Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>: [...]
> 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 course. 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 http://www.alpikom.it -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
