Re: how to tell one request from another inside a connection filter over keep-alive connection
--On Monday, March 1, 2004 11:57 PM -0800 Stas Bekman [EMAIL PROTECTED] 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
Justin Erenkrantz wrote: --On Monday, March 1, 2004 11:57 PM -0800 Stas Bekman [EMAIL PROTECTED] 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 BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] 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
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 BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] 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
--On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman [EMAIL PROTECTED] 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
Justin Erenkrantz wrote:
--On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman [EMAIL PROTECTED]
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 BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] 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
* Stas Bekman [EMAIL PROTECTED] 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
Andr Malo wrote: * Stas Bekman [EMAIL PROTECTED] 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 BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
