> 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:

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

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

Reply via email to