> Yes, section 8.2.2 says:


> As I mentioned in my previous message, I believe that
> this requirement is because the server responded
> early for a reason: it rejected the request, so
> sending the rest of the body to satisfy the
> Content-Lenght would go against the wishes of the
> server.  As we have seen, to compensate for this, the
> server "accepts" the body, but silently discards it
> (at least that seems to be the behaviour).  This
> means that the server is wasting resources in
> attending a rejected request.

I not convinced of this. The title of the section is "Monitoring Connections for
Error Status Messages". So when it say "SHOULD monitor the network connection
for an error status" I think that it refers to the connection itself and not to
an error reported by the server.
To support this in 8.2.4:
"... and if the client sees the connection close before receiving any status
from the server ..."
So the connection and what the server send are two different thinks.
I consider "sees the connection close" one of the possible results of "monitor
the network connection for an error status".


> ==== QUOTE:
> > If a Content-Length header was provided, the client
> > MUST close the connection.
> IE don't do so, but works (ok, it is a M$ product,
> following the rules is not
> very frequent ;).
> ====
> Are we confident that IE received the response early?

Yes. I waited at least one minute before confirm the authentication form. What
WireShark showed me is that the request was incomplete and the second try was
made with a new connection.
If I confirm immediately then all is done in the same connection, and of course
the re-send is made after the first is completed.
I repeat the same with Firefox (3.0.2) with similar result. The difference seems
that FF ask for user and password after it has finished to send the request.
Effectively I get the password request a bit later compared to IE.
Even FF do a new connection if I wait to confirm the authentication form. In
that case I see in WS that the first request is sent entirely.


> But keep in mind that it is a waste of time and
> resources for all parties involved to send a
> potentially large request in its entirety twice
> (first unauthorized, then authorized).

Yes, and in fact I'll change my client to work that way instead waiting for a
401 to include the authentication in the request, after the first time of 
Effectively if it has worked so from start I never encountered this problem. 

> Perhaps for NTLM connections the best course of
> action would be to send a HEAD request to retrieve
> the challenge-response token, instead of having to
> send the request multiple times.

Since it is a connection authentication and it is needed only the first time I
don't think that at the end it is a big issue.

About Tomcat, someone know the right place where put questions regarding the
behavior that we have discovered? I'm just curious...

Bye, Maurizio.

This mail has been sent using Alpikom webmail system

To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to