Re: How to access client socket from a protocol handler
On Sun, Oct 24, 2010 at 00:00, Alexander Farber wrote: > I've created a module using bb (the source code at the bottom) > and it suffers from the same problem (hijacks the port 80 too). > Could it be that "SetHandler" is a wrong directive for protocol handler? The wrong directive, yes. SetHandler handlers work at the request level, protocol handlers at the connection level. > Also, I do not know, how to check that the > "handler is enabled for the current vhost". >From mod_echo.c: static int process_echo_connection(conn_rec *c) { EchoConfig *pConfig = ap_get_module_config(c->base_server->module_config, &echo_module); if (!pConfig->bEnabled) { return DECLINED; } Hope that helps.
Re: How to access client socket from a protocol handler
No, SetHandler should be ok, because mod_echo works fine. I've added the port number to my logs: ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, conn->base_server, "served socket policy to %s via %d", conn->remote_ip, conn->base_server->port); And now I see in the error_log: [notice] served socket policy to 127.0.0.1 via 843 [notice] served socket policy to 127.0.0.1 via 80 - depending on which port I called the "telnet localhost XXX" with. So should I check for the port != 843 and return DECLINED? It seems a bit awkward to me Regards Alex
Re: How to access client socket from a protocol handler
Thank you, but - On Sat, Oct 23, 2010 at 10:01 PM, Ben Noordhuis wrote: > Alexander, take a look at mod_echo.c (included in the source tarball). > It's a great example of how a protocol handler should work and it just > might convince you to use bucket brigades after all. :) > > You need to check if your handler is enabled for the current vhost. If > it's not, return DECLINED. If it is, look up the client socket and go > from there. > I've created a module using bb (the source code at the bottom) and it suffers from the same problem (hijacks the port 80 too). Could it be that "SetHandler" is a wrong directive for protocol handler? LoadModule socket_policy_module modules/mod_socket_policy.so Listen 843 SetHandler socket_policy Also, I do not know, how to check that the "handler is enabled for the current vhost". for (p = conn->base_server; p != NULL; p = p->next) /* and then? */ Regards Alex #include #include #include #include #include #define POLICY "\n" \ "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd\";>\n" \ "\n" \ "\n" \ "\0" static int socket_policy_handler(conn_rec *conn) { apr_bucket_brigade *bb; apr_bucket *b; apr_status_t rv; bb = apr_brigade_create(conn->pool, conn->bucket_alloc); b = apr_bucket_immortal_create(POLICY, sizeof(POLICY), bb->bucket_alloc); APR_BRIGADE_INSERT_TAIL(bb, b); b = apr_bucket_flush_create(conn->bucket_alloc); APR_BRIGADE_INSERT_TAIL(bb, b); b = apr_bucket_eos_create(bb->bucket_alloc); APR_BRIGADE_INSERT_TAIL(bb, b); rv = ap_pass_brigade(conn->output_filters, bb); if (rv != APR_SUCCESS) { ap_log_error(APLOG_MARK, APLOG_ERR, 0, conn->base_server, "output error"); return DECLINED; } ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, conn->base_server, "served socket policy to %s", conn->remote_ip); return OK; } static void register_hooks(apr_pool_t *pool) { ap_hook_process_connection(socket_policy_handler, NULL, NULL, APR_HOOK_MIDDLE); } module AP_MODULE_DECLARE_DATA socket_policy_module = { STANDARD20_MODULE_STUFF, NULL, NULL, NULL, NULL, NULL, register_hooks };
Re: How to access client socket from a protocol handler
Alexander, take a look at mod_echo.c (included in the source tarball). It's a great example of how a protocol handler should work and it just might convince you to use bucket brigades after all. :) You need to check if your handler is enabled for the current vhost. If it's not, return DECLINED. If it is, look up the client socket and go from there.
Re: How to access client socket from a protocol handler
Hello Ben, On Sat, Oct 23, 2010 at 2:08 PM, Ben Noordhuis wrote: > On Sat, Oct 23, 2010 at 10:13, Alexander Farber > wrote: > Your connection handler should return DECLINED for vhosts it doesn't > handle (I wager mod_perl did this for you). > > You can get the vhost with conn->base_server and your module's > per-server config with > ap_get_module_config(conn->base_server->module_config, &your_module). > sorry, but I don't understand - 1) your original suggestion was to use apr_socket_t *socket = ap_get_module_config(conn->conn_config, &core_module); but I don't understand why it returns a socket instead of a config struct? 2) And now you suggest to ap_get_module_config(conn->base_server->module_config, &your_module); Yes, I know that it will return a custom config struct for my module, which I can prepare/merge in the earlier handlers, but how does it help me to access the client socket for my VirtualHost at port 843 3) And finally you tell me to return DECLINED for vhosts my module doesn't handle, but how can I recognize them in my protocol handler? Regards Alex
Re: How to access client socket from a protocol handler
On Sat, Oct 23, 2010 at 10:13, Alexander Farber wrote: > I wonder why my mod_perl module works and the C one not. Your connection handler should return DECLINED for vhosts it doesn't handle (I wager mod_perl did this for you). You can get the vhost with conn->base_server and your module's per-server config with ap_get_module_config(conn->base_server->module_config, &your_module).
Re: Strange EOS bucket in filter
On Sat, Oct 23, 2010 at 12:55:05PM +0200, r...@tuxteam.de wrote: > On Sat, Oct 23, 2010 at 11:22:20AM +0100, Nick Kew wrote: > > > > On 23 Oct 2010, at 11:06, r...@tuxteam.de wrote: > > > > > > > > Hello list, > > > > > > I'm currently developing an output filter that , dpending on some > > > condition either parses all data to convert it (and hence don't pass any > > > of the incomming buckets down the pipe) or decides to leave the data as > > > it is and just pushes all incomming buckets down. Now, strangely, for > > > the second case every second request my filter only gets an EOS bucket > > > (as the first bucket te filter sees) for all resources that the filter > > > doesn't need to touch. This only seems to happen for requests with > > > keep-alive true. That somehow sounds like someting I've encoutered > > > before but I can't recall when or where :-/ Any ideas what's going on? > > > > Are you clearing all the input once you've consumed it? > > You mean input buckets that i get as a the brigade parameter in my > filter callback? Yes, at least mod_diagnostics shows an EOS buffer > comming from my filter as the last buffer for that request. > Strange > Ah, found some hint: this only happens when I run the request through a proxy (had accidently set http_proxy in my debugging shell ...). Hm: I can narrow this dow to a second request with an If-Modified-Since header with the same value as the last sent Last-Modified header. So 304/Not-Modified will still chase an EOF through the content filter chain? Good to know ... Thanks RalfD > > -- > > Nick Kew
Re: Strange EOS bucket in filter
On Sat, Oct 23, 2010 at 11:22:20AM +0100, Nick Kew wrote: > > On 23 Oct 2010, at 11:06, r...@tuxteam.de wrote: > > > > > Hello list, > > > > I'm currently developing an output filter that , dpending on some > > condition either parses all data to convert it (and hence don't pass any > > of the incomming buckets down the pipe) or decides to leave the data as > > it is and just pushes all incomming buckets down. Now, strangely, for > > the second case every second request my filter only gets an EOS bucket > > (as the first bucket te filter sees) for all resources that the filter > > doesn't need to touch. This only seems to happen for requests with > > keep-alive true. That somehow sounds like someting I've encoutered > > before but I can't recall when or where :-/ Any ideas what's going on? > > Are you clearing all the input once you've consumed it? You mean input buckets that i get as a the brigade parameter in my filter callback? Yes, at least mod_diagnostics shows an EOS buffer comming from my filter as the last buffer for that request. Strange Thanks RalfD > -- > Nick Kew
Re: Strange EOS bucket in filter
On 23 Oct 2010, at 11:06, r...@tuxteam.de wrote: > > Hello list, > > I'm currently developing an output filter that , dpending on some > condition either parses all data to convert it (and hence don't pass any > of the incomming buckets down the pipe) or decides to leave the data as > it is and just pushes all incomming buckets down. Now, strangely, for > the second case every second request my filter only gets an EOS bucket > (as the first bucket te filter sees) for all resources that the filter > doesn't need to touch. This only seems to happen for requests with > keep-alive true. That somehow sounds like someting I've encoutered > before but I can't recall when or where :-/ Any ideas what's going on? Are you clearing all the input once you've consumed it? -- Nick Kew
Strange EOS bucket in filter
Hello list, I'm currently developing an output filter that , dpending on some condition either parses all data to convert it (and hence don't pass any of the incomming buckets down the pipe) or decides to leave the data as it is and just pushes all incomming buckets down. Now, strangely, for the second case every second request my filter only gets an EOS bucket (as the first bucket te filter sees) for all resources that the filter doesn't need to touch. This only seems to happen for requests with keep-alive true. That somehow sounds like someting I've encoutered before but I can't recall when or where :-/ Any ideas what's going on? Cheers, Ralf Mattes
Re: How to access client socket from a protocol handler
On Sat, Oct 23, 2010 at 10:09 AM, Alexander Farber wrote: > http://perl.apache.org/dist/mod_perl-2.0-current/xs/Apache2/Connection/Apache2__Connection.h > > apr_socket_t *socket = > ap_get_module_config(c->conn_config, &core_module); > > if (s) { > ap_set_module_config(c->conn_config, &core_module, s); > } > > Maybe this ensures, that the custom perl protocol handler gets > the correct socket (the one bound at the port 843 and not 80)? No, they probably do it so that they can get/set socket... I wonder why my mod_perl module works and the C one not. Regards Alex
Re: How to access client socket from a protocol handler
Hello again, the http://perl.apache.org/dist/mod_perl-2.0-current/xs/Apache2/Connection/Apache2__Connection.h uses conn_config to get at the client socket as well, but I've also noticed that they pass an additional argument there: apr_socket_t *socket = ap_get_module_config(c->conn_config, &core_module); if (s) { ap_set_module_config(c->conn_config, &core_module, s); } Maybe this ensures, that the custom perl protocol handler gets the correct socket (the one bound at the port 843 and not 80)? In my C module, I probably get the wrong socket (the one at port 80)? I probably need to somehow walk through all the servers and find my VirtualHost which is listening at port 843? I've put my both modules and the problem description here: http://stackoverflow.com/questions/4002871/apache-module-in-c-how-to-write-data-to-client-socket Thank you Alex