==== QUOTE: > 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? ==== Yes, section 8.2.2 says: "[...] If the client sees an error status, it SHOULD immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (section 3.6), a zero length chunk and empty trailer MAY be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client MUST close the connection." http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.2 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. ==== QUOTE: You said that the client MUST close the connection when receive the 401. Is the section above that you are referring? ==== Ah! I'm very sorry, but I think you may have misunderstood me. I said that the RFC (section 8.2.2, as quoted above) states that IF an error response is received early AND a Content-Length header was used THEN the client MUST close the connection. ==== QUOTE: 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? ==== No. Sending the response before the client has finished sending the request is allowed by the RFC. This is also in secion 8.2.2: "An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request." I can't find any place where it explicitly states that responses can come before the end of the request. Nor can I find a place where it explicitly states that the server must receive the full request before sending a response. The RFC seems to imply that the standard way is for a response to follow the full request; but parts like section 8.2.2 seem to imply that this is not a requirement. For example, in section 6: "After receiving and interpreting a request message, a server responds with an HTTP response message." It does not expressly say that the server must respond at the end of the request, just after interpreting it. Arguably, an unauthorized request for a resource that requires authentication can be clearly "interpreted" and identified as soon as the headers are received and processed. In any case, the wording in section 8.2.2 seems to suggest it strongly. ==== QUOTE: 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). ==== Exactly, it's a tricky situation. On the one hand, the server does not want to process a lengthy request which it *knows* is invalid. On the other hand, it is bound by the RFC to receive the full length of the body, as specified in the Content-Length header. The RFC therefore puts the responsibility on the client by saying that it MUST close the connection in such cases. If the client closes the connection, then everything falls into place: The client can re-connect and re-send the request with the appropriate authentication header (if it has the credentials), and the server can easily ignore the previous unauthorized request. All is well except for NTLM, which requires the connection to be kept open. By the way, when I said "security reasons", I meant to prevent a Denial-Of-Service attack. ==== 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? Perhaps it defers acknowledging responses until after the body is fully sent. (The RFC does say that the client "SHOULD" monitor for early error responses, it does not say they "MUST".) Also, as we have seen, the RFC seems a little vague in this regard, so it is entirely possible that this particular exceptional case was not considered too much. RFC 2616 does not discuss authentication at all, it was deferred to RFC 2617; but that RFC does not consider transport problems (since that is part of RFC 2616). Furthermore, RFC 2616 has this to say about Denial Of Service Attacks: "They exist. They are hard to defend against. Research continues. Beware. " Which does not help much. In any case, if it works for IE, it can work for us. Perhaps Firefox works the same way. We could ignore the RFC (like them) and send the full body. This will certainly work. 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). 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. ==== QUOTE: 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. ==== The RFC suggests clearly, while not stating explicitly, that servers may send a response before the entire body of the request is received (i.e. "[a]fter receiving and interpreting a request message", whenever that is). I know it's a bit of a stretch, but otherwise section 8.2.2 would be invalid or irrelevant. Cheers! -dZ. -- 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
