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
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:
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
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
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 yo
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-se
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
> > > c
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
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
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
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_
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_c
12 matches
Mail list logo
