Adrian? HTTP/1.0 100 Continue problem..

[Roelf Diedericks]

I'd like some discussion before filing an issue and the appropriate
fix.

Referencing this bug: http://code.google.com/p/lusca-cache/issues/detail?id=16&q=skip

The whole "Skipping over 100-Continue replies" thing seems to have
been open for a while and I've found in some of my tests that:

1.) Microsoft Windows Server 2003 can sometimes send "HTTP/1.1 100
Continue" replies, without the client having requested it by adding a
"Expect: 100-continue" header during the request. Theres an open KB
entry about it.

2.)When "HTTP/1.1 100 Continue" is received by Lusca from a server the
resulting reply to the client has additional data in they body that
shouldn't be there.

3.) This appears to be due to the "Skipping" of 1xx replies in http.c
httpReadReply, as the malformed body that my clients received has
exactly the length of junk added to it as the length of the "HTTP/1.1
100 Continue" reply.

I've had a long hard read thru the code for httpReadReply in http.c
and it appears that during the "Handle 1xx response skipping here "
loop, when httpProcessReplyHeader is called stuff is appended using
storeAppend to the entry

When a full 100-Continue reply is read, httpReplyReset is called, to
reset the reply structures and to start looking for another header.

However the store entry is still sitting with some data in it, and
this appears to leak into the body later. I've tested a fix by adding
a "storeEntryReset(entry);" right after the httpReplyReset(reply) and
it seems to fix my bug.

I've tested one website http://www.dsg.co.za/ that seems to exhibit
this problem with Lusca. One of the "rotating flashy flashy" goodies
on that site makes an HTTP POST, and via Lusca the response is always
broken due to about 24 extra bytes being added to the body.

The logic in httpReadReply confounds me a bit, but my suspicion is
that the following patch should fix things nicely. It certainly has --
for me, but hasn't been tested in topend production use.

Adrian, since the rewritten httpReadReply seems to be largely your
doing, could you give me an opinion on the above?

[Roelf Diedericks]

Here's the fix I'm currently testing


Index: http.c
===================================================================
--- http.c (revision 14819)
+++ http.c (working copy)
@@ -1148,6 +1148,7 @@
if (reply->sline.status >= 100 && reply->sline.status < 200)
{
debug(1, 1) ("httpReadReply: FD %d: skipping 1xx
response!\n", fd);
httpReplyReset(reply);
+ storeEntryReset(entry);
httpState->reply_hdr_state = 0;
po += done; /* Skip the reply in the
incoming buffer */
done = 0; /* So we don't double-account
*/

[Adrian Chadd]

Would you mind pinging me after saturday about this? :)

Please do file an Issue about this though; I absolutely want to make sure that's fixed. Ideally I'd like to implement the rest of HTTP/1.1 so Continue is actually -handled- but I think we need to be realistic and note that will take more time/effort. :-)


Adrian

--
You received this message because you are subscribed to the Google Groups "lusca-users" group.
To post to this group, send email to lusca...@googlegroups.com.
To unsubscribe from this group, send email to lusca-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lusca-users?hl=en.

[Adrian Chadd]

Roelf,

Can you now ping me about this? :)

Adrian

[Roelf Diedericks]

All I can confirm is that the website I mentioned in my commit and a
few others that all seemed
to have Win2k3 and IIS in common are working now.