==== QUOTE:
I not convinced of this. The title of the section is
"Monitoring Connections for
Error Status Messages". So when it say "SHOULD
monitor the network connection
for an error status" I think that it refers to the
connection itself and not to
an error reported by the server.
====
Wow, you bring a very interesting point. I was
interpreting "error status" as an error response, but
now I think you are right: it seems to mean that the
connection must be dropped when the TCP/IP connection
itself fails while transmitting. I don't know how I
missed this.
If this is the case, then early error responses are
not supposed to happen (since, as I said before, they
do not seem to be mentioned anywhere).
==== QUOTE:
So the connection and what the server send are two
different thinks.
I consider "sees the connection close" one of the
possible results of "monitor
the network connection for an error status".
====
Yes, you are right. I'm sorry, I appear to have
misunderstood the semantics of section 8.2.2 of the RFC.
==== QUOTE:
Yes. I waited at least one minute before confirm the
authentication form. What
WireShark showed me is that the request was
incomplete and the second try was
made with a new connection.
If I confirm immediately then all is done in the same
connection, and of course
the re-send is made after the first is completed.
====
I'm sorry but I'm confused. What caused IE to open a
new connection? When you say "I confirm", do you
mean that you submit a username and password when IE
prompted you?
Perhaps the new connection is because of a very short
nonce time-out?
==== QUOTE:
I repeat the same with Firefox (3.0.2) with similar
result. The difference seems
that FF ask for user and password after it has
finished to send the request.
Effectively I get the password request a bit later
compared to IE.
Even FF do a new connection if I wait to confirm the
authentication form. In
that case I see in WS that the first request is sent
entirely.
====
OK, so it is what we have suspected all along: Both
browsers receive the early 401 response but continue
sending the full content, and then re-send the
request with the authorization headers. The
difference is that IE prompts the user as soon as it
receives the response (early), while Firefox waits
until it finishes transmitting the body (late).
I think then that Arno's solution would work, since
it seems to have the same effect: delay the re-try
until after the body is sent completely.
I still think this offers a vector for
Denial-Of-Service attacks. However, sending the
response early does not protect you since, as we saw,
the client is free to delay reacting to the response.
I agree with you that if this was the concern of
Tomcat, it would have closed the connection. So why
does Tomcat respond early?
-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
