IE form post oddness

[jackfoust]

I'm trying to POST from a form a simple username and password onto
another website. Firefox and Opera post the data and results are
returned successfully. The site returns "missing user id and password"
when using the same form in Internet Explorer. This form works fine as
a GET, but I want to avoid this route. The site I'm posting to is
fairly closed and I'm not sure if I can get at the perl/c/whatever they
are using to check out the source. Anyone have a clue as to why IE is
misbehaving or the other browsers are breaking standards and actually
working?

<form name="accessform" method="post"
action="http://site/uhtbin/cgisirsi/0/0/30">
<input type="hidden" value="user" name="user_id" />
<input type="hidden" value="password" name="password" />
<p><input type="submit" value="Submit"></p>
</form>

TIA.

[Scott Bryce]

ja*******@gmail.com wrote:

I'm trying to POST from a form a simple username and password onto
another website. Firefox and Opera post the data and results are
returned successfully. The site returns "missing user id and password"
when using the same form in Internet Explorer. This form works fine as
a GET, but I want to avoid this route.

What type of file are you expecting to get in return? IE has a "feature"
(at least older versions did) that may require you to use GET. This
"feature" crops up when the server is generating a file type other than
an HTML or plain text file, and needs the form data to create the file.

I won't comment on the security issue of putting a password in a hidden
field. I'll assume you already know that, or that you have a good reason
to do that.

[jfoust]

Scott Bryce wrote:

What type of file are you expecting to get in return? IE has a "feature"
(at least older versions did) that may require you to use GET. This
"feature" crops up when the server is generating a file type other than
an HTML or plain text file, and needs the form data to create the file.

I won't comment on the security issue of putting a password in a hidden
field. I'll assume you already know that, or that you have a good reason
to do that.

It is outputting html. I replicated the form that is used on the web
site that is returning the data and it functions fine in IE. It is
only when I move the form to another webserver and have it try to get
results that I run into problems with just IE.

I'm not too concerned with the user going to view source and seeing the
hidden inputs, they are only seeing their actual id and pin, not
somethign system wide. I just want to avoid using GET so that the user
id and password doesn't end up in the cache. A lot of the traffic for
this web site is from shared computers.

[Jukka K. Korpela]

ja*******@gmail.com <ja*******@gmail.comscripsit:

<form name="accessform" method="post"
action="http://site/uhtbin/cgisirsi/0/0/30">

It's surprising that you claim that the form works on some browsers, given
the fact that the URL in the action attribute isn't even syntactically
correct, due to the malformed server part.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[jfoust]

Jukka K. Korpela wrote:

ja*******@gmail.com <ja*******@gmail.comscripsit:

<form name="accessform" method="post"
action="http://site/uhtbin/cgisirsi/0/0/30">

It's surprising that you claim that the form works on some browsers, given
the fact that the URL in the action attribute isn't even syntactically
correct, due to the malformed server part.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

I just shortened the fairly long server address to site, the
/uhtbin/cgisirsi/0/0/30 directory is correct though. There is no file
extension for whatever scripts the server is processing.

[Scott Bryce]

I don't know if this has anything to do with your problem, but I'll
describe IE's "feature" just in case this helps.

In the early days of the internet, not all servers sent the correct file
type headers for all file types. Of course, the correct solution to the
problem is to fix the servers. That has since happened. But in the mean
time, Microsoft added a Band-Aid to IE. When IE requests a file from the
server, it asks for only a portion of the file. When it gets this
portion, IE examines the content to determine what type of file it is.
IE may decide that the file type is different than the type specified in
the headers.

But here is where the "feature" comes in. IE will then make a second
request to the server for the entire file. If you are sending POST data
to the server, the POST data is not sent with this second request. GET
data is sent, since it is part of the URL. When you think about it, you
wouldn't want POST data sent a second time, since POST is supposed to be
used when the POSTed data will change the server state. Sending it a
second time could mess up data on the server. It would be sorta like
everybody clicking your submit button twice.

So if the content that is sent to the browser is determined by the data
sent to the server, you can't use POST. By the time IE sends a real
request for the content to the server, the POST data has been lost.

I know this was true for IE versions up to 5.x. I don't know if current
versions of IE still do this.

There may be exceptions to this, but I don't remember enough details to
know for sure.

Almost 3 years ago I was bit by this feature. My site generates PDF
files based on data sent to the server. I do most of my testing using
Netscape Navigator. When the site went live, I was unaware the site did
not work for IE users, until I started getting emails from them. It took
a full day to research the problem. I finally figured out what was
happening after finding a related article in the knowledge base at
msdn.com, (I can't find that article now) and noticing that my server
logs showed two requests to the server every time the submit button was
clicked by someone using IE. The solution was to change all my POSTs to
GETs.

[jfoust]

I just can't seem to figure out why it functions correctly when using
the form on the server of the target website, but not when I replicate
the form and put it on another webserver.

Original form is at
http://sirsi.altoonalibrary.org:8080.../0/0/29/48/X/1
-Using test as user id and test as pin; IE, Firefox and Opera all
return access denied, which they should.

Test form is at
http://www.altoonalibrary.org/sandbo...st_oddness.htm
-Firefox and Opera return access denied.
-IE returns missing user id or alt id.