M
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
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