Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of pon.umapathy@gmail.com
 designates 209.85.217.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52452CDF.3090906@gmail.com>
References: 
 <CAEqv1uD1x_4hg6tC5PaoUDQRZO0EGksk_=J==_nPQGdTGe_TAg@mail.gmail.com>
	<52452CDF.3090906@gmail.com>
Date: Fri, 27 Sep 2013 14:41:45 +0530
Message-ID: 
 <CAEqv1uBWdtgaufAZHGUy3Nz7HmcRnW856JxgjVs_3aER+BCLQA@mail.gmail.com>
Subject: Re: response handling inside ap_hook_create_request cb function
From: Pon Umapathy Kailash S <pon.umapathy@gmail.com>
To: modules-dev@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Thanks for your response, Sorin.

My concern in this approach is that - it would require one worker
thread to be held up for as long as this connection is open(and this
might be long + the number of clients can be higher than the worker
threads for my use-case/platform).

Given that the 1st handshake message is over http, i can setup the
connection in a handler hookup function and return a response, freeing
up the worker thread while keeping the connection persistent(plus save
the socket/ssl in a cache shared the worker threads).

Now, when the next set of messages come in(which is not over http), I
would need to intercept these and add my handling(ideally write
something on the socket on which the message came and be done with the
request while keeping the connection persistent unless the message was
a control frame to close).

Regards,
Umapathy


On Fri, Sep 27, 2013 at 12:29 PM, Sorin Manolache <sorinm@gmail.com> wrote:
> On 2013-09-27 03:06, Pon Umapathy Kailash S wrote:
>>
>> Hi,
>> Here is a quick background on what I am trying to do(basically adding
>> support for websockets - in a slightly customised manner as needed for
>> my app):
>>
>> - Handle the initial handshake inside a cb function registered as a
>> handler hook(from here, I compute checksums required and return the
>> response headers as needed).
>>   Also, the socket from which the request was read is stored in a cache.
>>
>> - For subsequent message reception(on the same connection), i have a
>> function cb registered using ap_hook_create_request(since this is a
>> different protocol format message). Here, I read and parse the
>> messages/requests which are coming in from the cached list of
>> sockets(this is working).
>>
>> However, once I return from this cb, the connection/socket seems to be
>> closed. I guess the request is further passed down to hooks down the
>> line and the connection is closed since the req format is not known.
>>
>> What would be the best way to handle this scenario?
>>
>> I have the following in mind:
>>    - let the request not be processed any further(and keep the connection
>> on).
>>    - create a req structure with dummy http headers that i can later
>> recognise and handle inside my handler hook to just ignore later on
>>
>> are there any examples/notes on how these can be achieved?
>
>
> In my opinion, it is too late to handle non-http in the create_request
> callback.
>
> The create_request callback is called from
> ap_run_process_connection->ap_process_http_{sync|async}_connection->ap_read_request.
>
> Your create_request callback returns to ap_read_request from where the
> request is further processed as an http request.
>
> In my opinion you should short-cut the http processing and hook
> ap_hook_process_connection. However, there, in process_connection, you have
> no request_rec, you have just a conn_rec. process_connection is called only
> once per connection creation. So it should handle all the requests that
> arrive while the connection is open.
>
> Sorin
>
>
>
>
>
>>
>> Regards,
>> Umapathy
>>
>