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 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.
Maurizio Lotauro wrote:
> So what I mean is that, if possible, the connection
should not be closed.
I agree. But my point was that since it is not
required by the protocol definition, clients and
servers are free to not implement re-using the
connection. Because of that, for the WWW to work,
both clients and servers must support their
counterparts to require a new connection for each
With HTTP 1.1, persistent connections are the
default, but note that if, say, the client closed the
connection before a new request (for whatever
reason), the server should accept the next request as
And, since the protocol *is* stateless, there is no
difference between sending a request within the same
connection and one from a new connection. Of course,
that is, no contextual difference (by which I mean
not counting performance).
> 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.
If it were a normal HTTP authentication method (Basic
or Digest, not NTLM), this would not be a problem:
You close the connection, re-connect, and re-send the
request with the proper credentials (as specified in
the 401 error response). Et voila.
>> (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
>> 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?
Because the authentication was for the *request*, not
the connection, and that request was terminated the
moment it was processed and a response was sent
(stateless, remember?). The persistent connection is
a hack in HTTP to improve performance and optimize
server loads. It does not imply statefulness, which
means that every request is treated as an entirely
new session, regardless of connection status.
Please understand this concept. This is why, in my
opinion, the NTLM causes so much trouble in edge
cases: because it breaks away from the standard way
that the HTTP protocol works.
>> [...] 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:
No, it is still true for Digest. The nonce is not
the same thing as the NTLM challenge, which
authenticates the *connection*. The HTTP protocol
allows for a client to close the connection,
re-connect and send the nonce in the next request
(along with the rest of the authentication details).
This is why it allows for a time-stamp or other
Note that it does not require that all requests are
sent through the same connection. Or do you think
that Digest was not supported until HTTP 1.1, when
persistent connections were the default?
>> 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
> It speak about a network connection and not an
error reported by the server. In
I'm not sure how this has to do with what I said
above. I stand by my comment: The HTTP protocol
(version 1.0 and 1.1) is stateless and requires that
every request contain all the information the server
needs to process it. In the case of the Digest
Authentication, the WWW-Authenticate header needs to
be submitted with the appropriate authenticated
digest hash on every request--regardless of whether
they are in the same connection or not.
By contrast, NTLM does not require this. Once it
authenticates the connection (notice again the
difference between authenticating requests and
connections), all requests made during that
connection are authorized, and do not need additional
information to this effect. This is in essence a
*stateful* connection; something that is not defined
in the HTTP protocol.
Again, this is why it causes subtle problems within
the HTTP protocol and has to be treated as a special
> 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.
I understand, but this only applies in the standard
case when the server sends the response after the
request has finished.
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 a
Content-Length header was provided, the client MUST
close the connection.
B. But closing the connection breaks the NTLM
connection authentication cycle (not so for Basic or
Digest), ergo the special case.
> About the NTLM, it is used for single signon and it
is quite useful.
NTLM is indeed very useful, but it is a Microsoft
protocol (for better or worse), which means that it
was designed to work with Microsoft products. By
implication, if it works with IIS, that's the extent
of their concern.
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.
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.
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