Bug report for Apache httpd-1.3 [2008/10/19]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |10744|New|Nor|2002-07-12|suexec might fail to open log file| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |10760|New|Maj|2002-07-12|empty ftp directory listings from cached ftp direc| |14518|Opn|Nor|2002-11-13|QUERY_STRING parts not incorporated by mod_rewrite| |16013|Opn|Nor|2003-01-13|Fooling mod_autoindex + IndexIgnore | |16631|Inf|Min|2003-01-31|.htaccess errors logged outside the virtual host l| |17318|Inf|Cri|2003-02-23|Abend on deleting a temporary cache file if proxy | |19279|Inf|Min|2003-04-24|Invalid chmod options in solaris build| |21637|Inf|Nor|2003-07-16|Timeout causes a status code of 200 to be logged | |21777|Inf|Min|2003-07-21|mod_mime_magic doesn't handle little gif files| |22618|New|Maj|2003-08-21|MultiViews invalidates PATH_TRANSLATED if cgi-wrap| |25057|Inf|Maj|2003-11-27|Empty PUT access control in .htaccess overrides co| |26126|New|Nor|2004-01-14|mod_include hangs with request body | |26152|Ass|Nor|2004-01-15|Apache 1.3.29 and below directory traversal vulner| |26790|New|Maj|2004-02-09|error deleting old cache file | |29257|Opn|Nor|2004-05-27|Problem with apache-1.3.31 and mod_frontpage (dso,| |29498|New|Maj|2004-06-10|non-anonymous ftp broken in mod_proxy | |29538|Ass|Enh|2004-06-12|No facility used in ErrorLog to syslog| |30207|New|Nor|2004-07-20|Piped logs don't close read end of pipe | |30877|New|Nor|2004-08-26|htpasswd clears passwd file on Sun when /var/tmp i| |30909|New|Cri|2004-08-28|sporadic segfault resulting in broken connections | |31975|New|Nor|2004-10-29|httpd-1.3.33: buffer overflow in htpasswd if calle| |32078|New|Enh|2004-11-05|clean up some compiler warnings | |32539|New|Trv|2004-12-06|[PATCH] configure --enable-shared= brocken on SuSE| |32974|Inf|Maj|2005-01-06|Client IP not set | |33086|New|Nor|2005-01-13|unconsistency betwen 404 displayed path and server| |33495|Inf|Cri|2005-02-10|Apache crashes with WSADuplicateSocket failed for| |33772|New|Nor|2005-02-28|inconsistency in manual and error reporting by sue| |33875|New|Enh|2005-03-07|Apache processes consuming CPU| |34108|New|Nor|2005-03-21|mod_negotiation changes mtime to mtime of Document| |34114|New|Nor|2005-03-21|Apache could interleave log entries when writing t| |34404|Inf|Blk|2005-04-11|RewriteMap prg can not handle fpout | |34571|Inf|Maj|2005-04-22|Apache 1.3.33 stops logging vhost| |34573|Inf|Maj|2005-04-22|.htaccess not working / mod_auth_mysql| |35424|New|Nor|2005-06-20|httpd disconnect in Timeout on CGI| |35439|New|Nor|2005-06-21|Problem with remove /../ in util.c and mod_rewri| |35547|Inf|Maj|2005-06-29|Problems with libapreq 1.2 and Apache::Cookie | |3|New|Nor|2005-06-30|Can't find DBM on Debian Sarge| |36375|Opn|Nor|2005-08-26|Cannot include http_config.h from C++ file| |37166|New|Nor|2005-10-19|Under certain conditions, mod_cgi delivers an empt| |37185|New|Enh|2005-10-20|AddIcon, AddIconByType for OpenDocument format| |37252|New|Reg|2005-10-26|gen_test_char reject NLS string | |38989|New|Nor|2006-03-15|restart + piped logs stalls httpd for 24 minutes (| |39104|New|Enh|2006-03-25|[FR] fix build with -Wl,--as-needed | |39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn| |39937|New|Nor|2006-06-30|Garbage output if README.html is gzipped or compre| |40176|New|Nor|2006-08-03|magic and mime| |40224|Ver|Nor|2006-08-10|System time crashes Apache @year 2038 (win32 only?| |41279|New|Nor|2007-01-02|Apache 1.3.37 htpasswd is vulnerable to buffer ove| |42355|New|Maj|2007-05-08|Apache 1.3 permits non-rfc HTTP error code = 600 | |43626|New|Maj|2007-10-15|r-path_info returning invalid value |
Re: CRL verification in mod_ssl
2008/10/20 Erwann ABALEA [EMAIL PROTECTED]: What is the decision criteria to reload a CRL? expiration of the notAfter date? An application based period would be better. s/notAfter/nextUpdate/ -- Erwann.
Re: strange usage pattern for child processes
On 10/18/08 4:28 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Also consider today that a server on broadband can easily spew 1gb/sec bandwidth at the client. If this is composed content (or proxied, etc, but not sendfiled) it would make sense to allow multiple buffer pages and/or resizing buffer pages, in a Location or Files or Proxy specific context. Would not the generic store-and-forward approach I sent last week help all of these situations? It effective turns any request into a sendfiled response. Let me do some checking and I may be able to just donate the code, since it's basically a very hacked up mod_deflate crossed with mod_xsendfile. It works for us, but we don't use the stock proxy, so not 100% it will help if the frontend and backend pools are somehow linked. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: strange usage pattern for child processes
Akins, Brian wrote: Would not the generic store-and-forward approach I sent last week help all of these situations? It effective turns any request into a sendfiled response. Let me do some checking and I may be able to just donate the code, since it's basically a very hacked up mod_deflate crossed with mod_xsendfile. It works for us, but we don't use the stock proxy, so not 100% it will help if the frontend and backend pools are somehow linked. This technique was used in the large disk cache work from 2006, and worked very well. Whether it will work in the current flow though I am not so sure. The current flow looks like this: read-backend - write-and-flush-frontend - disconnect-backend As I understand it, the flush part is the killer. The disconnect-backend should happen before the flush, not after. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: strange usage pattern for child processes
On Oct 19, 2008, at 4:20 PM, Ruediger Pluem wrote: On 10/19/2008 07:35 PM, Jim Jagielski wrote: On Oct 18, 2008, at 4:22 PM, Graham Leggett wrote: Ruediger Pluem wrote: As a result, the connection pool has made the server slower, not faster, and very much needs to be fixed. I agree in theory. But I don't think so in practice. Unfortunately I know so in practice. In this example we are seeing single connections being held open for 30 second or more. :( 1. 2.0.x behaviour: If you did use keepalive connections to the backend the connection to the backenend was kept alive and as it was bound to the frontend connection in 2.0.x it couldn't be used by other connections. Depending on the backend server it wasted the same number of resources as without the optimization (backend like httpd worker, httpd prefork) or a small amount of resources (backend like httpd event with HTTP or a recent Tomcat web connector). So you didn't benefit very well from this optimization in 2.0.x as long as you did not turn off the keepalives to the backend. Those who did need the optimisation, would have turned off keepalives to the backend. Trying to grok things better, but doesn't this imply that for those who needed the optimization, disabling the connection pool would be the required work-around for 2.2? No. Without a connection pool (e.g. the default reverse worker) the backend connection does not get freed any faster than without a connection pool. Ok strictly spoken you cannot turn off the connection pools at all (reverse is also one), you can only turn off a reuse of the connections. I thought that was the concern; that the pool wasn't released immediately. If you disable reuse, then you don't need to worry about when it is released... or I must be missing something obvious here :/
Re: strange usage pattern for child processes
Jim Jagielski wrote: I thought that was the concern; that the pool wasn't released immediately. If you disable reuse, then you don't need to worry about when it is released... or I must be missing something obvious here :/ Whether the connection is released and returned to the pool (when pools are used), or when the connection is closed (when pools are not used), as I understand it now neither of these make any difference - in both cases, the frontend connection to the client is flushed - causing a long delay - before the backend is released. The backend connection is held open during this delay, and isn't returned to the pool or closed, and this has the double effect of keeping expensive backend resources tied up for a long time, and reducing the effectiveness of the connection poool. If the backend connection is returned to the pool or disconnected the moment the backend request is finished, the delay is avoided, and when the pools are used, the backend connection can be reused immediately by another thread, instead of only after the flush to frontend is complete. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: strange usage pattern for child processes
On Oct 20, 2008, at 10:13 AM, Graham Leggett wrote: Jim Jagielski wrote: I thought that was the concern; that the pool wasn't released immediately. If you disable reuse, then you don't need to worry about when it is released... or I must be missing something obvious here :/ Whether the connection is released and returned to the pool (when pools are used), or when the connection is closed (when pools are not used), as I understand it now neither of these make any difference - in both cases, the frontend connection to the client is flushed - causing a long delay - before the backend is released. The backend connection is held open during this delay, and isn't returned to the pool or closed, and this has the double effect of keeping expensive backend resources tied up for a long time, and reducing the effectiveness of the connection poool. Ahhh... I got it now. Basically, as soon as we know we have all the data from the backend, we should release it.
Environment confusion
Hi all,
I have just been picking apart the way that environment variables are
handled at config time within httpd, and there seems to be some
overloading on concepts that has caused some confusion.
There are two environments within httpd, the first is the read only
system environment that is read using getenv(), the second is the
server-vars table that is read/write using mod_env and friends.
A recent addition was made (it's on trunk and 2.2) that allows httpd to
include system variables in config directives, like this:
DocumentRoot ${DOCUMENT_ROOT}
The system environment variable DOCUMENT_ROOT is parsed and placed in
the config line, so far so good.
What isn't possible however, is this:
SetEnv WEBAPP app1
Location /${WEBAPP}
ServerAdmin [EMAIL PROTECTED]
... other cool template style stuff ...
/Location
In this case, SetEnv sets a variable within mod_env's server-vars, but
this is ignored by ap_resolve_env, and so doesn't work as the user might
expect it to.
Zooming in some more on the way mod_env's environment works.
The mod_env environment in server-vars starts off empty, and then is
populated by explicit allocation (SetEnv), or by copying the value from
a system environment variable to a mod_env environment variable (PassEnv).
Would it make sense when parsing the config to try and insert mod_env's
server-vars variables first, and then if not present, fall back to (the
current behaviour of) looking at the system environment?
This will make some interesting templating options possible, and will
probably make lives easier for people doing mass hosting.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Environment confusion
On 10/20/08 1:19 PM, Graham Leggett [EMAIL PROTECTED] wrote: This will make some interesting templating options possible, and will probably make lives easier for people doing mass hosting. Seems like a place to get a lot of bug reports as well. I choose to just use a real template system to handle configs. I'm sure I'm not the only one. I'm +0 -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Environment confusion
On Oct 20, 2008, at 1:19 PM, Graham Leggett wrote:
Hi all,
I have just been picking apart the way that environment variables
are handled at config time within httpd, and there seems to be some
overloading on concepts that has caused some confusion.
There are two environments within httpd, the first is the read only
system environment that is read using getenv(), the second is the
server-vars table that is read/write using mod_env and friends.
A recent addition was made (it's on trunk and 2.2) that allows httpd
to include system variables in config directives, like this:
DocumentRoot ${DOCUMENT_ROOT}
The system environment variable DOCUMENT_ROOT is parsed and placed
in the config line, so far so good.
What isn't possible however, is this:
SetEnv WEBAPP app1
Location /${WEBAPP}
ServerAdmin [EMAIL PROTECTED]
... other cool template style stuff ...
/Location
In this case, SetEnv sets a variable within mod_env's server-vars,
but this is ignored by ap_resolve_env, and so doesn't work as the
user might expect it to.
Zooming in some more on the way mod_env's environment works.
The mod_env environment in server-vars starts off empty, and then
is populated by explicit allocation (SetEnv), or by copying the
value from a system environment variable to a mod_env environment
variable (PassEnv).
Would it make sense when parsing the config to try and insert
mod_env's server-vars variables first, and then if not present,
fall back to (the current behaviour of) looking at the system
environment?
This will make some interesting templating options possible, and
will probably make lives easier for people doing mass hosting.
But isn't that 2 different things? Do we really want WEBAPP to be in
the running process env space and contaminate that? If people want
macros
I tend to point them to mod_macro, which I like quite a bit...
Re: Environment confusion
Graham Leggett wrote:
Hi all,
I have just been picking apart the way that environment variables are
handled at config time within httpd, and there seems to be some
overloading on concepts that has caused some confusion.
There are two environments within httpd, the first is the read only
system environment that is read using getenv(), the second is the
server-vars table that is read/write using mod_env and friends.
A recent addition was made (it's on trunk and 2.2) that allows httpd to
include system variables in config directives, like this:
DocumentRoot ${DOCUMENT_ROOT}
The system environment variable DOCUMENT_ROOT is parsed and placed in
the config line, so far so good.
Actually the feature is just undocumented, and has existed since 2.0
(maybe 1.3 too?)
What isn't possible however, is this:
SetEnv WEBAPP app1
Location /${WEBAPP}
ServerAdmin [EMAIL PROTECTED]
... other cool template style stuff ...
/Location
In this case, SetEnv sets a variable within mod_env's server-vars, but
this is ignored by ap_resolve_env, and so doesn't work as the user might
expect it to.
-0, I would prefer to use a 'real' template language for configs, rather
than continuing to expand our current hacks upon hacks.
-Paul
Re: Environment confusion
Paul Querna schrieb:
Graham Leggett wrote:
Hi all,
I have just been picking apart the way that environment variables are
handled at config time within httpd, and there seems to be some
overloading on concepts that has caused some confusion.
There are two environments within httpd, the first is the read only
system environment that is read using getenv(), the second is the
server-vars table that is read/write using mod_env and friends.
A recent addition was made (it's on trunk and 2.2) that allows httpd
to include system variables in config directives, like this:
DocumentRoot ${DOCUMENT_ROOT}
The system environment variable DOCUMENT_ROOT is parsed and placed in
the config line, so far so good.
Actually the feature is just undocumented, and has existed since 2.0
(maybe 1.3 too?)
No, not 1.3. For 1.3 there was a simple module mod_define which came as
contrib in the mod_ssl package. I ported mod_define to 2.0 and 2.2
because I found it still useful: you can't change real environment
variables during graceful or restart, because the parent process doesn't
get a new environment. mod_define allows to either get the vars from the
process environment or via variable defines inside the config files,
which can of course be changed and activated via restarts.
I once asked about any interest on mod_define (could be ASL) on this
list, but got the hint about the support of environment variables
starting with 2.0 as a response.
mod_define and mod_macro are somewhat orthogonal. mod_macro allows you
to reuse config templates with variable parametrization in the
configuration, mod_define allows you to use the same value in very
different places of the config, without putting it in every time (e.g.
path values etc.). Instead you use a variable and thus managing the
values gets easier. An Example is a setup, that separates the httpd
product directory (modules etc.) from the instance directory (conf etc.)
and var part (logs, run) without fixig everything in a build layout. You
prepend three variables like APACHE_HOME, APACHE_BASE and APACHE_VAR to
the respective pathes and set them once according to your needs.
If httpd internal envvars were usable in configs, then of course
mod_define would be superfluous.
Concerning mod_macro: VirtualHost elements do not work inside Macros. I
never investigated wha.
Regards,
Rainer
Re: Environment confusion
On Mon, 20 Oct 2008 19:19:58 +0200
Graham Leggett [EMAIL PROTECTED] wrote:
There are two environments within httpd, the first is the read only
system environment that is read using getenv(), the second is the
server-vars table that is read/write using mod_env and friends.
Indeedie. Not IMHO a good thing, but to change it now would be worse.
What isn't possible however, is this:
SetEnv WEBAPP app1
Location /${WEBAPP}
ServerAdmin [EMAIL PROTECTED]
... other cool template style stuff ...
/Location
Your argument here appears to point towards the functionality
of mod_macro.
In this case, SetEnv sets a variable within mod_env's server-vars,
but this is ignored by ap_resolve_env, and so doesn't work as the
user might expect it to.
Zooming in some more on the way mod_env's environment works.
The mod_env environment in server-vars starts off empty, and then is
populated by explicit allocation (SetEnv), or by copying the value
from a system environment variable to a mod_env environment variable
(PassEnv).
Would it make sense when parsing the config to try and insert
mod_env's server-vars variables first, and then if not present, fall
back to (the current behaviour of) looking at the system environment?
This will make some interesting templating options possible, and will
probably make lives easier for people doing mass hosting.
We have a start on enabling this with the expression parser, which
enables configuration sections to be applied conditionally on an
expression evaluated at runtime. That's work-in-progress and needs
revisiting, but it can use env vars in its expression evaluation,
and templating with them should be a natural future direction.
(and of course, you can always use mod_rewrite).
--
Nick Kew
Re: svn commit: r697357 - in /httpd/httpd/trunk: include/ modules/http/ modules/test/ server/ server/mpm/experimental/event/
[EMAIL PROTECTED] wrote: --- httpd/httpd/trunk/modules/http/http_request.c (original) +++ httpd/httpd/trunk/modules/http/http_request.c Sat Sep 20 04:58:08 2008 @@ -257,24 +297,7 @@ ap_die(access_status, r); } -/* Send an EOR bucket through the output filter chain. When - * this bucket is destroyed, the request will be logged and - * its pool will be freed - */ -bb = apr_brigade_create(r-connection-pool, r-connection-bucket_alloc); -b = ap_bucket_eor_create(r-connection-bucket_alloc, r); -APR_BRIGADE_INSERT_HEAD(bb, b); -ap_pass_brigade(r-connection-output_filters, bb); - -/* From here onward, it is no longer safe to reference r - * or r-pool, because r-pool may have been destroyed - * already by the EOR bucket's cleanup function. - */ - -c-cs-state = CONN_STATE_WRITE_COMPLETION; -check_pipeline(c); -if (ap_extended_status) -ap_time_process_request(c-sbh, STOP_PREQUEST); +return ap_process_request_after_handler(r); } This is a compile error in a void function. What exactly was intended here? -- Nick Kew
Registration is still open for ApacheCon/US 2008
http://us.apachecon.com/c/acus2008/ Two weeks from today, ApacheCon/US in New Orleans kicks off with the hackathon, Tuesday offers a free Apache BarCamp, and there are several httpd tutorials with some seats remaining; Scaling Apache hands-on with Colm MacCarthaigh http://us.apachecon.com/c/acus2008/sessions/71 Advanced Production Troubleshooting with Theo Schlossnagle http://us.apachecon.com/c/acus2008/sessions/79 Apache Nuts to Bolts with Will Rowe, Rich Bowen and Jim Jagielski http://us.apachecon.com/c/acus2008/sessions/98 Wednesday Track One - Administration and Thursday Track One - Security should be especially interesting to subscribers of this list, and httpd is even hiding in Friday's program - see the lineup for yourself... http://us.apachecon.com/c/acus2008/schedule/2008/11/05 http://us.apachecon.com/c/acus2008/schedule/2008/11/06 http://us.apachecon.com/c/acus2008/schedule/2008/11/07 So if you haven't yet - today is a great day (for committers, too) to follow the Register Now link and join us in New Orleans for a great time!
