Closed Bug 264414 Opened 20 years ago Closed 19 years ago

POST data not obtained in IIS5 filter

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED EXPIRED

People

(Reporter: madan94043, Assigned: darin.moz)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.4.1) Gecko/20031008
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.4.1) Gecko/20031008

I have deployed a filter in Microsoft IIS 5.0 server. The filter basically
intercepts every request accessing the machine to check whether the user has
enough credentials to view the resource. If not it will redirect the request to
an authentication server. Once authentication is successful the authentication
server sends back the below document to the browser which then sends back the
document to the server where IIS5 filter is loaded. 

In this case lets assume that "server.test.com" is the machine
where the filter is deployed.

<HTML>
<Body OnLoad="document.Response.submit()">
<FORM NAME="Response" METHOD="POST"
ACTION="http://server.test.com/iisstart.asp">
<INPUT TYPE="HIDDEN" NAME="TEST" VALUE="<requrired data............>">

</FORM>
</BODY>
</HTML>

If I access the resource thru Internet Explorer it redirects me to the
authenticate server, once authentication is complete the IIS5 filter is
receiving the whole POST data. The header "Content-Length: " is indicating
how many bytes are there in the POST data. Everything is working as expected.

But if I acccess the resource thru Netscape Navigator or Mozilla (1.4.1) or 
FireFox (0.9.3) it redirects me to the authenticate server, once I authenticate
the IIS5 filter is not getting any POST data. Even the header "Content-Length: "
is not set.  A pop-up window appears and informs "Document contains no data".

I verified that the authentication server is infact sending the document. But
somewhere between "authenticate server -> browser -> IIS5 filter", the POST data
is lost. Subsequently functionality is failing if I use Mozilla or Netscape
browsers.

Any idea why I am getting POST data in IIS5 filter only when I use Internet
Explorer and not in other browsers?

Thanks,
Madan

Reproducible: Always
Steps to Reproduce:
As indicated in "Details".
Actual Results:  
A pop-up window appears and informs "Document contains no data"

Expected Results:  
1. The "Content-Length" header should be present with the value equal to that of
the length of the POST body. 
2. The actual POST body should be available to the IIS5 filter.

This is very important fix for our project. We cannot just ask the customers to
use IE. The POST data contains very important data to the IIS5 filter. Without
retrieving the data, the filter functionality fails.
so are you sending http 3xx status codes, to get a redirect?
Assignee: general → darin
Component: Browser-General → Networking: HTTP
QA Contact: general → core.networking.http
That is right. I am doing a 302 Redirect from my IIS5 filter to the
authentication server.

Madan
The definition of 302 responses
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3) says:

  If the 302 status code is received in response to a request other than GET or
  HEAD, the user agent MUST NOT automatically redirect the request unless it can
  be confirmed by the user, since this might change the conditions under which
  the request was issued.

(so Mozilla would have to prompt before redirecting in your case; I assume IE
doesn't prompt?).  It goes on to say:

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method.

That's what Mozilla is doing, in fact.
I am doing a 302 redirect in response to a GET. When the redirection happens
Mozilla is not prompting me before it does a redirect. The steps I perform are:
1. Access a resource (this is a GET request)
2. The filter intercepts the request to see whether the user has enough
credentials to access the resource. 
3. If not, it does a 302 redirect to the authenticate server
4. User authenticates and the authenticate server uploads the document as
explained before. The document has the METHOD name set to "POST" and the VALUE
field having the required POST data. I have verified the same by looking at the
logs on the authenticate server
5. The filter intercepts the request, checks for the method name. If it is POST
(which is in this case) and subsequently reads the POST data.
6. I am getting the correct method name, but the POST data is empty.

As explained before this problem is not happening with IE.

Also I saw similar bug being filed against Mozilla. FYI.

https://bugzilla.mozilla.org/show_bug.cgi?id=223893
https://bugzilla.mozilla.org/show_bug.cgi?id=137155
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.