Entire API reference List for v2.0 wanted!!
Hi all, Am looking out for a reference of all the Apache API's Revision changes. I.e Apache API v 1.3 v 2.0 revision changes in the API's What Could be the function prototypes entire API reference list for v2.0? Awaiting for a helping hand!! Warm Regards, --BENNY Benedict D'silva E-mail: [EMAIL PROTECTED] Software AG (India) Pvt Ltd. Ph: + 91-20-2663-0794 18, Viman Nagar, Ext No: 230 Pune - 411014.
Re: why modules/ssl keep on creating collisions on 'cvs up'
On Mon, Mar 01, 2004 at 11:53:00PM -0800, Stas Bekman wrote: 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 This should only happen very occasionally now in HEAD when one of the ssl_expr sources is modified (as happened recently) since buildconf will touch the files to ensure that make never regenerates them: rm modules/ssl/ssl_expr* cvs up ./buildconf to make it go away. Similarly build/PrintPath seems to be modified. That doesn't sound right. If thinds are generated they shouldn't be under cvs control. PrintPath should be fixed already too if you cvs up and buildconf. (I don't see why it needs to be under version control in httpd-2.0 since it could be copied from APR) Not keeping the ssl_expr* files under version control would mean Win32 etc then require yacc/lex to build mod_ssl, that's less clear cut. Regards, joe
Re: why modules/ssl keep on creating collisions on 'cvs up'
Joe Orton wrote: On Mon, Mar 01, 2004 at 11:53:00PM -0800, Stas Bekman wrote: 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 This should only happen very occasionally now in HEAD when one of the ssl_expr sources is modified (as happened recently) since buildconf will touch the files to ensure that make never regenerates them: rm modules/ssl/ssl_expr* cvs up ./buildconf to make it go away. That's what I was doing, but I was reluctant to put that in the build script, because you never remember those delete commands. But as you say they are autogenerated then I'll just the above trick. Similarly build/PrintPath seems to be modified. That doesn't sound right. If thinds are generated they shouldn't be under cvs control. PrintPath should be fixed already too if you cvs up and buildconf. (I don't see why it needs to be under version control in httpd-2.0 since it could be copied from APR) Not keeping the ssl_expr* files under version control would mean Win32 etc then require yacc/lex to build mod_ssl, that's less clear cut. Understood! Thanks Joe! __ 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: Entire API reference List for v2.0 wanted!!
* Benedict DSilva [EMAIL PROTECTED] wrote: What Could be the function prototypes entire API reference list for v2.0? http://httpd.apache.org/docs-2.0/developer/ should be the first place to look. Especially linked from there: http://docx.webperf.org/. nd
Re: RewriteCond and SSL environment variables
On Mon, Mar 01, 2004 at 10:37:46AM -0800, Mathihalli, Madhusudan wrote:
Hi,
Question: Can we use the environment variables setup by mod_ssl
in the RewriteCond directive ?
Not like in 1.3; in 2.0 you can use %{LA-U:ENV:...} to fetch the SSL
variables via a subrequest; a better solution is to extend mod_rewrite
to allow %{SSL:...} or something to use ssl_var_lookup() when available,
to fetch variables directly from mod_ssl.
joe
RE: Entire API reference List for v2.0 wanted!!
Thanks for your input!! Actually am looking out for a site similar to http://httpd.apache.org/dev/apidoc/index.html which would give me all the API reference for v2.0 Warm Regards, --BENNY From: André Malo [mailto:[EMAIL PROTECTED] Sent: Tue 3/2/2004 3:35 PM To: [EMAIL PROTECTED] Subject: Re: Entire API reference List for v2.0 wanted!! * Benedict DSilva [EMAIL PROTECTED] wrote: What Could be the function prototypes entire API reference list for v2.0? http://httpd.apache.org/docs-2.0/developer/ should be the first place to look. Especially linked from there: http://docx.webperf.org/. nd winmail.dat
Re: Bug? in 1.3 htdigest?
* Thom May ([EMAIL PROTECTED]) wrote :
Hey guys,
just wondering why we use system(copy...)/system(cp...) in htdigest in 1.3,
when the netware option seems to be more secure?
The patch attached just rips out the ifdef and uses the netware code
globally.
No complaints? Suggestions?
I'll commit tonight then?
-Thom
Index: htdigest.c
===
RCS file: /home/cvs/apache-1.3/src/support/htdigest.c,v
retrieving revision 1.39
diff -u -r1.39 htdigest.c
--- htdigest.c20 Feb 2004 22:02:24 - 1.39
+++ htdigest.c29 Feb 2004 18:50:18 -
@@ -152,7 +152,6 @@
}
-#ifdef NETWARE
static void copy_file(FILE *target, FILE *source)
{
static char line[MAX_STRING_LEN];
@@ -161,7 +160,6 @@
putline(target, line);
}
}
-#endif
int main(int argc, char *argv[])
{
@@ -239,14 +237,7 @@
}
fclose(f);
fclose(tfp);
-#ifndef NETWARE
-#if defined(OS2) || defined(WIN32)
-sprintf(command, copy \%s\ \%s\, tn, argv[1]);
-#else
-sprintf(command, cp %s %s, tn, argv[1]);
-#endif
-system(command);
-#else
+
if (!(tfp = fopen(tn, r))) {
fprintf(stderr, Could not open temp file.\n);
exit(1);
@@ -258,7 +249,6 @@
}
copy_file(f, tfp);
-#endif
unlink(tn);
return 0;
}
Re: FreeBSD 4.x and Apache2: worker MPM issue
On Mon, 1 Mar 2004, Justin Erenkrantz wrote: 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... Note that *BSD is looking at a 4.10 RSN, and I'm trying to fight for trying to get this fixed, if its possible, which is why I'm trying to come up with some data to fight with ... Is there anywhere that there is a summary of this gnarly stuff? Something you could point me at, that I can use/question? 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. k, changed it to: StartServers 3 MaxClients 150 MinSpareThreads 50 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 ps auxl (shows the parent id so that I can find all children) shows: pluto# ps auxl | grep 20098 root 20098 0.0 0.1 4516 2912 ?? Ss 11:44AM 0:00.06 /usr/local/sbin/ 0 20098 1 0 2 0 4516 2912 poll Ss??0:00.06 /usr/local/sbin/httpd www 20101 0.0 0.1 6408 3056 ?? S11:44AM 0:00.03 /usr/local/sbin/ 80 20101 20098 0 2 0 6408 3056 poll S ??0:00.03 /usr/local/sbin/httpd www 20102 0.0 0.1 6408 3056 ?? S11:44AM 0:00.02 /usr/local/sbin/ 80 20102 20098 0 2 0 6408 3056 poll S ??0:00.02 /usr/local/sbin/httpd www 20103 0.0 0.1 6408 3056 ?? S11:44AM 0:00.01 /usr/local/sbin/ 80 20103 20098 0 2 0 6408 3056 poll S ??0:00.01 /usr/local/sbin/httpd which is what I would expect ... now, running http_load with a rate of 2 (simple), I'm still left with those three processes ... 19 fetches, 1 max parallel, 28823 bytes, in 10.0108 seconds 1517 mean bytes/connection 1.89795 fetches/sec, 2879.19 bytes/sec msecs/connect: 157.772 mean, 189.588 max, 152.671 min msecs/first-response: 173.843 mean, 244.612 max, 160.396 min HTTP response codes: code 200 -- 19 increase it by 10x, still three, and a telnet/GET after still responsive: 192 fetches, 9 max parallel, 291264 bytes, in 10.0123 seconds 1517 mean bytes/connection 19.1764 fetches/sec, 29090.6 bytes/sec msecs/connect: 162.432 mean, 228.586 max, 152.396 min msecs/first-response: 174.894 mean, 221.808 max, 159.584 min HTTP response codes: code 200 -- 192 increase it to 50, jumped to four, then went back down to three, and a telnet/GET after still responsive: http_load -rate 50 -seconds 10 /tmp/urls 433 fetches, 77 max parallel, 656861 bytes, in 10.003 seconds 1517 mean bytes/connection 43.2871 fetches/sec, 65666.5 bytes/sec msecs/connect: 443.495 mean, 3411.55 max, 251.228 min msecs/first-response: 417.855 mean, 3750.21 max, 269.668 min HTTP response codes: code 200 -- 433 Great, so either it did get fixed at some point, and nobody has acknowledge it, or I'm really doing something wrong trying to trigger it :( that last one, if I read the notes on http_load, would have hit it 500 times in 10 seconds, which should have simulated a good load, I would have thought? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
Re: FreeBSD 4.x and Apache2: worker MPM issue
--On Tuesday, March 2, 2004 11:47 AM -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: Note that *BSD is looking at a 4.10 RSN, and I'm trying to fight for trying to get this fixed, if its possible, which is why I'm trying to come up with some data to fight with ... Is there anywhere that there is a summary of this gnarly stuff? Something you could point me at, that I can use/question? You'd have to look at the archives for [EMAIL PROTECTED] I would have been the one posting it along with David Reid and Aaron Bannert. We first looked at it in late 2001 and early 2002. This was coupled with issues with sendfile in libc_r that we got Alfred P. to fix. I'd look inside libc_r and see if someone committed some fixes to the scheduling and condition variable implementations recently. If so, then yah, someone might have fixed this. (Don't have the time to check the CVS history myself.) I also know that I checked this a few months ago on minotaur (ASF's CVS server), which is running 4.9-STABLE (from Nov 29 2003). So, if it got fixed, it's probably after that as it was still broken then. which is what I would expect ... now, running http_load with a rate of 2 (simple), I'm still left with those three processes ... Okay. Great, so either it did get fixed at some point, and nobody has acknowledge it, or I'm really doing something wrong trying to trigger it :( that last one, if I read the notes on http_load, would have hit it 500 times in 10 seconds, which should have simulated a good load, I would have thought? The only sure-fire reproduction case we had was to use two copies of telnet against the server. What happens if you don't use http_load at all? Yes, it's possible it's been fixed in 4.x; we know it's fixed in 5.2+ with libkse and libthr. But, the libc_r in 5.2 is still broken. -- justin
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: EOS is not being sent for HEAD requests
--On Monday, March 1, 2004 11:20 PM -0800 Stas Bekman [EMAIL PROTECTED] wrote: 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. That'd mean that a filter isn't passing it on as it should be. So, what filter loses it? Is it one of ours? Or, is it a custom one? As always, more details would be appreciated. -- justin
Re: making filters more efficient
--On Monday, March 1, 2004 10:58 PM -0800 Stas Bekman [EMAIL PROTECTED] wrote: 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. Correct. Because the EOS is generated by the request-level protocol handler (HTTP_IN). That's exactly how it is designed. If a connection input filter saw EOS, it'd signal end-of-connection not end-of-request. But, we don't even have EOC yet - Madhu's adding it for mod_ssl's purposes for the output chain. 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. There's been no data written by the time the response handler is called. So, the handler can always set the headers before it does the first write. Once a write is triggered, you must assume that the headers are sent. And, that's (almost) how it was in 1.3 as well. -- 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: making filters more efficient
Justin Erenkrantz wrote: --On Monday, March 1, 2004 10:58 PM -0800 Stas Bekman [EMAIL PROTECTED] wrote: 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. Correct. Because the EOS is generated by the request-level protocol handler (HTTP_IN). That's exactly how it is designed. If a connection input filter saw EOS, it'd signal end-of-connection not end-of-request. But, we don't even have EOC yet - Madhu's adding it for mod_ssl's purposes for the output chain. That sounds very incosistent. Why connection output filters do get the EOS bucket at the end of every HTTP request (which makes them HTTP aware, no?), but their brother input filters don't? Why it is not a problem with connection output filters? 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. There's been no data written by the time the response handler is called. So, the handler can always set the headers before it does the first write. Once a write is triggered, you must assume that the headers are sent. And, that's (almost) how it was in 1.3 as well. -- justin There are more complicated setups than just one simple script or a handler, where it could be hard to know whether the output headers set has been sent already or not. Granted that setup could write their own flag, which the rest of the application could use, but it sounds ideal for Apache to provide a set of state functions, which can tell you what exactly Apache is doing, whether it has completed something (sent headers) or has not completed (e.g. still parsing 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 11:20 PM -0800 Stas Bekman [EMAIL PROTECTED] wrote: 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. That'd mean that a filter isn't passing it on as it should be. So, what filter loses it? Is it one of ours? Or, is it a custom one? As always, more details would be appreciated. -- justin I'm just installing a passive snooper filter (one snooping on incoming connection and one on the outgoing) that passes the data through as is and dumps bbs contents and bucket types to error log. So it must be some of the core filters I believe. Here are the traces: HEAD /index.html connection input filter o bucket 1: HEAP [HEAD /index.html HTTP/1.0 ] connection input filter o bucket 1: HEAP [Host: localhost.localdomain:8529 ] connection input filter o bucket 1: HEAP [User-Agent: libwww-perl/5.76 ] connection input filter o bucket 1: HEAP [ ] connection output filter o bucket 1: HEAP [HTTP/1.1 200 OK Date: Tue, 02 Mar 2004 18:22:46 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 Last-Modified: Thu, 07 Aug 2003 19:13:15 GMT ETag: 23cb9-2d0-830a88c0 Accept-Ranges: bytes Content-Length: 720 Connection: close Content-Type: text/html ] connection output filter o bucket 1: FLUSH [] connection output filter o bucket 1: FLUSH [] No EOS as you can see Now issue GET /index.html connection input filter o bucket 1: HEAP [GET /index.html HTTP/1.0 ] connection input filter o bucket 1: HEAP [Host: localhost.localdomain:8529 ] connection input filter o bucket 1: HEAP [User-Agent: libwww-perl/5.76 ] connection input filter o bucket 1: HEAP [ ] connection output filter o bucket 1: HEAP [HTTP/1.1 200 OK Date: Tue, 02 Mar 2004 18:22:45 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 Last-Modified: Thu, 07 Aug 2003 19:13:15 GMT ETag: 23cb9-2d0-830a88c0 Accept-Ranges: bytes Content-Length: 720 Connection: close Content-Type: text/html ] connection output filter o bucket 1: MMAP [!-- WARNING: this file is generated, do not edit 01: /home/stas/apache.org/modperl-2.0/Apache-Test/lib/Apache/TestConfig.pm:739 02: /home/stas/apache.org/modperl-2.0/Apache-Test/lib/Apache/TestConfig.pm:756 03: /home/stas/apache.org/modperl-2.0/Apache-Test/lib/Apache/TestConfig.pm:1030 04: /home/stas/apache.org/modperl-2.0/Apache-Test/lib/Apache/TestConfig.pm:1233 05: /home/stas/apache.org/modperl-2.0/Apache-Test/lib/Apache/TestRun.pm:408 06: /home/stas/apache.org/modperl-2.0/Apache-Test/lib/Apache/TestRunPerl.pm:41 07: /home/stas/apache.org/modperl-2.0/Apache-Test/lib/Apache/TestRun.pm:589 08: /home/stas/apache.org/modperl-2.0/Apache-Test/lib/Apache/TestRun.pm:589 09: t/TEST:21 -- welcome to localhost:8529 ] o bucket 2: EOS [] connection output filter o bucket 1: FLUSH [] connection output filter o bucket 1: FLUSH [] EOS is there. __ 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: Entire API reference List for v2.0 wanted!!
* [EMAIL PROTECTED] wrote: Actually am looking out for a site similar to http://httpd.apache.org/dev/apidoc/index.html which would give me all the API reference for v2.0 You've found it. You may want to read my posting again. nd
Re: RewriteCond and SSL environment variables
* Joe Orton [EMAIL PROTECTED] wrote:
On Mon, Mar 01, 2004 at 10:37:46AM -0800, Mathihalli, Madhusudan wrote:
Hi,
Question: Can we use the environment variables setup by mod_ssl
in the RewriteCond directive ?
Not like in 1.3; in 2.0 you can use %{LA-U:ENV:...} to fetch the SSL
variables via a subrequest; a better solution is to extend mod_rewrite
to allow %{SSL:...} or something to use ssl_var_lookup() when available,
to fetch variables directly from mod_ssl.
Sounds good. But we'd need to hook the variable creation earlier anyway, since
ssl_var_lookup finally just uses r-subprocess_env.
And then -- we could just use %{ENV:...} :-)
nd
Re: Bug? in 1.3 htdigest?
* Thom May [EMAIL PROTECTED] wrote: * Thom May ([EMAIL PROTECTED]) wrote : Hey guys, just wondering why we use system(copy...)/system(cp...) in htdigest in 1.3, when the netware option seems to be more secure? The patch attached just rips out the ifdef and uses the netware code globally. No complaints? Suggestions? I'll commit tonight then? I'd suggest you start with 2.1 and propose it for backport. nd
mod_jk / mod_jk2 : help from specialists welcome
Hi to all,
I'm involved in jk/jk2 on tomcat and we wonder on tomcat-dev
if we should use translate in MIDDLE or FIRST position (specifying
that mod_rewrite to be the first in hooks chain).
I see in jk that we're using :
ap_hook_translate_name(jk_translate,NULL,NULL,APR_HOOK_MIDDLE);
and now in jk2 :
static const char * const aszPre[] = { mod_rewrite.c, NULL };
ap_hook_translate_name(jk2_translate, aszPre, NULL, APR_HOOK_FIRST);
What do you think of it ?
MIDDLE or FIRST but after mod_rewrite ?
Thanks for your help and advices !!!
RE: RewriteCond and SSL environment variables
-Original Message-
From: André Malo [mailto:[EMAIL PROTECTED]
[SNIP]
* Joe Orton [EMAIL PROTECTED] wrote:
On Mon, Mar 01, 2004 at 10:37:46AM -0800, Mathihalli,
Madhusudan wrote:
Hi,
Question: Can we use the environment variables setup by mod_ssl
in the RewriteCond directive ?
Not like in 1.3; in 2.0 you can use %{LA-U:ENV:...} to fetch the SSL
variables via a subrequest; a better solution is to extend
mod_rewrite
to allow %{SSL:...} or something to use ssl_var_lookup()
when available,
to fetch variables directly from mod_ssl.
Infact, I tried the LA-U:ENV logic - what happens is that for the very first request,
the env is NOT available - however, for any subsequent requests, the ENV shows up
correctly
Sounds good. But we'd need to hook the variable creation
earlier anyway, since
ssl_var_lookup finally just uses r-subprocess_env.
And then -- we could just use %{ENV:...} :-)
I guess so - I have a working patch. I'll post it after doing some testing.
-Madhu
Re: EOS is not being sent for HEAD requests
If you have mod_logio configured, this might be its doing. It replaces
the EOS with FLUSH. This is in order to make sure all output is counted
and logged properly for each request.
Here is the code from mod_logio that does that:
---
static apr_status_t logio_out_filter(ap_filter_t *f,
apr_bucket_brigade *bb) {
apr_bucket *b = APR_BRIGADE_LAST(bb);
/* End of data, make sure we flush */
if (APR_BUCKET_IS_EOS(b)) {
APR_BRIGADE_INSERT_TAIL(bb,
apr_bucket_flush_create(f-c-bucket_alloc));
APR_BUCKET_REMOVE(b);
apr_bucket_destroy(b);
}
return ap_pass_brigade(f-next, bb);
}
---
I remember trying without APR_BUCKET_REMOVE/apr_bucket_destroy, but that
kept giving me problems. This was long time ago and I don't remember
exactly what the nature of those problems.
Anyway, may be the culprit...
--
Bojan
Re: EOS is not being sent for HEAD requests
Bojan Smojver wrote:
If you have mod_logio configured, this might be its doing. It replaces
the EOS with FLUSH. This is in order to make sure all output is counted
and logged properly for each request.
Here is the code from mod_logio that does that:
---
static apr_status_t logio_out_filter(ap_filter_t *f,
apr_bucket_brigade *bb) {
apr_bucket *b = APR_BRIGADE_LAST(bb);
/* End of data, make sure we flush */
if (APR_BUCKET_IS_EOS(b)) {
APR_BRIGADE_INSERT_TAIL(bb,
apr_bucket_flush_create(f-c-bucket_alloc));
APR_BUCKET_REMOVE(b);
apr_bucket_destroy(b);
}
return ap_pass_brigade(f-next, bb);
}
---
I remember trying without APR_BUCKET_REMOVE/apr_bucket_destroy, but that
kept giving me problems. This was long time ago and I don't remember
exactly what the nature of those problems.
Anyway, may be the culprit...
Thanks Bojan, but no I don't use it.
It just shows how fragile the reliance on buckets to deliver information is.
Any filter may decide to do whatever it wants and if you get this kind of
problem how do you figure out where the problem is? Plug yourself into the
filter chain and watch which filter eats the bucket? Supposedly I can do that
on my machine. What happens to a user who can't do that? And even after
finding the faulty filter it'll take time to fix the problem. Meanwhile my
module will be unusable as long as users don't update the faulty filter. If I
didn't have to rely on other filters behaving well and my code is proper I
won't need to worry about things and spend time creating new things rather
than trying to find the faulty filter.
That's why I'd prefer for Apache to have an API for these events, in addition
to the meta buckets...
p.s. I have nothing against Bojan's mod_logio, but he just gave a good example
where a filter is not well behaved (by a non-existing well-behaved-filters
Apache spec).
__
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
On Wed, 2004-03-03 at 07:42, Stas Bekman wrote: ... but he just gave a good example where a filter is not well behaved (by a non-existing well-behaved-filters Apache spec). I'm not sure exactly why I can't have a FLUSH bucket followed by an EOS bucket, but I'm pretty sure I wanted to keep the EOS, it just that the filter wouldn't work properly that way :-(. Anyhow, if Apache 2.1 is different in that regard, maybe I should download the CVS stuff and give it another go. Also, if you remember, there was a thread a while back about multiple FILE buckets in the same brigade. That was causing dramas unless after each FILE bucket there was a FLUSH one. So, now in my own module, which creates a brigade with multiple FILE buckets, I have insert FLUSH after each one. I bet this isn't all that good for performance. -- Bojan
Re: EOS is not being sent for HEAD requests
On Wed, 3 Mar 2004, Bojan Smojver wrote:
If you have mod_logio configured, this might be its doing. It replaces
the EOS with FLUSH. This is in order to make sure all output is counted
and logged properly for each request.
That's bad. :)
If you have to do that, then something else is broken.
/* End of data, make sure we flush */
if (APR_BUCKET_IS_EOS(b)) {
APR_BRIGADE_INSERT_TAIL(bb,
apr_bucket_flush_create(f-c-bucket_alloc));
APR_BUCKET_REMOVE(b);
apr_bucket_destroy(b);
}
return ap_pass_brigade(f-next, bb);
}
---
I remember trying without APR_BUCKET_REMOVE/apr_bucket_destroy, but that
kept giving me problems. This was long time ago and I don't remember
exactly what the nature of those problems.
That would be a problem because then you'd have a FLUSH bucket *after*
your EOS bucket in brigade bb (or at least that's what I assume from the
context given here without actually pulling up the whole module), which is
illegal.
PS: a shorthand for APR_BUCKET_REMOVE()+apr_bucket_destroy() is
apr_bucket_delete().
--Cliff
Re: EOS is not being sent for HEAD requests
On Wed, 2004-03-03 at 10:27, Cliff Woolley wrote: That would be a problem because then you'd have a FLUSH bucket *after* your EOS bucket in brigade bb (or at least that's what I assume from the context given here without actually pulling up the whole module), which is illegal. I think the code I was trying out was actually slightly different. I was inserting FLUSH before the EOS with APR_BUCKET_INSERT_BEFORE. Anyway, I might try that with Apache 2.1 one of these days. No promises, however, some other stuff is keeping me pretty busy these days. PS: a shorthand for APR_BUCKET_REMOVE()+apr_bucket_destroy() is apr_bucket_delete(). Thanks. -- Bojan
A-T: making the debug tracing functionality usable in production?
I'm getting used to use: debug foo, [EMAIL PROTECTED] when writing my code and I want to continue using it in my real modules. The problem with Apache::TestTrace that even though you can control the tracing level, they aren't compile time checks. Meaning that it's going to be costly to keep trace calls in the production code. What I was thinking is to introduce a subclass of Apache::TestTrace, which will operate exactly the same as its parent. But it won't be possible to change the trace level post-compile time, which will allow to optimize away calls like 'debug' if the level is not right. Or do you think this functionality doesn't belong to the Apache::Test framework? __ 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: [...] The patch below fixes that. But I haven't written that code, so I don't know why it was written to specifically ignore any failures. So I'm hesitant to commit it. I've pinged Doug who wrote this code, and he said: i seem to recall it being intentional. if a module couldn't be compiled then don't try to test it. but i can't recall an example of such a case where ignoring the compile error would be reasonable. your patch seems fine. So if that works for you, Ken (i.e. it aborts 'make test') I'll commit it. __ 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
Rodent of Unusual Size wrote:
Stas Bekman wrote:
Rodent of Unusual Size wrote:
the options are correct, but the module isn't being created properly.
coolio, so now you know what the problem is ;)
actually, the options *aren't* correct for AIX and apache 1.3.
and in dealing with that, i found another set of '/' path
concatenation assumptions. here's a patch that seems to get
this working for apache 1.3 on aix.
looks ok to me, but please drop () around 'catfile' to be consistent with the
rest of the file.
I can't test it, though I'd assume that it's correct. please commit, Ken. And
please add a log entry in Changes.
thanks to bill stoddard for pointing out the weird and not-so-wonderful
link options needed for aix.
note the
my $makefile = $mod-{dir}/Makefile;
path concatenation assumption. i fixed that in the new sub i added
for aix, but left the original (and any others) alone..
What assumption are you talking about? Using '/'? so your change is to use
catfile?
my $makefile = catfile($mod-{dir}, 'Makefile');
__
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: Stas Bekman wrote: [...] The patch below fixes that. But I haven't written that code, so I don't know why it was written to specifically ignore any failures. So I'm hesitant to commit it. I've pinged Doug who wrote this code, and he said: i seem to recall it being intentional. if a module couldn't be compiled then don't try to test it. but i can't recall an example of such a case where ignoring the compile error would be reasonable. your patch seems fine. So if that works for you, Ken (i.e. it aborts 'make test') I'll commit it. Now committed. __ 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: What assumption are you talking about? Using '/'? so your change is to use catfile? yes. is good? or no? -- #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: What assumption are you talking about? Using '/'? so your change is to use catfile? yes. is good? or no? It depends: If the path is only ever handled internally by perl than you can always use '/' and it will do the right thing on any platform. When it interacts with external world than nothing is sure. So, yes, it's always a good idea to use catfile when building a path with a file, and catdir when it's only a directory path. But be careful when that path is then used as a part of URI in which case http://example/foo\bar won't make a happy URI since it may live on a non-win32 server, when the client is win32. But you know that already. This is just something I had tripped over several times. So yes, your change is good and if you would like to fix the main function, that would be great. __ 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
