On Sep 23, 2008, at 21:34, Maurizio Lotauro wrote:
> The problem is that when HttpCli detect the 401 (after finished to
> receive the
> body?) it start to re-send even if it has not finished the previous
> one, so the
> server will discard part of it, so it appear "truncated" on the head.
I'm sorry for the redundancy, and I do not wish to sound obtuse on
purpose, but I really want to understand this. If I understand you
correctly, what happens with HttpCli is this:
1. HttpCli sends unauthorized request.
2. Server sends 401 response after headers.
3. HttpCli receives 401 response while the body is in transit.
4. As soon as HttpCli acknowledges the 401 response, it tries to
resend, even if the body hasn't finished sending.
5. The server receives the new request within the Content-Length
payload of the old one, so it is not identified, and it (pressumably)
discards parts of it.
6. The new request then arrives distorted to the server.
If this is accurate, then I now understand why the RFC requires the
connection to be dropped: Technically you have two choices, either
continue sending the full Content-Length, so that the server can
discard it, reset, and be ready for a new request; or drop the
connection, therefore cancelling the entire unauthorize request, and
re-send in a new connection.
However, since the server has already rejected the request, sending the
full body is really useless (and a waste of resources, which is really
why the server responded early!), specially when you are posting a
large file. Therefore dropping the connection to reset everything is
the best option in such situation. But, again, this will cancel the
NTLM challenge-response cycle, and so we still have that problem.
> It works when you send all data in FSendStream from event
> THttpCli.SocketDataSent at once. That's of course not a real fix but
> it works, give it a trial.
This works because it prevents the HttpCli from acknowledging the 401
response until after it finishes sending (am I right?). But if the
payload is too big, you are still wasting everybody's time and
resources (server, client, user).
I suggest making the same tests but with a very large file (some
megabytes at least), and see how IE handles such cases (I want to see
if there is any heuristicts in IE that would cause it to drop a
connection if the file is too big, so that it doesn't waste resources).
If it does exactly the same thing as we have seen, then we should try
to replicate the behaviour in HttpCli: perhaps adding a new machine
state that instead of re-sending when 401 is detected, it makes sure
that the body has been sent completely, and if not, it delays
re-sending until it does.
dZ.
--
DZ-Jay [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
--
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
