Re: Q about http-parser

Hi willy,

On Mit 14.11.2007 19:04, Willy Tarreau wrote:
>On Wed, Nov 14, 2007 at 06:23:32PM +0100, Aleksandar Lazic wrote:
>> >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 ;-)
>
>yes, part of this.

[snipp]

>The http_process_session() will have to support the HTTP state in
>addition to this, so it will look more like this (synthetic) :
>
> {
> if (client_side_buffer->state != SILENT)
> update_session(client_side_buffer);
> if (server_side_buffer->state != SILENT)
> update_session(server_side_buffer);
>
> switch (session->state) {
> case REQ_HEADERS:
> filter_request(); rewrite_request();
> capture_headers(); capture_cookies();
> apply_persistence(); select_server();
> break;
>
> case REP_HEADERS:
> filter_response(); rewrite_response();
> capture_response(); capture_cookies();
> update_persistence();
> break;
>
> case DATA:
> transfer_at_most_content_length();

Will be able to add a fuction()/module/.. into this state?!

> }
>
> if (client_side == CLOSED && server_side == CLOSED)
> end_of_session;
> }

[snipp]

>Like I described above in fact. It would also become easier to support
>SSL since we will "just" have to attach the client-side buffer to
>another buffer which gets decrypted traffic :
>
> TCP req_buffer SSL req_buffer HTTP
> client_sock <----> <--------> <-------> server_sock
> rep_buffer rep_buffer
>
>The "master" processing here is HTTP. The config will inform the proxy
>that the client side relies on SSL, which itself relies on TCP, so this
>sort of "stack" will have to be built upon accept(). Sometimes we build
>above us by calling the upper level accept(), sometimes we call below
>us by calling the lower level connect(). I think that the chain of
>protocols should simply be specified in an per-proxy array, and each
>accept() at level N calls the accept at level N+1. In the example
>above, the functions would be called that way :

Thanks for the description ;-).

Cheers

Aleks Received on 2007/11/16 10:13