You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stas Bekman <st...@stason.org> on 2004/01/20 04:09:46 UTC
how to tell one request from another inside a connection filter over
keep-alive connection
If I'm inside an input connection filter and want to be able to tell one HTTP
request from another what should I do? Counting Content-length is ineffective,
and a won't work if C-L header is wrong.
I can tell the end of HTTP headers section from the request body, by matching
/^[\r\n]$/ while reading HTTP headers. But I see no token that tells me that
the body is done. Any filter examples I can look at?
Also, why there is no EOS token in connection level filters? if you had some
data buffered how do you know when to flush it?
With Keep-Alive requests I get some IMMORTAL bucket after the last request.
Not sure what it is. At the moment just snooping on the traffic.
Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: how to tell one request from another inside a connection filter
over keep-alive connection
Posted by Stas Bekman <st...@stason.org>.
Justin Erenkrantz wrote:
> --On Monday, March 1, 2004 11:57 PM -0800 Stas Bekman <st...@stason.org>
> wrote:
>
>> AP_FTYPE_PROTOCOL. But what difference does it make as long as it sees
>> the
>> HTTP headers?
>
>
> Because AP_FTYPE_PROTOCOL is request-level when you are using HTTP.
yes, but it won't see the headers, no?
> But, you should not be changing HTTP headers in a filter. You should be
> altering them in a post_read_request hook and add it to the table.
that could be too late for some purposes, e.g. if you want to change the HTTP
method I believe.
>>> I'm certain, a mod_pop3 wouldn't like HTTP filters on connection level.
>>
>>
>> I fail to see what it has to do with mod_pop3.
>>
>> If I run a connection filter that works on HTTP headers/requests I put it
>> inside a vhost, so it doesn't affect any other protocols.
>
>
> What you are suggesting is to make the connection-level filters aware of
> HTTP. Once again, that is *not* correct. The connection-level filters
> must be unaware of HTTP or things start to break.
>
> I'm not clear how to better explain this, but what you are trying to do
> is going against the core principles of our filter design. -- justin
I'm not aware of any document explaining the core principles of Apache 2
filter design. So obviously it's open to various interpretation, including
potentially erroneous ones. Or was such a spec written recently and I wasn't
aware of?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: how to tell one request from another inside a connection filter
over keep-alive connection
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, March 1, 2004 11:57 PM -0800 Stas Bekman <st...@stason.org> wrote:
> AP_FTYPE_PROTOCOL. But what difference does it make as long as it sees the
> HTTP headers?
Because AP_FTYPE_PROTOCOL is request-level when you are using HTTP.
But, you should not be changing HTTP headers in a filter. You should be
altering them in a post_read_request hook and add it to the table.
>> I'm certain, a mod_pop3 wouldn't like HTTP filters on connection level.
>
> I fail to see what it has to do with mod_pop3.
>
> If I run a connection filter that works on HTTP headers/requests I put it
> inside a vhost, so it doesn't affect any other protocols.
What you are suggesting is to make the connection-level filters aware of HTTP.
Once again, that is *not* correct. The connection-level filters must be
unaware of HTTP or things start to break.
I'm not clear how to better explain this, but what you are trying to do is
going against the core principles of our filter design. -- justin
Re: how to tell one request from another inside a connection filter
over keep-alive connection
Posted by Stas Bekman <st...@stason.org>.
André Malo wrote:
> * Stas Bekman <st...@stason.org> wrote:
>
>
>>>Why should a connection-level filter know about HTTP requests? --
>>>justin
>>
>>Because that's the only way to write a filter that processes HTTP headers
>>only.
>
>
> Hmm. FTPYPE_PROTOCOL (sp?) is for such a purpose. If it's no applicable,
> we'd need to fix *that*.
AP_FTYPE_PROTOCOL. But what difference does it make as long as it sees the
HTTP headers?
> I'm certain, a mod_pop3 wouldn't like HTTP filters on connection level.
I fail to see what it has to do with mod_pop3.
If I run a connection filter that works on HTTP headers/requests I put it
inside a vhost, so it doesn't affect any other protocols.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: how to tell one request from another inside a connection filter
over keep-alive connection
Posted by André Malo <nd...@perlig.de>.
* Stas Bekman <st...@stason.org> wrote:
> > Why should a connection-level filter know about HTTP requests? --
> > justin
>
> Because that's the only way to write a filter that processes HTTP headers
> only.
Hmm. FTPYPE_PROTOCOL (sp?) is for such a purpose. If it's no applicable,
we'd need to fix *that*.
I'm certain, a mod_pop3 wouldn't like HTTP filters on connection level.
nd
Re: how to tell one request from another inside a connection filter
over keep-alive connection
Posted by Stas Bekman <st...@stason.org>.
Justin Erenkrantz wrote:
> --On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman <st...@stason.org>
> wrote:
>
>> Answering my own question, the solution is to use conn->keepalives
>> counter
>> which is incremented at the end of each request. By storing the previous
>> count and comparing with the current count one can tell when a new
>> request
>> is coming in over the keepalive connection. This technique is now
>> documented
>> in the mod_perl land:
>
>
> Sorry, but I think something is off here.
>
> Why should a connection-level filter know about HTTP requests? -- justin
Because that's the only way to write a filter that processes HTTP headers
only. See: http://search.cpan.org/dist/Apache-Filter-HTTPHeadersFixup/
There are quite a few people who need this functionality. And it takes a few
lines perl of code to write a custom filter.
package MyFilter::in_append;
use base qw(Apache::Filter::HTTPHeadersFixup);
sub manip {
my ($class, $ra_headers) = @_;
my $header = "Donkey: Monkey\n";
push @$ra_headers, $header;
}
And you have a new header added. $ra_headers contains all the headers, so you
can manipulate them as well.
People find it very handy with proxies when all they need is to
add/remove/manipulate HTTP headers.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: how to tell one request from another inside a connection filter
over keep-alive connection
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman <st...@stason.org> wrote:
> Answering my own question, the solution is to use conn->keepalives counter
> which is incremented at the end of each request. By storing the previous
> count and comparing with the current count one can tell when a new request
> is coming in over the keepalive connection. This technique is now documented
> in the mod_perl land:
Sorry, but I think something is off here.
Why should a connection-level filter know about HTTP requests? -- justin
Re: how to tell one request from another inside a connection filter
over keep-alive connection
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> If I'm inside an input connection filter and want to be able to tell one
> HTTP request from another what should I do? Counting Content-length is
> ineffective, and a won't work if C-L header is wrong.
>
> I can tell the end of HTTP headers section from the request body, by
> matching /^[\r\n]$/ while reading HTTP headers. But I see no token that
> tells me that the body is done. Any filter examples I can look at?
>
> Also, why there is no EOS token in connection level filters? if you had
> some data buffered how do you know when to flush it?
>
> With Keep-Alive requests I get some IMMORTAL bucket after the last
> request. Not sure what it is. At the moment just snooping on the traffic.
Answering my own question, the solution is to use conn->keepalives counter
which is incremented at the end of each request. By storing the previous count
and comparing with the current count one can tell when a new request is coming
in over the keepalive connection. This technique is now documented in the
mod_perl land:
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Filters_over_KeepAlive_Connections
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com