Re: Q about http-parser

Hi Willy,

On Mit 14.11.2007 08:59, Willy Tarreau wrote:
>Hi Aleks,
>
>On Tue, Nov 13, 2007 at 08:11:24PM +0100, Aleksandar Lazic wrote:
>> Hi,
>>
>> today I have have take a look into your http-parser and have not
>> found where you handle the:
>>
>> ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt
>>
>> 3.6.1 Chunked Transfer Coding
>>
>> in src/proto_http.c
>
>The http-parser only parses the first line and header parts. In
>chunked-encoding, you also have to read one line of data, which
>contains the chunk size, then skip over that exact number of bytes,
>then read next line of data, etc... until you read 0 indicating the
>line ends, or until the peer closes (in which case I believe you can
>report an error).

I have remember, to late sorry, that haproxy only handle header phase ;-).

Sorry for the rush ;-/.

>> I found a nice compressed info about MUST/SHOULD/... here
>> http://www.and.org/texts/server-http.
>
>Oh, that's a very interesting analysis. I did not know that LWS were
>allowed in the middle of numbers (and I still doubt about it, it looks
>strange).

Yep, it is :-/

>Otherwise his analysis is fine and he seems to have covered many of the
>crappy aspects of HTTP. However,I don't agree with his last statement :
>
> "All major clients send the correct CRLF encoding, and while
> it's possible some minor clients may be sending just LF I
> have no sympathy for accomodating them."
>
>TuX did this in its early versions, and it quickly changed when people
>got bored by not being able to telnet into it and send test requests by
>hand! And-http may be a young project, and will certainly change this
>counter-rfc limitation when people start to complain ;-)

I have not used his webserver, but I found the analysis also very nice ;-)

>> As we talked many times I think there are still some issues before we
>> can start to look into some 1.1 features but, thanks to your change
>> to modules and filters we are not so far any more ;-))
>
>No, I really think we're close to being able to support basic
>keep-alive, at least for adjacent content-less requests such as HEAD
>and GET. When the HTTP processing moves into process_http function, it
>should get even easier because the underlying states will serve only
>data transfer.

Hm, do you mean this comment in src/client.c:

/*

• FIXME: This should move to the STREAM_SOCK code then split into TCP
• and HTTP. */

right ;-)

Do you plan to make a:

---
    switch(mode):
         case HTTP: process_http; break; <= here you must handle also the
	                                   tcp parts
          case TCP: process_tcp;  break;
          case ...: process_...;  break;
---

a chain like:

---
process_tcp
check_again:
if http_mode then process_http
if ssl_mode then process_ssl set http_mode goto: check_again

if ..._mode then process_...
----

or a complete different way ;-)?!

Cheers

Aleks