Scrive "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>: > Hello: > I'm sorry for the long discussions, but we have > identified an issue and understanding each other is > the only way to work together to solve it. Please > read below for my responses.
I think that putting together our experience is the way to get a better (or the correct) result. > I would take this off-list, except for the fact that > it is a discussion on the implementation of HTTP > protocols, which I think is relevant to this list. > If not, please let me know. I agree. I must admit that the implementation of NTLM has really mislead me, bring me to think that the server keep the authentication info until the connection close. That's wrong, and the key word is "stateless". Thank you very much for enlighten me! > Maurizio Lotauro wrote: [...] > ==== > > In that case (401) the server answer with > Connection: Keep-alive, so the client > > (try to) act consequently. > ==== > > Yes, but the response came while the body was in > transit already, before it was sent completely, which > puts the transaction in a very unstable state. This > is the reason why the RFC requires the client (i.e. > it says it "MUST") close the connection if the > Content-Length header was used. Can you point me where the rfc say this? Is it the 8.2.2? [...] > ==== > >> Another way that NTLM breaks away from the > protocol is that, once the > >> connection is authenticated, subsequent requests > within the same > >> connection need not perform the challenge-response. > > > > I don't agree with you. In a previous post I think > you refer to this (from rfc > > 2616): > > > > ---8<--- > > 8.2.2 Monitoring Connections for Error Status Messages > > [...] > > It speak about a network connection and not an > error reported by the server. In > > fact: > ==== > > I'm not sure how this has to do with what I said > above. You said that the client MUST close the connection when receive the 401. Is the section above that you are referring? > ==== > > 8.1.2 Overall Operation > > [...] > > That is, unless otherwise indicated, the client > SHOULD assume that the server > > will maintain a persistent connection, even after > error responses from the server. > > --->8--- > ==== > > I understand, but this only applies in the standard > case when the server sends the response after the > request has finished. What is still not clear to me is: sending the response before the client has finished to send the request break the rfc or not? > Our problem with ICS is in dealing with an edge case: > > A. The server (for security reasons) sent the error > response right after the headers, and the client is > already engaged in sending the body. If this was for security reasons why the server doesn't close the connection? As it is actually it receive the rest of the request (at least if made by IE). > 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 ;). > But non-Microsoft products tend to adhere pretty > closely to the RFCs. A case in point is Tomcat, > which seems to send error responses before receiving > the entire request--precisely because this is allowed > by the HTTP RFC. And any other mechanism defined by > the RFCs will work fine with this. I'm unable to find where the rfc describe clearly a situation like this, but I read only the sections that I think are related and probably I missed the right one. > In my opinion, NTLM may be very good, but it is still > not purely HTTP-friendly (when it comes to > exceptional and edge cases), and so it must be > treated as a special case. This is how I think > Firefox and IE deal with it, and this is how I think > we should deal with it. I agree, even for situations that are not fully correct. For example actually the component handle html response that come without the header. 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
