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
