Re: new one: rwrite on aix with 1.3
Stas Bekman wrote: Was httpd and the mod_test_rwrite.so module compiled with the same compiler? i presume so, since i just built and installed the server and the framework used the resulting apxs to build its module. but just to make sure, let me rung through it all again. one thing that's particularly irksome is that this error occurs and blocks execution even if i have apache.rwrite in the t/SKIP file. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp!
Re: new one: rwrite on aix with 1.3
Stas Bekman wrote:
Was httpd and the mod_test_rwrite.so module compiled with the same compiler?
just went through and reconfigured the server build, built it, installed
it, cleaned out the .so files in the framework tree, and re-ran
t/TEST -{stop,clean,configure) and then t/TEST . same results.
how could i tell how the module was built?
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
Millennium hand and shrimp!
Re: new one: rwrite on aix with 1.3
Rodent of Unusual Size wrote:
Stas Bekman wrote:
Was httpd and the mod_test_rwrite.so module compiled with the same compiler?
just went through and reconfigured the server build, built it, installed
it, cleaned out the .so files in the framework tree, and re-ran
t/TEST -{stop,clean,configure) and then t/TEST . same results.
it doesn't mean that the compiler and the same compile options were used,
does it?
how could i tell how the module was built?
by looking at the output of 'make test' (after 'make clean').
p.s. I'm not on AIX, so I'm just guessing here.
__
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: new one: rwrite on aix with 1.3
Stas Bekman wrote:
just went through and reconfigured the server build, built it, installed
it, cleaned out the .so files in the framework tree, and re-ran
t/TEST -{stop,clean,configure) and then t/TEST . same results.
it doesn't mean that the compiler and the same compile options were used,
does it?
should be, since the apxs file store the compiler and options so that
modules will be built the same way.
how could i tell how the module was built?
by looking at the output of 'make test' (after 'make clean').
nothing there suggests that it's being built with anything other than the
standard options.
okey, cding down into perl-framework/c-modules/test_rwrite and
rm mod_test_rwrite.so
make mod_test_rwrite.so
/home/coar/web/server/bin/apxs -DAPACHE1
-I/home/coar/ibm/testpak/perl-framework/c-modules -c mod_test_rwrite.c
xlc -DAIX=510 -U__STR__ -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -DUSE_EXPAT
-I../lib/expat-lite -g -O2 -DSHARED_MODULE -I/home/coar/web/server/include
-I/home/coar/ibm/testpak/perl-framework/c-modules -DAPACHE1 -c
mod_test_rwrite.c
ld -H512 -T512 -bhalt:4 -bM:SRE -bnoentry
-bI:/home/coar/web/server/libexec/httpd.exp -lc -o mod_test_rwrite.so
mod_test_rwrite.o
ld: 0711-244 ERROR: No csects or exported symbols have been saved.
apxs:Break: Command failed with rc=8
make: 1254-004 The error code from the last command is 1.
the options are correct, but the module isn't being created properly.
so, two problems here:
1. what needs to be done to get the module to build correctly? (working
on that; it's obviously some bogus aix thing)
2. the framework needs to varf and bail out if it gets errors building
its modules -- currently it ignores the error status, evidently.
i'll tackle the former, while maybe stas can look at the latter.
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
Millennium hand and shrimp!
Re: new one: rwrite on aix with 1.3
Rodent of Unusual Size wrote: -bI:/home/coar/web/server/libexec/httpd.exp -lc -o mod_test_rwrite.so mod_test_rwrite.o ld: 0711-244 ERROR: No csects or exported symbols have been saved. apxs:Break: Command failed with rc=8 make: 1254-004 The error code from the last command is 1. the options are correct, but the module isn't being created properly. coolio, so now you know what the problem is ;) so, two problems here: 1. what needs to be done to get the module to build correctly? (working on that; it's obviously some bogus aix thing) 2. the framework needs to varf and bail out if it gets errors building its modules -- currently it ignores the error status, evidently. i'll tackle the former, while maybe stas can look at the latter. may be ;) __ 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
new one: rwrite on aix with 1.3
the same sources configured the same way on linux runs fine, but on aix i get: /home/coar/web/server/bin/httpd -d /home/coar/ibm/testpak/perl-framework/t -f /home/coar/ibm/testpak/perl-framework/t/conf/httpd.conf -DAPACHE1 using Apache/1.3.30-dev waiting 60 seconds for server to start: .Syntax error on line 138 of /home/coar/ibm/testpak/perl-framework/t/conf/httpd.conf: Can't locate API module structure `test_rwrite_module' in file /home/coar/ibm/testpak/perl-framework/c-modules/test_rwrite/mod_test_rwrite.so: Function not implemented (test_rwrite_module) . waiting 60 seconds for server to start: giving up after 61 secs [ error] server failed to start! (t/logs/error_log wasn't created, start the server in the debug mode) anyone seen anything like this before? -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp!
Re: FreeBSD 4.x and Apache2: worker MPM issue
On Sun, 29 Feb 2004, Justin Erenkrantz wrote: --On Sunday, February 29, 2004 4:06 PM -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: k, if I'm understanding what you are saying, how do you test something like that in a way that you can debug it? What I'm reading is that if I sent two queries (GET / and, say, GET /subdir), there is a chance that the one that sent GET / will get the results for GET /subdir? No, that's not quite the problem. It is: 1. Client requests GET / 2. *nothing happens* 3. Client (same or different) requests GET /subdir/ 4. Server responds to GET / request issued in #1 (to the correct client) 5. *nothing happens* 6. Someone requests GET /subdir/foo/ issued in #3 7. Server responds to GET /subdir/ request 8. *nothing happens* ...repeat cycle... Does this make more sense? The server won't respond to the first request until the second request is issued and so on. We think it's a flaw in how libc_r implements the pthread condition variables. But, again, it's been fixed with the thread library rewrites in 5.2. -- justin 'k, this makes more sense ... but, is there no way to 'trigger' it to debug? As I said, I ran http_load at it, oh, wait, I wouldn't see the problem with http_load, since, of course, its getting hit one after the other, so masking it ... but, again, there has to be a trigger somewhere, because results of http_load: 1981 fetches, 1017 max parallel, 2.99152e+06 bytes, in 30.0021 seconds 1510.11 mean bytes/connection 66.0286 fetches/sec, 99710.4 bytes/sec msecs/connect: 1688.24 mean, 16187.5 max, 152.65 min msecs/first-response: 1578.06 mean, 18004.3 max, 168.112 min 9 bad byte counts HTTP response codes: code 200 -- 1972 so I've effectively 'pounded' the server, followed by a telnet session to the same server doing a 'GET /' and it returned right away: 24.222.46.208 - - [01/Mar/2004:11:32:32 -0400] GET / HTTP/1.0 200 1517 - http_load 04jan2002 24.222.46.208 - - [01/Mar/2004:11:32:42 -0400] GET / 200 1517 - - checking my server: pluto# /usr/local/sbin/httpd -l Compiled in modules: core.c worker.c http_core.c mod_so.c I believe I'm compiled right ... checking my backends, I seem to have alot more then I'm expecting to have: pluto# ps auxl | grep 10231 root 10231 0.0 0.0 2296 1420 ?? Ss4Feb04 3:47.82 /usr/local/sbin/ 0 10231 1 0 2 0 2296 1420 select Ss??3:47.82 /usr/local/sbin/httpd www 10265 0.0 0.0 2720 1784 ?? I 4Feb04 0:03.80 /usr/local/sbin/ 80 10265 10231 0 2 0 2720 1784 accept I ??0:03.80 /usr/local/sbin/httpd www 10266 0.0 0.0 2648 1724 ?? I 4Feb04 0:03.91 /usr/local/sbin/ 80 10266 10231 0 2 0 2648 1724 accept I ??0:03.91 /usr/local/sbin/httpd www 10267 0.0 0.0 2720 1780 ?? I 4Feb04 0:04.12 /usr/local/sbin/ 80 10267 10231 0 2 0 2720 1780 accept I ??0:04.12 /usr/local/sbin/httpd www 10268 0.0 0.0 2648 1736 ?? I 4Feb04 0:03.74 /usr/local/sbin/ 80 10268 10231 0 2 0 2648 1736 accept I ??0:03.74 /usr/local/sbin/httpd www 10269 0.0 0.0 2644 1760 ?? I 4Feb04 0:03.86 /usr/local/sbin/ 80 10269 10231 0 2 0 2644 1760 accept I ??0:03.86 /usr/local/sbin/httpd www 13919 0.0 0.0 2644 1756 ?? I 4Feb04 0:04.26 /usr/local/sbin/ 80 13919 10231 0 2 0 2644 1756 accept I ??0:04.26 /usr/local/sbin/httpd www 52484 0.0 0.0 2644 1728 ?? I 5Feb04 0:03.93 /usr/local/sbin/ 80 52484 10231 0 2 0 2644 1728 accept I ??0:03.93 /usr/local/sbin/httpd www 31428 0.0 0.0 2644 1748 ?? I 7Feb04 0:03.82 /usr/local/sbin/ 80 31428 10231 0 2 0 2644 1748 accept I ??0:03.82 /usr/local/sbin/httpd www 31452 0.0 0.0 2644 1740 ?? I 7Feb04 0:03.71 /usr/local/sbin/ 80 31452 10231 0 2 0 2644 1740 accept I ??0:03.71 /usr/local/sbin/httpd www 85079 0.0 0.0 2644 1732 ?? I17Feb04 0:03.71 /usr/local/sbin/ 80 85079 10231 0 2 0 2644 1732 accept I ??0:03.71 /usr/local/sbin/httpd www 57616 0.0 0.0 2572 1736 ?? I11:31AM 0:00.20 /usr/local/sbin/ 80 57616 10231 0 2 0 2572 1736 accept I ??0:00.20 /usr/local/sbin/httpd www 57619 0.0 0.0 2572 1736 ?? I11:31AM 0:00.16 /usr/local/sbin/ 80 57619 10231 0 2 0 2572 1736 accept I ??0:00.16 /usr/local/sbin/httpd www 57620 0.0 0.0 2572 1736 ?? I11:31AM 0:00.16 /usr/local/sbin/ 80 57620 10231 0 2 0 2572 1736 accept I ??0:00.16 /usr/local/sbin/httpd www 57627 0.0 0.0 2572 1736 ?? I11:31AM 0:00.12 /usr/local/sbin/ 80 57627 10231 0 2 0 2572 1736 accept I ??0:00.12 /usr/local/sbin/httpd www 57628 0.0 0.0 2572 1736 ?? I11:31AM 0:00.12 /usr/local/sbin/ 80 57628 10231 0 2 0 2572 1736 accept I ??
RewriteCond and SSL environment variables
Hi, Question: Can we use the environment variables setup by mod_ssl in the RewriteCond directive ? I believe there's some inconsistency there - the SSL environment variables are setup in the r-subprocess_env during the hook_fixup phase, where as the RewriteCond evaluates/expands the environment variables during the hook_translatename phase (which happens before the hook_fixup). As a result, the SSL variables don't get expanded on the first connection - but it happens for subsequent connections ! -Madhu
RE: RewriteCond and SSL environment variables
BTW, I forgot to mention that RewriteCond with SSL variables work if (1) ssl_hook_Translate is APR_HOOK_FIRST and (2) ssl_hook_Fixup logic is transferred to ssl_hook_Translate. I know it's a hack - do you think my config is not setup correctly or is the logic wrong ? -Madhu -Original Message- From: Mathihalli, Madhusudan Sent: Monday, March 01, 2004 10:38 AM To: [EMAIL PROTECTED] Subject: RewriteCond and SSL environment variables Hi, Question: Can we use the environment variables setup by mod_ssl in the RewriteCond directive ? I believe there's some inconsistency there - the SSL environment variables are setup in the r-subprocess_env during the hook_fixup phase, where as the RewriteCond evaluates/expands the environment variables during the hook_translatename phase (which happens before the hook_fixup). As a result, the SSL variables don't get expanded on the first connection - but it happens for subsequent connections ! -Madhu
EOS is not being sent for HEAD requests
in 2.0 - Connection output filters don't recieve the EOS bucket when the request method is HEAD. This breaks the idiom of flushing any stored data when the eos bucket is seen. And some filters could be broken because of that. A typical response filter sees this for the following 3 brigades for a HEAD request which otherwise would have sent a response body: connection output filter o bucket 1: HEAP [HTTP/1.1 200 OK Date: Tue, 02 Mar 2004 04:04:30 GMT Server: Apache/2.0.49-dev (Unix) mod_perl/1.99_13-dev Perl/v5.8.3 mod_ssl/2.0.49-dev OpenSSL/0.9.7b DAV/2 Connection: close Content-Type: text/plain ] connection output filter o bucket 1: FLUSH [] connection output filter o bucket 1: FLUSH [] __ 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
making filters more efficient
It'd be very helpful if Apache provided methods to query various in and out stream processing events to make filters more efficient. The events I can think at the moment are: - end of HTTP input headers - end of HTTP input body - end of HTTP response headers - end of HTTP response body only the latter is sort of accessible via the EOS bucket (which as I've pointed out in another email is not always set!). Ideally the connection record could have the following entries: done_with_input_headers done_with_input_body done_with_output_headers done_with_output_body so for example when http headers processing is completed, the done_with_input_headers flag will go up. etc. These flags will be reset at the end of each request. At the moment it's sort of possible to workout all these events from the filter itself, but it's *very* inefficient and makes the code fragile if Apache needs to change the internals. Matching for /\n\n/ on every bucket just to know when the headers are done with, is just plain bad, when the Apache core filter knows already when this event happens and it could share that knowledge with other filters. __ 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: making filters more efficient
* Stas Bekman [EMAIL PROTECTED] wrote: Ideally the connection record could have the following entries: done_with_input_headers done_with_input_body done_with_output_headers done_with_output_body no other comments atm, but this isn't really ideal. The connection does not know anything about concepts like HTTP. (or should however). Perhaps we should introduce a structure stub pointer for connection type related things, private to all functions below process_*_connection. so for example when http headers processing is completed, the done_with_input_headers flag will go up. etc. These flags will be reset at the end of each request. Or should it simply be in the request struct? nd
Re: EOS is not being sent for HEAD requests
* Stas Bekman [EMAIL PROTECTED] wrote: in 2.0 - Connection output filters don't recieve the EOS bucket when the request method is HEAD. This breaks the idiom of flushing any stored data when the eos bucket is seen. And some filters could be broken because of that. I believe that is because of broken handlers, which don't send anything if they detect HEAD. In 2.0 a handler should not care about GET or HEAD, but send all the time its data, so that all the processing (C-L filter etc) works properly. nd
Re: making filters more efficient
André Malo wrote: * Stas Bekman [EMAIL PROTECTED] wrote: Ideally the connection record could have the following entries: done_with_input_headers done_with_input_body done_with_output_headers done_with_output_body no other comments atm, but this isn't really ideal. The connection does not know anything about concepts like HTTP. (or should however). Perhaps we should introduce a structure stub pointer for connection type related things, private to all functions below process_*_connection. There is no way this could be solved in 2.0, right? so for example when http headers processing is completed, the done_with_input_headers flag will go up. etc. These flags will be reset at the end of each request. Or should it simply be in the request struct? Yup, I had that idea too. That works for me as long as you can access it via the connection filter variable. I'm not sure about the fine details. e.g. the scope of request's life and the last invocation of the connection filter. __ 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: EOS is not being sent for HEAD requests
André Malo wrote: * Stas Bekman [EMAIL PROTECTED] wrote: in 2.0 - Connection output filters don't recieve the EOS bucket when the request method is HEAD. This breaks the idiom of flushing any stored data when the eos bucket is seen. And some filters could be broken because of that. I believe that is because of broken handlers, which don't send anything if they detect HEAD. In 2.0 a handler should not care about GET or HEAD, but send all the time its data, so that all the processing (C-L filter etc) works properly. I see that with a non-broken handler which sends the response body unconditionally. The output I've posted in my original email is all that's seen by an output connection filter. Besides, shouldn't the output connection filter see the response data nevertheless? otherwise how can you calculate a correct C-L when the filter weren't given a change to change the data, potentially changing its length. I'm talking about dynamic handlers, not static data here. __ 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: making filters more efficient
--On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman [EMAIL PROTECTED] wrote: It'd be very helpful if Apache provided methods to query various in and out stream processing events to make filters more efficient. The events I can think at the moment are: ... - end of HTTP input headers I'm not sure that this is helpful because input filters aren't supposed to know about the input headers. The headers are read before the HTTP input filters are 'installed' at the end of ap_read_request (i.e. no request-level input filters are installed until *after* the headers are read - which, of course, makes sense). - end of HTTP input body An EOS *is* generated for this. - end of HTTP response headers As soon as the first write is sent, it should be assumed that the headers are written. That is, if you want to change the headers and you are an output filter, you *must* change it on the first write you intercept. - end of HTTP response body An EOS is sent for this. Ideally the connection record could have the following entries: done_with_input_headers done_with_input_body done_with_output_headers done_with_output_body As nd pointed out, this is completely invalid as that'd mean that the connections now know about the underlying protocol and that violates our abstraction. The impression I got from this email is that you want connection-level filters to know about HTTP, and I'm not sure I agree with that. If a connection-level filter needs to know HTTP, I don't think it should be a connection-level filter. -- justin
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: EOS is not being sent for HEAD requests
--On Monday, March 1, 2004 9:55 PM -0800 Stas Bekman [EMAIL PROTECTED] wrote: I see that with a non-broken handler which sends the response body unconditionally. The output I've posted in my original email is all that's seen by an output connection filter. Why is ap_finalize_request_protocol not being called? That is the code that should be ensuring that EOS is passed down even if the handler is 'broken.' -- justin
Re: FreeBSD 4.x and Apache2: worker MPM issue
--On Monday, March 1, 2004 11:37 AM -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: so I've effectively 'pounded' the server, followed by a telnet session to the same server doing a 'GET /' and it returned right away: See below, I think you only have one worker process running. You need multiple process to trigger it. What we believed was that it was related to race conditions inside the OS scheduler handler where our poll calls got mixed up with the scheduler's polls. We had it tracked down to some gnarly stuff inside the libc_r scheduler and gave up... so am I mis-configuring something? I'm running the default httpd.conf, and the worker stuff is setup as: IfModule worker.c StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 /IfModule so I would have expected no more then 4 processes to be running, no? Well, I'd expect it to be no more than 6 (150 / 25). But, yah, I'm not making sense of your 'ps auxl' output either. Is it possible that FreeBSD is showing the threads as processes? That'd make the count about right if there is only one process. (Linux used to do that, but I forget *BSD's behavior.) I also know that you must have two worker processes to trigger it. You may need to set 'MinSpareThreads' to 50 to ensure that you always have two processes up. If you look in STATUS (FreeBSD, threads, and worker MPM entry) that is the other pre-requisite. I'm guessing that the MaxRequestsPerChild == 0 means unlimited? Should, yah. -- justin
Re: making filters more efficient
Justin Erenkrantz wrote: --On Monday, March 1, 2004 8:18 PM -0800 Stas Bekman [EMAIL PROTECTED] wrote: It'd be very helpful if Apache provided methods to query various in and out stream processing events to make filters more efficient. The events I can think at the moment are: ... - end of HTTP input headers I'm not sure that this is helpful because input filters aren't supposed to know about the input headers. The headers are read before the HTTP input filters are 'installed' at the end of ap_read_request (i.e. no request-level input filters are installed until *after* the headers are read - which, of course, makes sense). I'm talking about connection filters which process HTTP requests, not HTTP body filters. HTTP body filters don't need this knowledge since they never see headers. At least do you agree that scanning for /\n\n/ is very inefficient, and an unneeded operation when Apache has already done that. - end of HTTP input body An EOS *is* generated for this. It does in the request filter (in and out). It does in the connection output filter. It does *not* in the connection input filter. I've just double checked. - end of HTTP response headers As soon as the first write is sent, it should be assumed that the headers are written. That is, if you want to change the headers and you are an output filter, you *must* change it on the first write you intercept. Yes, this is how it works. There is no API to tell you that. e.g. what if you want to check from the response handler whether Apache has already sent the headers or not? In 1.3 the user controlled that, but that's not the case in 2.0. The moment something sends the output the headers are flushed. that something at times could be an empty bucket when an uninitented flush triggers data out. - end of HTTP response body An EOS is sent for this. Indeed. Ideally the connection record could have the following entries: done_with_input_headers done_with_input_body done_with_output_headers done_with_output_body As nd pointed out, this is completely invalid as that'd mean that the connections now know about the underlying protocol and that violates our abstraction. The impression I got from this email is that you want connection-level filters to know about HTTP, and I'm not sure I agree with that. If a connection-level filter needs to know HTTP, I don't think it should be a connection-level filter. -- justin Only connection level filters can see HTTP headers, and they need to know about HTTP and they do know (core http filters). I'm not suggesting to make the connection structure HTTP dependant. I'm just looking for a more efficient way to write filters. And I'm all ears for the proper design. For example a connection record could have an member similar to the context, which could store protocol specific information. So for example the http protocol could store the above information in that structure and have accessors to read/write it. Besides the connection structure is not clean of HTTP stuff at the moment. All this KeepAlive stuff is httpd specific and from what I can see is used (set) only inside http_protocol.c. Granted, other protocols may find per-use those members. __ 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
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: EOS is not being sent for HEAD requests
Justin Erenkrantz wrote: --On Monday, March 1, 2004 9:55 PM -0800 Stas Bekman [EMAIL PROTECTED] wrote: I see that with a non-broken handler which sends the response body unconditionally. The output I've posted in my original email is all that's seen by an output connection filter. Why is ap_finalize_request_protocol not being called? That is the code that should be ensuring that EOS is passed down even if the handler is 'broken.' -- justin I've stepped through with gdb, ap_finalize_request_protocol is called and EOS is sent, but it gets lost and doesn't reach the connection output filter. __ 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
why modules/ssl keep on creating collisions on 'cvs up'
There must be some simple explanation, but this is very annoying as 'cvs up' in httpd-2.0 keeps on colliding at these files: M modules/ssl/ssl_expr_parse.c M modules/ssl/ssl_expr_parse.h M modules/ssl/ssl_expr_scan.c I never touch anything under httpd-2.0/modules/ssl. But the build process messes up with them. Am I the only one having this problem? I build with: make distclean ./buildconf CFLAGS=-DAP_UNSAFE_ERROR_LOG_UNESCAPED ./configure --prefix=/home/stas/httpd/worker \ --with-mpm=worker \ --enable-maintainer-mode \ --enable-so --enable-shared\ --enable-auth-anon --enable-maintainer-mode \ --enable-auth-dbm --enable-auth-db--enable-auth-digest \ --enable-file-cache --enable-echo --enable-cache \ --enable-mime-magic --enable-usertrack --enable-vhost-alias \ --enable-cern-meta --enable-expires--enable-headers \ --enable-unique-id --enable-proxy --enable-proxy-connect \ --enable-proxy-ftp --enable-proxy-http --enable-dav \ --enable-suexec --enable-cgi--enable-dav-fs\ --enable-rewrite--enable-info --enable-deflate \ --enable-ssl --with-ssl=/usr/include/ make make install Similarly build/PrintPath seems to be modified. That doesn't sound right. If thinds are generated they shouldn't be under cvs control. __ 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
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
