Scrive DZ-Jay <[EMAIL PROTECTED]>: > > On Sep 20, 2008, at 19:03, Maurizio Lotauro wrote: > > > I just saw it. The 401 become after the whole file is sent. > > Leave it to MS to allow for a DOS attack vector, ha!
:-) > As Maurizio said, we need to test this on a server that responds after > the headers are sent (before the payload). In my case the server answers not after the headers but rigth after the client has sent the first 8193 byte of the SendStream (that is the size of the THttpCli send buffer). > > It's IE trying to upload a file to IIS 5.1 and basic authentication is > > required. > > But isn't "basic authentication" handled in the way I mentioned before, > that is, you close the connection when you receive the error from the > server, and re-send the request with the auth header? No the connection is not closed, and specifically the server answer with "Connection: Keep-alive". > I thought that > the problem had to do with the specific NTLM authentication method, > which required a challenge-response within the same session. Not really, the NTLM make the close of connection impracticable, but IMHO in any case it is better to do so (not close I mean). > (Boy, I should really go read up on that NTLM thing!) Another interesting link: http://www.innovation.ch/personal/ronald/ntlm.html In particular this sentence: "Also note that this scheme is not an http authentication scheme - it's a connection authentication scheme which happens to (mis-)use http status codes and headers (and even those incorrectly)." [...] > > Should the 401 be considered an error? > > Yes. Success responses are start in the 200-299 range. Fatal error > responses are in the 500-599 range, and 400-499 represent transient > errors. This is typical of most "classic" Internet high-level > protocols. The 401 response code indicates a recoverable error: the > server rejected the request because it requires authentication, you > just need to resend the request with the appropriate credentials. Since it is a recoverable error there should be no reason to close the connection. Opening a connection is a relative heavy operation. > As originally intended in the HTTP RFC, the protocol being stateless, > it was expected that the resonse would follow the request and complete > the session, and that the re-send would be an entirely new > connection/session. HTTP is stateless, but this has nothing to do with keeping the connection open. I don't think that a browser reopen the connection for every part that compose a web page. And I don't think also that you close and reopen the connection for every file you want upload or download to/from an ftp server :-) > From what I understand now about NTLM (still need > to learn about it!), it requires the cycle to happen within the same > session, which counters the RFC, and thus is an exceptional case. The basic is the only one that is handled in one step. All others needs a negotiation. IIRC the NTLM is anomaly is that it is the server that starts it with the first 401 answer. 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
