HTTP POST, Authorization header automatically sent -- WHY?!

[Michael Scovetta]

Alright, I have a complex environment set up, but here is the jist of
it:

Client <---> Apache 1.3.x <----> mod_jk <----> JBoss
(IE 6) + Custom Auth Module

I believe the problem lies in the custom auth module, but I need to
know
how IE works in order to provide a fix. Here is the problem:
Sometimes (non-reproducible), when a user sends a POST request, the
relevant HTTP that are initially sent are: [sniffed going out of
client]

POST /servlets/foo HTTP/1.1
Accept: */*
Referer: http://server/bar.jsp
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; GIS
IE6.0 Build 20031007; .NET CLR 1.0.3705)
Host: server
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: Java cookie, proxy cookie, auth cookie
Authorization: NTLM TlRM...

Now, the auth cookie takes care of authentication, and so the
Authorization: NTLM... stuff is unnecessary. However, the custom
module, knowing that the auth cookie is valid, passes the request on,
so that my application finally receives the POST request, but as you
can see, Content-Length=0 and there is no POST data, so my app thinks
that nothing was submitted.

Generally, once this occurs in a particular browser session on a site,
it is reproducible every time in that browser session. Spawning new
browsers (CTRL-N) continues the effect, but opening new browsers
don't.

I realize that this is a problem in the custom auth module, but my
main question is:
When does IE decide to send Authorization:... information during a
POST request? It was not asked for by the server:
Normally: GET ---->
<---- 401 + WWW-Authenticate
Authorization---->
<---- 200 data

But here:
DURING PROBLEM:
POST + Authorization ---->
(content length=0)
<---- 200 data
WITHOUT PROBLEM:
POST ---->
<---- 200 data

So clearly, sometimes IE wants to send Authorization, and sometimes it
does not. Resetting cookies, deleting caches, etc don't seem to have
an effect. The site is on an Intranet zone. Cookies are not being
blocked. IE browser version is: 6.0.2800 1106CO with all current
patches.

If anyone from Microsoft would respond, it would be greatly
appreciated.

Regards,

Michael Scovetta

 

[nobody]

Alright, I have a complex environment set up, but here is the jist of
it:

Client <---> Apache 1.3.x <----> mod_jk <----> JBoss
(IE 6) + Custom Auth Module

I believe the problem lies in the custom auth module, but I need to
know
how IE works in order to provide a fix. Here is the problem:
Sometimes (non-reproducible), when a user sends a POST request, the
relevant HTTP that are initially sent are: [sniffed going out of
client]
[snip]

But here:
DURING PROBLEM:
POST + Authorization ---->
(content length=0)
<---- 200 data
WITHOUT PROBLEM:
POST ---->
<---- 200 data

So clearly, sometimes IE wants to send Authorization, and sometimes it
does not. Resetting cookies, deleting caches, etc don't seem to have
an effect. The site is on an Intranet zone. Cookies are not being
blocked. IE browser version is: 6.0.2800 1106CO with all current
patches.

This is actually in IE, and not a problem on your side. Once NTLM
authentication has been negotiated, the client browser will renegotiate
authentication before sending the POST data. Basically, there is a
handshake during initial authentication. When you do a form POST at any
point after that, the client reinitiates the handshake (with the empty
POST). The server responds with a challenge, and the client then
resubmits the POST with the form data (and the response to the challenge
in the authorization header).

 

[Michael Scovetta]

Alright, I have a complex environment set up, but here is the jist of
it:

Client <---> Apache 1.3.x <----> mod_jk <----> JBoss
(IE 6) + Custom Auth Module

I believe the problem lies in the custom auth module, but I need to
know
how IE works in order to provide a fix. Here is the problem:
Sometimes (non-reproducible), when a user sends a POST request, the
relevant HTTP that are initially sent are: [sniffed going out of
client]
[snip]

But here:
DURING PROBLEM:
POST + Authorization ---->
(content length=0)
<---- 200 data
WITHOUT PROBLEM:
POST ---->
<---- 200 data

So clearly, sometimes IE wants to send Authorization, and sometimes it
does not. Resetting cookies, deleting caches, etc don't seem to have
an effect. The site is on an Intranet zone. Cookies are not being
blocked. IE browser version is: 6.0.2800 1106CO with all current
patches.

This is actually in IE, and not a problem on your side. Once NTLM
authentication has been negotiated, the client browser will renegotiate
authentication before sending the POST data. Basically, there is a
handshake during initial authentication. When you do a form POST at any
point after that, the client reinitiates the handshake (with the empty
POST). The server responds with a challenge, and the client then
resubmits the POST with the form data (and the response to the challenge
in the authorization header).

I gotcha, except that I have packet captures that indicate that
sometimes (actually, most of the time), the POST is sent without any
authorization information at all (because, from IEs point of view, the
resource is not protected). I believe there is some confusion on how
IE acts when authenticating to a site that, for some pages, requires
authentication, but not for others. This really isn't the case here,
because the auth is stored in the cookie, but IE doesn't know that.
**Something** is making it behave differently **sometimes**. I don't
know what **Something** or **sometimes** is though.

Could IE be caching credentials for a time period? Or is it based on
URLs? I'm not cross-server POSTing, but I am cross-directory POSTing
(form is at /foo/bar.jsp and the form ACTION is /servlets/Quux. I
can't see this being totally intentional, since it doesn't happen all
the time (but when it does happen, my process fails, all of the time).

So, regardless of the cause in IE, the custom auth module SHOULD act
as such: Whenever it gets an Authorization header, it should send back
the auth header to get IE to believe that it is authenticated (via
401s) and then IE will then POST again with the actual data? It looks
like a bug in the auth module at this point.

Thanks for your help--
Mike

 

[nobody]

I gotcha, except that I have packet captures that indicate that
sometimes (actually, most of the time), the POST is sent without any
authorization information at all (because, from IEs point of view, the
resource is not protected). I believe there is some confusion on how
IE acts when authenticating to a site that, for some pages, requires
authentication, but not for others. This really isn't the case here,
because the auth is stored in the cookie, but IE doesn't know that.
**Something** is making it behave differently **sometimes**. I don't
know what **Something** or **sometimes** is though.

From what I have seen, any NTLM authentication to a server will result
in this behavior for subsequent POSTs to the same server (even
unprotected resources). For example, if I go to NTLM-protected resource
"/myntlm/test.html", then (later on) POST to the unprotected resource
"/unprotected/foo.asp" this will be exhibited.

Could IE be caching credentials for a time period? Or is it based on
URLs? I'm not cross-server POSTing, but I am cross-directory POSTing
(form is at /foo/bar.jsp and the form ACTION is /servlets/Quux. I
can't see this being totally intentional, since it doesn't happen all
the time (but when it does happen, my process fails, all of the time).

The only way I have seen to get IE to "forget" it has previously
NTLM-authenticated to a site is to send a 401 page status. This
effectively resets the IE authentication state.

 

[Michael Scovetta]

From what I have seen, any NTLM authentication to a server will result
in this behavior for subsequent POSTs to the same server (even
unprotected resources). For example, if I go to NTLM-protected resource
"/myntlm/test.html", then (later on) POST to the unprotected resource
"/unprotected/foo.asp" this will be exhibited.


The only way I have seen to get IE to "forget" it has previously
NTLM-authenticated to a site is to send a 401 page status. This
effectively resets the IE authentication state.

Ooh, that's interesting. I'll try that-- is this black-magic documented
anywhere? There seem to be no description of how IE behaves, or is this
actually what the RFC says should happen?

Thanks for your help!
Mike

 

[Blue Jean]

We are expericening the same problem,
Do you have any progress with regard fixing
this problem?
Thanks,
-B.

 

[H Leboeuf]

http://support.microsoft.com/?kbid=831167
SYMPTOMS
Programs that use Wininet functions to post data (such as a user name or a
password) to a Web server retry the POST request with a blank header if the
Web server closes (or resets) the initial connection request.