> On Sep 21, 2008, at 18:53, Maurizio Lotauro wrote:


> I'm sorry but you are confused.  HTTP is not like FTP.

I mentioned ftp only as example that show how many time is needed to make the
connection, while http do it behind the scene.

> In HTTP 1.1, 
> persistent connections were defined but it was a matter of convenience 
> and they are not required (RFC #2616, Section 8 uses the term "SHOULD" 
> instead of "MUST" when discussing the negotiation of persistent 
> connections).

I haven't said that the connection must keep open, but that it is better (or
preferable, or convenient as you said) in term of performance.
The advantages are listed at the point 8.1.1, right before the sentence "HTTP
implementations SHOULD implement persistent connections."
So what I mean is that, if possible, the connection should not be closed.

>   Some servers supported the Keep-Alive mechanism, but--again--it was 
> more of a convenience, and could never be expected to be supported by 
> either side.

In that case (401) the server answer with Connection: Keep-alive, so the client
(try to) act consequently.

> This is why, in my opinion, coercing HTTP as the de facto standard 
> protocol for all communications in the Internet (as a lot of people are 
> trying to make it) is stupid.  There are better transfer protocols out 
> there.  But this is a rant for another day.

I fully agree with you!! 


> > 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.
> Again, wrong.  All HTTP authentication uses the same negotiation 
> mechanism (even since the days of HTTP 1.0), because they authenticate 
> the *request*:

Well, I'm getting old and sometimes my memory miss something :-)
Now I (quickly) reread the RFC 2617

> 1. The client requests a resource from the server for the very first 
> time and it doesn't know it requires authentication.


> 2. The server responds with an appropriate error code specifying the 
> authentication mechanism(s) supported (including Basic and Digest).
> (At this point, servers or clients using older versions of the HTTP 
> protocol would have closed the connection.)

Only if the client and the server doesn't include Connection: Keep-alive

> 3. The client re-sends the request with the appropriate credentials and 
> the server performs the authorization.


> 4. On every subsequent request, the client includes the same 
> credentials and the server re-authenticates the request.  (Digest has 
> some differences, but generally fits this scheme).

This should be not necessary if the connection is not closed in the meantime.
In fact if the client is still connected why it should resend the exactly same
credential every time?

> Notice that since the protocol is absolutely stateless, the server has 
> no idea at any point how many requests have been sent, and it doesn't 
> care.  So, the client can remember the specific server's requirements 
> and send them in subsequent visits.  And in fact, this is what browsers 
> do:  from then on, the authentication can be done in a single request, 
> without the "error" step.

This is true for basic but I think not for digest. The challenge include a nonce
value, and the section 3.2.1 say:

With a nonce of this form a server would recalculate the hash portion after
receiving the client authentication header and reject the request if it did not
match the nonce from that header or if the time-stamp value is not recent 
An implementation might choose not to accept a previously used nonce or a
previously used digest, in order to protect against a replay attack. Or, an
implementation might choose to use one-time nonces or digests for POST or PUT
requests and a time-stamp for GET requests.


> 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

8.2.2 Monitoring Connections for Error Status Messages
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. If the
client sees an error status, it SHOULD immediately cease transmitting the body.
If the body was preceded by a Content-Length header, the client MUST close the

It speak about a network connection and not an error reported by the server. In

8.1 Persistent Connections
8.1.1 Purpose
- HTTP can evolve more gracefully, since errors can be reported without the
penalty of closing the TCP connection.

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 

> Because of its unique nature (damn you, Microsoft!) I'm sure browsers 
> treat it as a special case. (I seem to remember having problems with 
> Firefox 1.x connecting to my office's intranet site, while IE worked 
> fine.  I always knew it had to be some MS extension to the protocol but 
> didn't know what.  Now I do.)  Of course, IE will work fine with IIS.

I think we can share a lot of opinion about M$ :-)
About the NTLM, it is used for single signon and it is quite useful. 

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