Lusca handles HTTP status reply codes >= 600 poorly

[GoogleCodeExporter]

The server-side code handles HTTP status reply codes >= 600 poorly. It results 
in the client-side connection simply "hanging".

There's two problems:

* I'm seeing HTTP replies with status >= 600 in the wild; and
* Both these and "invalid HTTP header/too big" result in the connection hanging 
rather than completing.

To reproduce:

* grab that reply file
* while true; do cat yahoo-999-reply.txt | nc -l 127.0.0.1 8080 ; done
* then request that file through lusca - eg squidclient http://127.0.0.1:8080/
* watch the client-side connection hang

Original issue reported on code.google.com by adrian.c...@gmail.com on 27 Nov 2010 at 4:05

Attachments:

• yahoo-999-reply.txt

[GoogleCodeExporter]

The fix to the first part is to bump the invalid status header id's up to 
something that isn't going to be parsed. I'm going to bump them to begin at 
1001. The parser should then ensure that they're not parsed normally.

The fix to the second part will be a bit more difficult.

Original comment by adrian.c...@gmail.com on 27 Nov 2010 at 4:07

[GoogleCodeExporter]

I've done the status code bumping and it does seem to resolve the hanging for 
me.

Have tested with both squidclient and wget against a test page I've setup:

http://rodent.za.net/999.php which simply spits out a 999 error.

Before bumping the invalid status code header up, I'd get a client connection 
hang with the following:

2010/12/15 14:27:01| httpProcessReplyHeader: Non-HTTP-compliant header: 
'HTTP/1.1 999 AveryWeirdError
2010/12/15 14:27:01| httpProcessReplyHeader: Non-HTTP-compliant header: 
'HTTP/1.1 999 AveryWeirdError
2010/12/15 14:27:24| ctx: exit level  0
2010/12/15 14:27:24| ctx: exit level  0
2010/12/15 14:27:24| Preparing for shutdown after 0 requests
2010/12/15 14:27:24| Preparing for shutdown after 0 requests
2010/12/15 14:27:24| Waiting 0 seconds for active connections to finish
2010/12/15 14:27:24| Waiting 0 seconds for active connections to finish

--- After bumping the invalid status past 999 as per your commit, 

I get the following

--
2010/12/15 14:28:38| httpProcessReplyHeader: HTTP CODE: 999
2010/12/15 14:28:38| httpProcessReplyHeader: HTTP CODE: 999
2010/12/15 14:28:38| httpMakeVaryMark: accept-encoding, user-agent
2010/12/15 14:28:38| httpMakeVaryMark: accept-encoding, user-agent
2010/12/15 14:28:38| ctx: exit level  0
2010/12/15 14:28:38| ctx: exit level  0
2010/12/15 14:28:38| fwdUnregister: http://rodent.za.net/999.php
2010/12/15 14:28:38| fwdUnregister: http://rodent.za.net/999.php
2010/12/15 14:28:38| fwdComplete: http://rodent.za.net/999.php
        status 999
2010/12/15 14:28:38| fwdComplete: http://rodent.za.net/999.php
        status 999
2010/12/15 14:28:38| fwdReforward: http://rodent.za.net/999.php?
2010/12/15 14:28:38| fwdReforward: http://rodent.za.net/999.php?
2010/12/15 14:28:38| fwdReforward: No forward-servers left
2010/12/15 14:28:38| fwdReforward: No forward-servers left
2010/12/15 14:28:38| fwdComplete: not re-forwarding status 999
2010/12/15 14:28:38| fwdComplete: not re-forwarding status 999
2010/12/15 14:28:38| fwdStateFree: 0x2830278
2010/12/15 14:28:38| fwdStateFree: 0x2830278

---------------------------------------------

My feeling is there's some logic bug being propagated from here in http.c:

(http.c)

 if (reply->sline.status >= HTTP_INVALID_HEADER) {
        debug(11, 3) ("httpProcessReplyHeader: Non-HTTP-compliant header: '%.*s'\n", (int) hdr_size, hdr_buf);
        httpState->read_buf = buf_deref(httpState->read_buf);
        ctx_exit(ctx);
        /* XXX why return hdr_len here when the memBuf used has been cleaned? */ <<<<<<<<<<<<<<<<<<<<<<<<<
        //return done;
        return 0;
    }

Shouldn't that actually return "done" rather than zero because some other code 
expects it ?

Original comment by roelf.di...@gmail.com on 15 Dec 2010 at 12:39

[GoogleCodeExporter]

You can try changing the return code but i dont think it will help. The problem 
is that the connection isn't closed 'right' and thus thre client side never 
gets notification that the server side has finished.

That whole sectuon of the http code could do with some reevaluation. :p

Original comment by adrian.c...@gmail.com on 16 Dec 2010 at 3:40