Re: proxy returning apr_status_t to handler?
On Dec 17, 2007 11:20 AM, Jeff Trawick [EMAIL PROTECTED] wrote: On Dec 17, 2007 10:27 AM, Nick Kew [EMAIL PROTECTED] wrote: On Mon, 17 Dec 2007 10:22:02 -0500 Eric Covener [EMAIL PROTECTED] wrote: Thanks; Any particular concerns about the generic fix for 2.0.x? Haven't looked, but if it applies cleanly, then +1 on doing so. same here That generic change may just be a temporary diversion when it comes to proxy... Here's an alarming response for a testcase where client didn't send enough bytes to satisfy C-L and we timed out: HTTP/1.1 200 OK Date: Tue, 18 Dec 2007 16:13:36 GMT Server: Apache/2.3.0-dev (Unix) DAV/2 Connection: close Transfer-Encoding: chunked Content-Type: text/plain 1f1 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title200 OK/title /headbody h1OK/h1 pThe server encountered an internal error or misconfiguration and was unable to complete your request./p pPlease contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error./p pMore information about this error may be available in the server error log./p /body/html 127.0.0.1 - - [18/Dec/2007:11:13:36 -0500] POST /readbody.pl HTTP/1.1 500 497 [Tue Dec 18 11:13:41 2007] [error] (70007)The timeout specified has expired: proxy: prefetch request body failed to 127.0.0.1:8081 (127.0.0.1) from 127.0.0.1 () [Tue Dec 18 11:13:41 2007] [debug] proxy_util.c(1995): proxy: HTTP: has released connection for (127.0.0.1) [Tue Dec 18 11:13:41 2007] [error] [client 127.0.0.1] Handler for proxy-server returned invalid result code 70007 backtrace for where r-status_line gets set to 200 OK: Hardware watchpoint 2: r-status_line Old value = 0x0 New value = 0x81493b4 200 OK basic_http_header_check (r=0x9124228, protocol=0xb74c8d30) at http_filters.c:721 721 if (r-proto_num HTTP_VERSION(1,0) (gdb) where #0 basic_http_header_check (r=0x9124228, protocol=0xb74c8d30) at http_filters.c:721 #1 0x080e5be5 in ap_http_header_filter (f=0x9125048, b=0x91256f8) at http_filters.c:1049 #2 0x0808c756 in ap_pass_brigade (next=0x9125048, bb=0x91256f8) at util_filter.c:527 #3 0x08071f43 in ap_content_length_filter (f=0x9125030, b=0x91256f8) at protocol.c:1337 #4 0x0808c756 in ap_pass_brigade (next=0x9125030, bb=0x91256f8) at util_filter.c:527 #5 0x080e7374 in ap_byterange_filter (f=0x9125018, bb=0x91256f8) at byterange_filter.c:169 #6 0x0808c756 in ap_pass_brigade (next=0x9125018, bb=0x91256f8) at util_filter.c:527 #7 0x0808c980 in ap_fflush (f=0x9125018, bb=0x91256f8) at util_filter.c:602 #8 0x080c9e62 in connection_cleanup (theconn=0x9082900) at proxy_util.c:1636 #9 0x080caad6 in ap_proxy_release_connection (proxy_function=0x8146e2d HTTP, conn=0x9082900, s=0x9080910) at proxy_util.c:1998 #10 0x080d5b11 in ap_proxy_http_cleanup (scheme=0x8146e2d HTTP, r=0x9124228, backend=0x9082900) at mod_proxy_http.c:1742 #11 0x080d5f9d in proxy_http_handler (r=0x9124228, worker=0x90bf6a8, conf=0x90bf568, url=0x91209e8 /cgi-bin/readbody.pl, proxyname=0x0, proxyport=0) at mod_proxy_http.c:1872 #12 0x080c67c5 in proxy_run_scheme_handler (r=0x9124228, worker=0x90bf6a8, conf=0x90bf568, url=0x91253f6 http://127.0.0.1:8081/cgi-bin/readbody.pl;, proxyhost=0x0, proxyport=0) at mod_proxy.c:2313 #13 0x080c3306 in proxy_handler (r=0x9124228) at mod_proxy.c:945 #14 0x0807fdc3 in ap_run_handler (r=0x9124228) at config.c:163 #15 0x0808050d in ap_invoke_handler (r=0x9124228) at config.c:378 #16 0x080e28f7 in ap_process_async_request (r=0x9124228) at http_request.c:244 #17 0x080e2a18 in ap_process_request (r=0x9124228) at http_request.c:288 #18 0x080df30d in ap_process_http_connection (c=0x91203d0) at http_core.c:208 #19 0x080883e7 in ap_run_process_connection (c=0x91203d0) at connection.c:43 #20 0x080887fb in ap_process_connection (c=0x91203d0, csd=0x9120220) at connection.c:178 #21 0x0811f6e2 in process_socket (p=0x91201e0, sock=0x9120220, my_child_num=0, my_thread_num=0, bucket_alloc=0x91221e8) at worker.c:542 #22 0x08120018 in worker_thread (thd=0x9109328, dummy=0x910b0e0) at worker.c:893 The only thing in the brigade being passed is a flush bucket.
Re: proxy returning apr_status_t to handler?
On Dec 18, 2007 12:06 PM, Plüm, Rüdiger, VF-Group
[EMAIL PROTECTED] wrote:
-Ursprüngliche Nachricht-
Von: Jeff Trawick
Gesendet: Dienstag, 18. Dezember 2007 17:43
An: dev@httpd.apache.org
Betreff: Re: proxy returning apr_status_t to handler?
Argh. Without further testing: Does the following patch fixes this:
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c (revision 605247)
+++ modules/proxy/proxy_util.c (working copy)
@@ -1601,7 +1601,7 @@
#endif
r = conn-r;
-if (conn-need_flush r) {
+if (conn-need_flush r (r-eos_sent || r-bytes_sent)) {
/*
* We need to ensure that buckets that may have been buffered in the
* network filters get flushed to the network. This is needed since
Yes; bogus 200 OK is resolved:
HTTP/1.1 500 Internal Server Error
Date: Tue, 18 Dec 2007 18:47:08 GMT
Server: Apache/2.3.0-dev (Unix) DAV/2
Content-Length: 535
Connection: close
Content-Type: text/html; charset=iso-8859-1
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
htmlhead
title500 Internal Server Error/title
/headbody
h1Internal Server Error/h1
pThe server encountered an internal error or
misconfiguration and was unable to complete
your request./p
pPlease contact the server administrator,
[EMAIL PROTECTED] and inform them of the time the error occurred,
and anything you might have done that may have
caused the error./p
pMore information about this error may be available
in the server error log./p
/body/html
$ tail -1 ~/inst/23/logs/access_log
127.0.0.1 - - [18/Dec/2007:13:47:08 -0500] POST /readbody.pl HTTP/1.1 500 535
$ tail -5 ~/inst/23/logs/error_log
[Tue Dec 18 13:47:08 2007] [debug] proxy_util.c(2281): proxy: HTTP:
fam 2 socket created to connect to 127.0.0.1
[Tue Dec 18 13:47:08 2007] [debug] proxy_util.c(2382): proxy: HTTP:
connection complete to 127.0.0.1:8081 (127.0.0.1)
[Tue Dec 18 13:47:13 2007] [error] (70007)The timeout specified has
expired: proxy: prefetch request body failed to 127.0.0.1:8081
(127.0.0.1) from 127.0.0.1 ()
[Tue Dec 18 13:47:13 2007] [debug] proxy_util.c(1995): proxy: HTTP:
has released connection for (127.0.0.1)
[Tue Dec 18 13:47:13 2007] [error] [client 127.0.0.1] Handler for
proxy-server returned invalid result code 70007
Re: Getting perl to core via mod_cgi
On 10/14/05, Graham Leggett [EMAIL PROTECTED] wrote: Joost de Heer wrote: What's 'ulimit -c' (bash, under tcsh it's 'limit -c', other shells may differ) for the user under which httpd runs? [EMAIL PROTECTED] ~]# ulimit -c unlimited This is for root though, which spawned httpd, which then becomes apache. I am not sure whether the apache user inherits this from root. It does. ulimit settings in the shell used to start Apache affect the Apache child processes. IOW, the setuid() does not change that aspect of the environment.
Re: Apache HTTP Server 1.3.34 prerelease tarballs
On 10/13/05, Jim Jagielski [EMAIL PROTECTED] wrote: Look for the Apache HTTP Server 1.3.34 prerelease tarballs in: http://httpd.apache.org/dev/dist/ +1 (AIX 5.3)
Re: mod_mem_cache and caching of file descriptors
On 10/17/05, Colm MacCarthaigh [EMAIL PROTECTED] wrote: On Mon, Oct 17, 2005 at 07:19:18AM -0400, Jeff Trawick wrote: doc says mod_mem_cache can be configured to operate in two modes: caching open file descriptors or caching objects in heap storage CacheEnable fd will use mod_mem_cache for caching open file descriptors. Not sure if it works, I havn't tested it. mod_mem_cache.c also has an CACHE_TYPE_MMAP, but this doesn't seem to be implemented. thanks... What's this got to do with apr? oops :(
Re: svn commit: r326058 - /httpd/httpd/trunk/modules/metadata/mod_setenvif.c
On 10/18/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jfclere Date: Tue Oct 18 02:24:02 2005 New Revision: 326058 URL: http://svn.apache.org/viewcvs?rev=326058view=rev Log: C++ comments are not supported by some compilers (ReliantUnix). or native compilers for AIX, z/OS, HP-UX, ...
Re: mod_cpluplus
On 10/20/05, artem [EMAIL PROTECTED] wrote: Hi All. When I'm building my own module (using mod_cplusplus) string LoadCPPHandler in httpd.conf causing /etc/init.d/apachectl: line 89: 13955 Segmentation fault $HTTPD -k $ARGV, but when i'm writing it in mod_cplusplus dir using it's own MakeFile - there is no error. What it is (or how to create the right Makefile for my module if that is the problem). You may wish to ask mod_cplusplus folks (not supported here). If you can determine where the crash occurred, you could post a backtrace here in case somebody recognizes the problem.
Re: Apache 2.0.x Binary distribution for HPUX
On 10/21/05, chris [EMAIL PROTECTED] wrote: I'm trying to build a binary distribution of Apache 2.0.54 for HPUX 32bits. I can build the binaries, and the tar.gz distrib file, but I can not deploy it on other servers, since my httpd binary doesn't seem to be properly linked. I build the distrib with the following command (default bindist.sh command) $ cd /tmp/buildapache/hpux11/src/httpd-2.0.54 $ build/bindist.sh Here are some output command: -- start of command output $ pwd /tmp/buildapache/hpux11/test/bin $ ./httpd -l /usr/lib/dld.sl: Can't open shared library: For one thing, httpd is not generally a valid way to run Apache 2. Use apachectl instead. You *should* have installroot/bin/envvars which sets SHLIB_PATH as appropriate, such that the shared library is found. I use some hacks for binbuild-like binary distributions on HP-UX: a) add -Wl,+s for SHLIB_PATH (you tried that) b) instead of /path/to/libexpat.sl /path/to/libaprutil.sl /path/to/libapr.sl, use -L/path/to -lexpat -laprutil -llibapr (otherwise, httpd will only look in that path for those libraries at run-time)
Re: [PATCH] PR37145: data loss with httpd-2.0.55 reverse proxy method=post
On 10/19/05, Ruediger Pluem [EMAIL PROTECTED] wrote: On 10/19/2005 10:44 PM, William A. Rowe, Jr. wrote: [..cut..] The problem is -not- in creating the transient buckets (if they are sent, that's goodness). The problem is in transforming them to persistant buckets before the core, ssl, or other filters who have set-aside operations decide to return. So there should have been no trouble creating the transient bucket below, the trouble came in when the core filter didn't send the data, and also didn't set it aside :-( Sorry, maybe I am only confused, but I think I disagree with you on that. The proxy code is reading the input filter chain in a loop and does repeated calls to ap_get_brigade without doing any more things with these brigades it gets from ap_get_brigade, but storing them for later processing. This looks to me like a typical setaside situation. The data was not send because ap_proxy_http_request kept it for itself not sending it anyware. +1
Re: [PATCH] PR37145: data loss with httpd-2.0.55 reverse proxy method=post
On 10/21/05, Ruediger Pluem [EMAIL PROTECTED] wrote: On 10/21/2005 04:06 PM, Joe Orton wrote: [..cut..] I agree that's the correct analysis, your patch to fix the proxy to use ap_save_brigade looks good to me. Thanks for feedback. I will commit later to give otherBill a chance for feedback. One technical question: As this bug was reported against 2.0.55 I would like to propose this patch for backport. As I am only committer am I allowed - to add it to the 2.0.x STATUS file yes - add my (of course non binding) vote on this backport? yes; I cannot think of a reason why your vote would not be respected in this particular matter
Re: Apache 2.0.x Binary distribution for HPUX
On 10/21/05, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Jeff Trawick wrote:
I use some hacks for binbuild-like binary distributions on HP-UX:
a) add -Wl,+s for SHLIB_PATH (you tried that)
It works nicely if you tweak libtool's archive_cmds from +b to +s +b
in the hpux* section of acinclude.m4, aclocal.m4 and configure, also
toggling...
hardcode_libdir_flag_spec='${wl}+s ${wl}+b ${wl}$libdir'
hardcode_minus_L=no
and a bit further down (line after SHLIB_PATH)...
shlibpath_overrides_runpath=yes
That does looks nice!
Re: svn commit: r327601 - /httpd/httpd/branches/2.0.x/STATUS
On 10/21/05, Colm MacCarthaigh [EMAIL PROTECTED] wrote: On Fri, Oct 21, 2005 at 10:48:23PM -, [EMAIL PROTECTED] wrote: Author: rpluem Date: Fri Oct 21 15:48:18 2005 New Revision: 327601 URL: http://svn.apache.org/viewcvs?rev=327601view=rev Log: * Move two backports from proposed to accepted, as they have enough votes now. I don't think this should be done until the actual code is backported too :-) (someone more clued-in than I can confirm though). Move from proposed to accepted when there are sufficient votes. Remove from STATUS when code is backported.
Re: The 2.2.0 Process
On 10/23/05, Paul Querna [EMAIL PROTECTED] wrote: 2) 2.1.N is voted on for BETA. 3) Assuming the vote passes, several days after releasing 2.1.N-BETA, a vote to mark 2.1.N-BETA as Stable/General Availability will be called for by the 2.1.N Release Manager. 3 days is maybe enough time to catch a couple of build issues that we didn't see, but not anything else. I don't see the value in making a big deal about it to the general public if the thing is likely to be GA before there is time for more than a handful of people to give feedback. (Why did I bother with the beta?)
Re: [RFC] require apr/apr-util 1.2.x for 2.2.x
On 10/24/05, Nick Kew [EMAIL PROTECTED] wrote: On Monday 24 October 2005 13:22, Joe Orton wrote: There was a thread about this previously; just checking for consensus, is there any objection to bumping the apr/apr-util version requirements to 1.2.x? (1.2.x is already required for mod_dbd, event MP, and it will simplify the code to allow unconditional use of 1.2.x features) +1 +1 here as well
ProxyPassReverseCookieDomain in 2.0?
The patch in PR 10722 seems to be very widely referred to (perhaps widely used as well ;) ). Are there any known issues with that patch? Is there any technical reason why it couldn't be applied to 2.0?
just how bad an idea is it to specify the path to suexec binary in httpd.conf?
ErrorLog /etc/some-important-database LoadModule hidden_module /usr/local/viewcvs-0.9.3/pipeopen.py SuexecWrapper /www/abc.example.com/bin/suexec If random user can edit main conf file, things are pretty bad, at least when root starts Apache. Perhaps there are more current limitations on possible harm when non-root starts Apache. Any thoughts on avoiding hard-coded path to suexec?
Re: Building Apache 2.0.55
On 11/10/05, Paul Smedley [EMAIL PROTECTED] wrote: Hi All, I'm trying to get Apache2 2.0.55 building and running on OS/2 using GCC 3.3.5. There's a current build of Apache using GCC 2.8.1 but that GCC is getting a bit long in the tooth so I'd like to update things :) Anyway, I have it building ok - using the unix network_io and poll code instead of the OS/2 code as GCC 3.3.5 on OS/2 provides a much more unix like behaviour. [Thu Nov 10 19:51:18 2005] [error] (38)Socket operation on non-socket: apr_accept apparently it doesn't provide as much as is necessary... does it still work with the OS/2 networking? do APR test programs work better or worse with the unix networking implementation? you are essentially deciding to be an APR developer by switching the networking implementation to something that nobody else has used before (APR questions to dev@apr.apache.org)
Re: svn commit: r327872 - in /httpd/httpd/trunk: CHANGES include/httpd.h server/core_filters.c
On 10/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: brianp
Date: Sun Oct 23 15:38:35 2005
New Revision: 327872
URL: http://svn.apache.org/viewcvs?rev=327872view=rev
Log:
New version of ap_core_output_filter that does nonblocking writes
...
+static apr_status_t send_brigade_blocking(apr_socket_t *s,
+ apr_bucket_brigade *bb,
+ apr_size_t *bytes_written,
+ conn_rec *c)
+{
...
+if (APR_STATUS_IS_EAGAIN(rv)) {
+rv = apr_wait_for_io_or_timeout(NULL, s, 0);
Whoops, not an API. This needs to use apr_poll().
Re: Proper declaration for apr_wait_for_io_or_timeout() (was: Re: NWGNUmakefile update for APR1.2?)
On 11/11/05, Brad Nicholes [EMAIL PROTECTED] wrote: On 11/11/2005 at 1:40:32 pm, in message [EMAIL PROTECTED], Jeff Trawick [EMAIL PROTECTED] wrote: On 11/11/05, Brad Nicholes [EMAIL PROTECTED] wrote: Reposting to the APR list with a new subject line. Does this need to be taken care of in APR 1.2.x before httpd 2.2 ships? apr_wait_for_io_or_timeout() is private APR function (not API). Is the caller outside of APR? Yes, HTTPD. trunk/server/core_filters.c Simply shocking ;) That code needs to be fixed to call a real API :(
Re: Can't compile trunk on Win
On 11/12/05, Vadim Chekan [EMAIL PROTECTED] wrote:
Hi all,
I've tryed to compile httpd/trunk and got an error:
core_filters.obj : error LNK2019: unresolved external symbol
_apr_wait_for_io_or_timeout referenced in function
_send_brigade_blocking
I have apr from apr/branches/1.2.x and looks like it doesn't contain
apr_wait_for_io_or_timeout for windows, unix only.
wasn't supposed to be used
Try this??
Index: server/core_filters.c
===
--- server/core_filters.c (revision 332755)
+++ server/core_filters.c (working copy)
@@ -26,7 +26,6 @@
#include apr_hash.h
#include apr_thread_proc.h/* for RLIMIT stuff */
#include apr_hooks.h
-#include apr_support.h
#define APR_WANT_IOVEC
#define APR_WANT_STRFUNC
@@ -624,7 +623,17 @@
rv = send_brigade_nonblocking(s, bb, bytes_written, c);
if (rv != APR_SUCCESS) {
if (APR_STATUS_IS_EAGAIN(rv)) {
-rv = apr_wait_for_io_or_timeout(NULL, s, 0);
+/* Wait until we can send more data */
+apr_int32_t nsds;
+apr_interval_time_t timeout;
+apr_pollfd_t pollset;
+
+pollset.p = c-pool;
+pollset.desc_type = APR_POLL_SOCKET;
+pollset.reqevents = APR_POLLOUT;
+pollset.desc.s = s;
+apr_socket_timeout_get(s, timeout);
+rv = apr_poll(pollset, 1, nsds, timeout);
if (rv != APR_SUCCESS) {
break;
}
apr_wait_for_io_or_timeout() decl in apr_support.h which is in public include directory
On 11/12/05, Brian Pane [EMAIL PROTECTED] wrote:
On Nov 11, 2005, at 6:21 PM, Jeff Trawick wrote:
On 11/11/05, Brad Nicholes [EMAIL PROTECTED] wrote:
On 11/11/2005 at 1:40:32 pm, in message
[EMAIL PROTECTED], Jeff
Trawick
[EMAIL PROTECTED] wrote:
On 11/11/05, Brad Nicholes [EMAIL PROTECTED] wrote:
Reposting to the APR list with a new subject line. Does this
need
to
be taken care of in APR 1.2.x before httpd 2.2 ships?
apr_wait_for_io_or_timeout() is private APR function (not API). Is
the caller outside of APR?
Yes, HTTPD. trunk/server/core_filters.c
Simply shocking ;) That code needs to be fixed to call a real API :(
I just double-checked the declaration, and apr_wait_for_io_or_timeout()
currently is implemented as part of the public API. I don't have any
strong
objection to making it private, though (e.g., by wrapping the
declaration in
an #ifdef APR_PRIVATE or moving apr_support.h to apr/include/arch/
unix).
apr_support.h has these comments...
/**
* @defgroup apr_support Internal APR support functions
* @ingroup APR
* @{
*/
It must be for pragmatic reasons that apr_support.h is in the apr
include directory instead of include/arch. Perhaps
include/arch/apr_private_common.h is more appropriate?
Re: Typo in modules\proxy\mod_proxy.c
On 11/15/05, Christophe Jaillet [EMAIL PROTECTED] wrote: Typo in modules\proxy\mod_proxy.c, in function set_status_opt, line 1388 : Thanks for the patch! Committed to trunk.
Re: Small cleanup in /modules/mappers/mod_negotiation.c, in function get_body
On 11/20/05, Ruediger Pluem [EMAIL PROTECTED] wrote: On 11/20/2005 11:00 AM, Ruediger Pluem wrote: [..cut..] If there is consensus that such trivial CHANGES should not be added (which I would also tend to with the reasons you mentioned), then I will happily remove the CHANGE log entry. So another comment please! Ok, forget about the removal part. Paul backported it to 2.2.x and taged 2.1.10 afterwards. So I cannot remove it for this case. Anyway since I was uncertain about the 'right' thing to do here and since it seemed to be handled differently by different people I still like to have further comments on this issue :-). I think it is a good idea for people who show up with patches out of the blue to see a recognition of their contribution, even if relatively small. Many people off the dev list don't realize that a lot of fixes come from random people. It can only help to do what we can to promote that perception.
mod_dav and EBCDIC
On input path, ap_xml_parse_input() handles converting xml to native charset (at least in 2.2). On output, there is no provision for converting xml in responses. Some choices: (a) convert right in DAV before calling ap_fXXX() APIs (b) have DAV implement a filter that converts xml from native to UTF-8 (or whatever the xml says the charset is in); add the filter automatically within DAV when it generates an xml response; it would be prudent for mod_charset_lite to be aware of this filter so that it won't touch the body where it is added (c) have mod_charset_lite implement a special filter for this purpose; perhaps it uses the existing logic but the name of the filter sets the proper configuration; DAV would add this filter implicitly when it generates an xml response; user simply loads mod_charset_lite on non-ASCII machine and no further configuration is needed to get DAV xml translatable (d) ??? (some solutions in mod_charset_lite which require user to do special mod_charset_lite configuration, such as to indicate that dav xml is translated one way and actual content is potentially translated a different way, or not translated at all) (c) looks reasonable to me; they agree on filter name (mod_charset_lite.h) and it is presumed that it means to translate from the codepage of compliled in strings (such as the string DAV_XML_HEADER in mod_dav.h) to UTF-8 Thoughts?
Re: mod_so problem under OS/2
On 11/26/05, Paul Smedley [EMAIL PROTECTED] wrote: What's happening is that it's loading all the modules that are listed in httpd.conf, then for some reason is trying to load them a second time which then fails as the library is already open. loading them again is normal; but they are closed/unloaded in-between
Re: realtime client connnection abort notifications
On 12/17/05, Christian Parpart [EMAIL PROTECTED] wrote: What I need is a way to install a hook within the apache server process that gets invoked ASAP(!) the client connection of interest has been aborted (mostly by client side). if a module is busy handling the request (e.g., long-running CGI, or forwarded to some application server and is awaiting a response), Apache has no idea when the client aborts the connection... there's nothing to hook into... if we're in core code handling I/O, network-layer filter will find out ASAP, [should] set c-aborted, and return; presumably no other software would delay notification of this Apache already has a big I/O dispatching loop, so, is there maybe something I can hook me in to? not generally
Re: Apache 2.2.0 Listen Directive
On 12/28/05, Fenlason, Josh [EMAIL PROTECTED] wrote: I'm running into an issue where Apache 2.2.0 on AIX won't start if there is more than one Listen directive. Does it get better if you code Listen 0.0.0.0:port1 Listen 0.0.0.0:port2 ? What version of AIX (unclear that it matters)? Can you send me truss of startup using the failure configuration? truss -o /tmp/startup -f bin/apachectl start
Re: Apache 2.2.0 Listen Directive
On 12/28/05, Jeff Trawick [EMAIL PROTECTED] wrote:
On 12/28/05, Fenlason, Josh [EMAIL PROTECTED] wrote:
I'm running into an issue where Apache 2.2.0 on AIX won't start if there is
more than one Listen directive.
Can you send me truss of startup using the failure configuration?
truss -o /tmp/startup -f bin/apachectl start
(trace received offline)
I don't see any socket errors. I jumped more than half-way to a
conclusion from your initial report (won't start) and assumed that
some sort of bind error occurred. It seems somewhat likely that a
crash is occurring, though I don't see SIGSEGV being reported in the
trace. Anything written to the console by apachectl start? What is
exit status of apachectl start in the failure?
# bin/apachectl start
# echo $?
Anything written to error log?
AIX 5.1 doesn't have IPV6_V6ONLY socket option (added in 5.2), which
does affect processing of sockets. Can you try this hack?
Index: server/listen.c
===
--- server/listen.c (revision 360100)
+++ server/listen.c (working copy)
@@ -408,11 +408,8 @@
if (previous != NULL
IS_INADDR_ANY(lr-bind_addr)
lr-bind_addr-port == previous-bind_addr-port
- IS_IN6ADDR_ANY(previous-bind_addr)
- apr_socket_opt_get(previous-sd, APR_IPV6_V6ONLY,
- v6only_setting) == APR_SUCCESS
- v6only_setting == 0) {
-
+ IS_IN6ADDR_ANY(previous-bind_addr)) {
+/* hacked to ignore IPV6_V6ONLY setting */
/* Remove the current listener from the list */
previous-next = lr-next;
continue;
Re: mod_cgi, fork, and threaded MPMs
On 1/14/06, Paul Querna [EMAIL PROTECTED] wrote: Last week bloglines.com upgraded from 2.0.x to 2.2.x. At the same time, I switched us from mod_cgid to mod_cgi. mod_cgid has some problems if its path to the cgisock changes at any time, it really needs to call realpath() on the cgisock path, to avoid issues with how we distribute releases. (We swap some symlinks around, but as soon as these were changed, it would cause every CGI request to return a 503...) I decided to instead to just switch to mod_cgi. Fork() on a threaded process according to POSIX is supposed to be thread local. And Linux wasn't supposed to be stupid about it, unlike Solaris. So, running mod_cgi on the worker MPM should of been safe. What happens with mutexes? They get forked (including ownership), and there is no code in APR/httpd to make sure the ownership of mutexes makes sense in the forked child (the kind of stuff that is done in pthread_atfork handlers). What happens with pipes created to communicate with CGI children? Pipe handles accidently get inherited by child processes created by other threads when then can hold them open unknowingly preventing EOF from being seen from the original CGI at the proper time, right? Cookie-going-to-wrong-user could be caused by file descriptor handling glitch like a double close, but it would have to be in code that Windows doesn't use (assuming there are enough Windows CGI setups). close(9); ... close(9); in prefork is sloppiness seen when you do strace, but with worker it gets a CVE number.
Re: filters that change r-status[_line]
(editing subject line slightly) On 2/16/06, Jeff Trawick [EMAIL PROTECTED] wrote: (perhaps tell me where I go wrong here with the way it is supposed to work) A module that wants to use an HTTP response code which has no built-in support in Apache needs to set r-status AND r-status_line. Otherwise, Apache will return 500 to the client. A module that proxys to some other HTTP application which can return arbitrary HTTP response codes can set r-status and r-status_line with whatever the other application returned, to avoid situations where Apache will return 500 to the client instead of the unsupported HTTP response code. It shouldn't have to look at the exact status code before deciding whether to set r-status and r-status_line. The Range support in Apache = 2 can handle arbitrary sources for the response due to its implementation as a filter. If the request was for a range and the handler didn't implement that aspect of the request, the byterange filter will process the non-error response and report status to the client as appropriate (e.g., set 206). The range support right now isn't smart enough to clear r-status_line when it sets a new status code (206, 416). That needs to be fixed to avoid breaking range requests for modules which set r-status_line even for non-error responses. *Any filter* that modifies r-status should clear (or set) r-status_line. Apache could do something to remove the requirement... * if Apache has built-in support for r-status, use apache status line (200 OK) * elsif r-status_line is set, use that (200 GOODYGOODY) * else use 500 status line (If the filter changed r-status to a code with no built-in support, the filter had to set r-status_line ANYWAY) No idea here what depends on modules being able to override Apache's status lines... Thoughts?
Re: filters that change r-status[_line]
On 2/17/06, Joe Orton [EMAIL PROTECTED] wrote: On Fri, Feb 17, 2006 at 11:03:54AM -0500, Jeff Trawick wrote: On 2/16/06, Jeff Trawick [EMAIL PROTECTED] wrote: ... The range support right now isn't smart enough to clear r-status_line when it sets a new status code (206, 416). That needs to be fixed to avoid breaking range requests for modules which set r-status_line even for non-error responses. I'm not sure I understand this. The range filter would only confuse things if some module set r-status_line but *not* r-status, right? (because the range filter only takes effect if r-status == 200). But that would be a rather odd thing for a module to do, surely, or am I missing the point? missing the point due to bad explanation ;) The range filter would confuse things if a module set r-status = 200; r-status_line = 200 OK because the range filter could set r-status = 206, leave r-status_line 200 OK, and so the client would see 200 OK in the response since basic_http_header_check() will respect r-status_line if already set, whether or not it matches r-status. Now why would the module be stupid enough to set r-status_line if r-status is 200? Maybe it is a proxy that blindly stores whatever the origin server returns. *Any filter* that modifies r-status should clear (or set) r-status_line. Apache could do something to remove the requirement... * if Apache has built-in support for r-status, use apache status line (200 OK) * elsif r-status_line is set, use that (200 GOODYGOODY) * else use 500 status line That seems reasonable to me. Same here, but wondering whose kludge breaks because they can't see 200 GOODYGOODY from their module any more :) Here's another variation... if r-status_line is set and leading number matches r-status, use that elsif Apache has built-in support for r-status, use Apache status line else use 500 status line
input filter which modifies body, Content-Length
(Apologies if there is juicy past discussion that I didn't find with my search keywords.) It isn't clear to me what an input filter should do about Content-Length when it modifies the length of the body (assuming that this isn't chunked encoding). It causes problems for some handlers to modify the length of the request body but leave Content-Length alone. Handlers which care about Content-Length have probably already looked at it before the input filter has been called anyway. A handler that uses brigades to read the body and has no need to look at Content-Length should be okay either way. mod_cgi uses brigades to read the body but needs to look at Content-Length before spawning the CGI script, so that's problematic. And there is an unexpected ordering requirement so that the input filter can signal to this handler that the content-length can't be trusted, before mod_cgi spawns the child. ap_setup_client_block() looks at the initial Content-Length to know how much to read, so that's problematic but perhaps fixable for these types of handlers. A filter which spools up to a configured amount of request body in order to calculate content-length could be of some practical benefit, since many request bodies are relatively small and this could potentially allow mod_cgi[d] to properly handle chunked request bodies, regardless of input filtering. With such a filter installed, and no need to spool beyond a configured limit, getting a brigade would return bucket(s) with known length and an EOS at the end. Unknown lengths or EOS? Better punt if you're mod_cgi[d]. Thoughts?
Re: input filter which modifies body, Content-Length
On 2/24/06, Greg Ames [EMAIL PROTECTED] wrote: Jeff Trawick wrote: It isn't clear to me what an input filter should do about Content-Length when it modifies the length of the body (assuming that this isn't chunked encoding). mod_cgi uses brigades to read the body but needs to look at Content-Length before spawning the CGI script, so that's problematic. And there is an unexpected ordering requirement so that the input filter can signal to this handler that the content-length can't be trusted, before mod_cgi spawns the child. so is this the current ordering? 1. mod_cgi[d] handler is dispatched 2. C-L environment variable is set for the script from the initial C-L header 3. CGI child is spawned. 4. mod_cgi[d] reads the body from input filters 5. foo_input_filter changes the body, invalidating the C-L env var + whatever local variables the script is using to track the length 6. CGI reads from stdin into buffer of length ? looks right to me A filter which spools up to a configured amount of request body in order to calculate content-length could be of some practical benefit, since many request bodies are relatively small and this could potentially allow mod_cgi[d] to properly handle chunked request bodies, regardless of input filtering. With such a filter installed, and no need to spool beyond a configured limit, getting a brigade would return bucket(s) with known length and an EOS at the end. Unknown lengths or EOS? Better punt if you're mod_cgi[d]. per offline discussions, * the CGI spec (fwiw) is oblivious to chunking * 1.3 and pre-filtering 2.0 used to fail CGI requests with chunked bodies. getting them to work properly in common cases (i.e. 8K bodies ) would be a step forward. * this is analogous to proxy trying to avoid chunking to the origin server, except the spec is weaker for CGIs a decent solution for CGI request body chunking would also solve some cases of input filters modifying the length. y I suspect a number of third-party modules would need to change (not to mention our own). The handler would need to get a brigade then, if there is EOS bucket at the end and the length of each bucket is known, then use that for content-length. (Presumably a magic filter with configurable timeouts and spooling capability would allow this to happen.) Otherwise, either fail the request (e.g., CGI) or don't handle the body in a way that needs to know the length in advance.
Re: Detecting if Client closed connection
On 3/1/06, R, Rajesh (STSD) [EMAIL PROTECTED] wrote: Hello, I am working on a patch, to kill a cgi process if the client closes the conenction in Apache 2.0.54/mod_cgid. Apache only finds out when it tries to do I/O. CGI needs to write a little output to the client every so often if it is a long-running CGI so that Apache tries to write to the client and finds out that it has closed the connection.
pool use/mutex initialization in util_ldap not thread safe?
Plz forgive any misunderstanding, as well as my use of 2.0 function names ;) Also, for being slow at learning what ldap stands for. I know this code has been hashed over many many times over the last few years. util_ldap_create_config() creates the per-server config for util_ldap. That saves a config-time pool in the per-server config. util_ldap_connection_find() is called on a request and allocates a mutex using st-pool without holding a mutex, if the mutex wasn't created before. IOW, the first very-small-number of threads in that process that try to find a connection will allocate a mutex. Hopefully very-small-number is one (This is exactly the type of bug I had the displeasure of diagnosing in a proprietary module some time back; somebody eons ago had deferred some initialization until the first request, assuming incorrectly that there was no way that at the time of the first request for a certain vhost that there would actually be 2+ concurrent requests stomping on each other. one of the baby bells proved otherwise continually until the problem was found and fixed) The child init hook really needs to talk the server_recs and create the mutex there, right? Also, is the pool growth of the config-time pool reasonable? What happens when some other module cheats and uses a config-time pool on request processing thread, even if it is smart enough to protect the pool misuse with a mutex? (kaboom) If it is reasonable to grow some pool over time during the request processing, shouldn't it be an ldap-unique pool?
Re: pool use/mutex initialization in util_ldap not thread safe?
On 3/15/06, Brad Nicholes [EMAIL PROTECTED] wrote: I think you are right. I am going to take a closer look at that code and see about fixing both the mutex problem and the use of the config pool. This could actually explain some funny things that I have been seeing on the NetWare build lately. Something else to make sure is resolved by any fixes: Forget the race condition initializing the mutex for a sec... That is really one pool globally but there is a mutex per server_rec. So a thread handling a request for one vhost grabs the mutex and uses the pool but that doesn't protect from a thread handling a request for a different vhost which grabs a different mutex supposedly protecting the same pool.
Re: pool use/mutex initialization in util_ldap not thread safe?
On 3/16/06, Ruediger Pluem [EMAIL PROTECTED] wrote: On 03/16/2006 03:49 AM, Jeff Trawick wrote: On 3/15/06, Brad Nicholes wrote: That is really one pool globally but there is a mutex per server_rec. So a thread handling a request for one vhost grabs the mutex and uses the pool but that doesn't protect from a thread handling a request for a different vhost which grabs a different mutex supposedly protecting the same pool. Would it help to create sub-pools per server_rec from the config pool? That sounds like a definite improvement, but I'm eager for LDAP gurus to explain how pool growth is mitigated in the current design (assuming thread safety) before jumping to a conclusion.
Re: pool use/mutex initialization in util_ldap not thread safe?
On 3/16/06, Brad Nicholes [EMAIL PROTECTED] wrote: On 3/16/2006 at 7:12 am, in message [EMAIL PROTECTED], Jeff Trawick [EMAIL PROTECTED] wrote: On 3/16/06, Ruediger Pluem [EMAIL PROTECTED] wrote: On 03/16/2006 03:49 AM, Jeff Trawick wrote: On 3/15/06, Brad Nicholes wrote: That is really one pool globally but there is a mutex per server_rec. So a thread handling a request for one vhost grabs the mutex and uses the pool but that doesn't protect from a thread handling a request for a different vhost which grabs a different mutex supposedly protecting the same pool. Would it help to create sub-pools per server_rec from the config pool? That sounds like a definite improvement, but I'm eager for LDAP gurus to explain how pool growth is mitigated in the current design (assuming thread safety) before jumping to a conclusion The use of the pool is actually fairly limited. It is used to create and initialize the reusable LDAP resources such as ldap connections. The pool of ldap connections can grow but that is based on the amount of traffic that requires LDAP authentication. Even under very heavy use, the number of connections in the connection pool might be ~20 but even that is a generous number. if ldap server times out the connection and we have to bring one back up, that is no pool growth, right? we just get pool growth when we talk to an LDAP server we haven't already talked to yet, or when? Any per-request memory allocations are done from the request pool. So the potential for collisions within the global memory pool, although not 0, would be very low. very low == still broken but much much harder to debug than high The purpose of the mutex is not necessarily to protect the memory pool but to protect the ldap connection pool. Whenever mod_ldap needs to pull a connection from the ldap connection pool, it first grabs the mutex so that it is free to search for a connection and modify its parameters without having to worry about other threads doing the same thing. Since most of the global memory pool usage, outside of module initialization, also occurs after the connection pool mutex has been locked, this also lessens the chance of memory pool collisions. However, given all of there, I still think that there are things that need to be cleaned up especially with the mutex allocation and use in a worker MPM environment. I interpret this as meaning that the following would resolve the problems (race condition for mutex initialization between multiple threads for the same vhost and race condition for pool use between multiple threads in different vhosts): 1) this code needs LDAP-specific subpool of pchild* for each LDAP-enabled vhost, initialized in child-init hook 2) the vhost-specific mutex is initialized in the child-init hook (walk the server_rec list) *do these objects need to get cleaned up when the process goes away? maybe it shouldn't be a subpool at all but instead a freestanding pool (I can't remember at the moment if a freestanding pool keeps it from being cleaned up at child process exit) or 1) one global subpool of pchild* for each LDAP-enabled vhost, initialized in child-init hook 2) one global mutex initialized in the child-init hook It just depends on expected collision rate. I see some pthread_mutex_trylock usage, which makes me think the collision rate can be high, but it is unclear that segregating by vhost makes much of an improvement.
Re: pool use/mutex initialization in util_ldap not thread safe?
On 3/16/06, Graham Leggett [EMAIL PROTECTED] wrote: Jeff Trawick wrote: if ldap server times out the connection and we have to bring one back up, that is no pool growth, right? we just get pool growth when we talk to an LDAP server we haven't already talked to yet, or when? Dead LDAP connections (timed out, server gone away, etc) are repaired rather than replaced, in other words the record is reused. In theory, the pool should never get bigger than the maximum number of simultaneous connections we have ever had open at one time. Great, so fix should be very straightforward.
Re: svn commit: r386477 - /httpd/httpd/trunk/modules/ldap/util_ldap.c
On 3/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewcvs?rev=386477view=rev Log: remove the race condition when creating the connection pool mutex. Also eliminate some unnecessary uses of the global memory pool cool! @@ -1753,7 +1753,10 @@ util_ldap_state_t *base = (util_ldap_state_t *) basev; util_ldap_state_t *overrides = (util_ldap_state_t *) overridesv; -st-pool = p; +st-pool = base-pool; +#if APR_HAS_THREADS +st-mutex = base-mutex; +#endif What this use of the base pool and mutex means is that while a subpool and mutex were created for the vhost, we'll never use them. Instead, we'll use the subpool and mutex created for the main server. Not what you meant, right?
Re: svn commit: r386477 - /httpd/httpd/trunk/modules/ldap/util_ldap.c
On 3/16/06, Brad Nicholes [EMAIL PROTECTED] wrote: On 3/16/2006 at 7:01 pm, in message [EMAIL PROTECTED], Jeff Trawick [EMAIL PROTECTED] wrote: On 3/16/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewcvs?rev=386477view=rev Log: remove the race condition when creating the connection pool mutex. Also eliminate some unnecessary uses of the global memory pool cool! @@ -1753,7 +1753,10 @@ util_ldap_state_t *base = (util_ldap_state_t *) basev; util_ldap_state_t *overrides = (util_ldap_state_t *) overridesv; -st-pool = p; +st-pool = base-pool; +#if APR_HAS_THREADS +st-mutex = base-mutex; +#endif What this use of the base pool and mutex means is that while a subpool and mutex were created for the vhost, we'll never use them. Instead, we'll use the subpool and mutex created for the main server. Not what you meant, right I guess I don't understand. When I tested this using the worker MPM (3 servers, 25 threads each) and configuring both an ldap protected directory in the main server and an ldap protected directory in a vhost, it never had a problem locking the mutex or allocating memory. Am I missing something? You won't see any functional problem. You're just not using some of the pools and mutexes you created. Example: Here are some vhosts: VirtualHost *:8080 ldapcacheentries 200 /VirtualHost VirtualHost *:80 ldapcacheentries 100 /VirtualHost util_ldap_create_config() gets called 3 times to create the vhost-specific configuration for mod_ldap (once for main server scope and once for each vhost). Each time, you create a subpool and a mutex to be used for that vhost/server_rec. After the create-config is called, next the merge function util_ldap_merge_config() is called twice to merge the main server scope server_rec with each vhost server_rec. The first time it is called, basev points to the main server_rec, and overridesv points to the server_rec with ldapcacheentries set to 200. Normally a merge function will have logic like: if value not set in overrides server_rec overrides-value = base-value But this merge function ignores information in the overrides server_rec (e..g, the one with ldapcacheentries 200 and its own specific pool and mutex) and writes over the values with the main server values. After the merge function is called twice (once per vhost), both vhost containers have had the pool and mutex wiped out and all requests will use the pool and mutex for the main server_rec. Other (original) code in this merge function looks wrong too: st-cache_bytes = base-cache_bytes; OTOH, some code looks like it is working properly: st-secure = (overrides-secure_set == 0) ? base-secure : overrides-secure;
Re: svn commit: r386698 - /httpd/httpd/trunk/modules/ldap/util_ldap.c
On 3/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: bnicholes
Date: Fri Mar 17 11:26:27 2006
New Revision: 386698
URL: http://svn.apache.org/viewcvs?rev=386698view=rev
Log:
Fix the server_merge so that the memory pools and mutexes that were created
during the server_create, are used. Allow the settings that can be
overwritten in a vhost to use the vhost values
Modified:
httpd/httpd/trunk/modules/ldap/util_ldap.c
Modified: httpd/httpd/trunk/modules/ldap/util_ldap.c
URL:
http://svn.apache.org/viewcvs/httpd/httpd/trunk/modules/ldap/util_ldap.c?rev=386698r1=386697r2=386698view=diff
==
--- httpd/httpd/trunk/modules/ldap/util_ldap.c (original)
+++ httpd/httpd/trunk/modules/ldap/util_ldap.c Fri Mar 17 11:26:27 2006
@@ -1753,24 +1753,36 @@
util_ldap_state_t *base = (util_ldap_state_t *) basev;
util_ldap_state_t *overrides = (util_ldap_state_t *) overridesv;
-st-pool = base-pool;
+st-pool = overrides-pool;
#if APR_HAS_THREADS
-st-mutex = base-mutex;
+st-mutex = overrides-mutex;
#endif
+/* The cache settings can not be modified in a
+virtual host since all server use the same
+shared memory cache. */
st-cache_bytes = base-cache_bytes;
st-search_cache_ttl = base-search_cache_ttl;
st-search_cache_size = base-search_cache_size;
st-compare_cache_ttl = base-compare_cache_ttl;
st-compare_cache_size = base-compare_cache_size;
-st-connections = base-connections;
-st-ssl_supported = base-ssl_supported;
+
+st-connections = NULL;
+st-ssl_supported = 0;
st-global_certs = apr_array_append(p, base-global_certs,
overrides-global_certs);
st-client_certs = apr_array_append(p, base-client_certs,
overrides-client_certs);
st-secure = (overrides-secure_set == 0) ? base-secure
: overrides-secure;
+
+/* LDAP connection settings can be overwritten in a virtual host */
+st-connectionTimeout = (overrides-connectionTimeout == 10)
+? base-connectionTimeout
+: overrides-connectionTimeout;
actually, it can't...
util_ldap_set_connection_timeout() has
err = ap_check_cmd_context(cmd, GLOBAL_ONLY);
if (err != NULL) {
return err;
}
should I remove that check for GLOBAL_ONLY?
I can a check for GLOBAL_ONLY and try to update the docs for
directives that aren't appropriate in a vhost, according to your notes
in the merge function.
Re: svn commit: r386776 - in /httpd/httpd/trunk/docs/manual/mod: mod_ldap.html.en mod_ldap.xml
On 3/18/06, Graham Leggett [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewcvs?rev=386776view=rev Log: LDAPConnectionTimeout and LDAPVerifyServerCert can be configured per-vhost We need to note in addition to this that not all LDAP SDK libraries support the concept of separately configurable verify server cert behaviour. In other words, even though you specify LDAPVerifyServerCert in LDAP connections from vhost A, you end up overriding this when you specify it in vhost B. This affects people using the Novell SDK. Beyond doc, do you agree we can change the code so that the virtual host configuration is disallowed when APR_HAS_NOVELL_LDAPSDK? I think putting a note in the directive pointing people to http://httpd.apache.org/docs/2.2/mod/mod_ldap.html#settingcerts will save some questions on mailing lists. Sure. If we tweak the code to disallow vhost coding for libraries where we know it doesn't work, that will affect the wording.
Re: mod_cgid not able to handle large POST request
On 3/31/06, pradeep kumar [EMAIL PROTECTED] wrote: One more detail. I get this error only on commenting out the Scriptsock directive. When I use this directive though I have no trouble in running the script. Is there more than one Apache instance with same ServerRoot, such that using the default ScriptSock results in multiple instances trying to use the same Unix socket? I assume you set Scriptsock to a non-default value?
Re: prefork mpm in linux: ap_process_connection isn't called on connection
On 3/28/06, Rian A Hunter [EMAIL PROTECTED] wrote: On the httpd trunk in prefork.c ap_process_connection isn't called until there is data on the new connection (instead of just when a client connects). Is there a kernel accept filter enabled?
PR 31759 - default handler returns output filter apr_status_t value
Some discussion has taken place in bugzilla but more discussion and
opinions are needed.
A patch recently posted:
Index: server/core.c
===
--- server/core.c (revision 386843)
+++ server/core.c (working copy)
@@ -3645,7 +3645,16 @@
e = apr_bucket_eos_create(c-bucket_alloc);
APR_BRIGADE_INSERT_TAIL(bb, e);
-return ap_pass_brigade(r-output_filters, bb);
+status = ap_pass_brigade(r-output_filters, bb);
+if (status == APR_SUCCESS
+|| r-status != HTTP_OK
+|| c-aborted) {
+return r-status;
+}
+else {
+/* no way to know what type of error occurred */
+return HTTP_INTERNAL_SERVER_ERROR;
+}
}
else { /* unusual method (not GET or POST) */
if (r-method_number == M_INVALID) {
Some concerns about the else path:
a) is 500 proper? should it just return OK instead?
b) what about logging that path to ensure that the administrator has
some help diagnosing the problem, since we can't carry the
apr_status_t any further than here?
There are concerns of too much logging (filter has already logged
something) or too little logging (filter didn't log anything). The
access log won't have any strong hints that something bad happened
since r-status didn't get changed and c-aborted didn't get set.
Thoughts?
Re: PR 31759 - default handler returns output filter apr_status_t value
On 4/1/06, Ruediger Pluem [EMAIL PROTECTED] wrote: On 03/31/2006 06:53 PM, Jeff Trawick wrote: Some concerns about the else path: a) is 500 proper? should it just return OK instead? I think 500 is good. b) what about logging that path to ensure that the administrator has some help diagnosing the problem, since we can't carry the apr_status_t any further than here? There are concerns of too much logging (filter has already logged something) or too little logging (filter didn't log anything). The access log won't have any strong hints that something bad happened since r-status didn't get changed and c-aborted didn't get set. What about the debug level for this log message? Would this be a compromise between too much logging and no logging? yep ;) I'll move the patch to trunk, change it to return OK where original patch returned r-status, integrate your logging patch, and commit, if it holds up under more varied testing.
Re: [VOTE] Release 2.2.1 as GA
On 4/1/06, Steffen [EMAIL PROTECTED] wrote: No go on win32: unresolved external symbol [EMAIL PROTECTED] referenced in function _show_compile_settings .\Release/httpd.exe : fatal error LNK1120 Didn't a Windows guy make that change? (duck)
Re: svn commit: r391025 - /httpd/httpd/trunk/server/core.c
On 4/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jim Date: Mon Apr 3 05:10:22 2006 New Revision: 391025 URL: http://svn.apache.org/viewcvs?rev=391025view=rev Log: We actually want to reach the rest of the code :) Thanks for cleaning up after me!!!
[PATCH] htdbm: warn crypt-enabled users that plaintext format won't work
Index: support/htdbm.c === --- support/htdbm.c (revision 390811) +++ support/htdbm.c (working copy) @@ -308,6 +308,10 @@ case ALG_PLAIN: /* XXX this len limitation is not in sync with any HTTPd len. */ apr_cpystrn(cpw,htdbm-userpass,sizeof(cpw)); +#if APR_HAVE_CRYPT_H +fprintf(stderr, Warning: Plain text passwords aren't supported by the +server on this platform!\n); +#endif break; #if APR_HAVE_CRYPT_H case ALG_CRYPT: FWIW, when you choose crypt() you see CRYPT is now deprecated, use MD5 instead! As I understand the plaintext password issue: In the database file, there are special denotations for md5 and sha1 password hashes, and if there is no denotation then the server expects (defaults to) crypt() format. But on Windows no crypt() function is available, so no denotation means plaintext format there. 1) design issue: file format doesn't have a delimeter for plain text, so a server on Unix has no way to support plaintext passwords 2) usability issue: htdbm doesn't warn users on platforms with crypt() that it is fruitless to specify plaintext format for password
Re: [PATCH] htdbm: warn crypt-enabled users that plaintext format won't work
On 4/3/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Taking things one step further, sha1 is far preferred for cryptographic purposes these days than md5. Suppose its time to switch? Also, get htpasswd and htdbm defaults in sync. htpasswd says it defaults to CRYPT where crypt() is available. To the extent that modern htdbm and htpasswd are provided solely for user/pass verification with Apache 2.0 or above, there should be no migration problems caused by changing the default hash mechanism as long as we don't change the default TO crypt or plaintext (since those are unsafe when moving files across platforms).
Re: httpd size grows on restart with mod_php enabled
On 4/5/06, pradeep kumar [EMAIL PROTECTED] wrote: Hi, I see httpd grows in size on every restart/graceful restart with PHP(4 or 5) enabled. But this doesn't happen when I do a stop and start. Also this problem is seen only when mod_php is enabled. Is this a know problem with PHP or Apache? Take out PHP, leave everything else the same, and try again. I would expect: * very very small growth with just Apache-distributed modules (i.e., you'd have to restart hundreds of times before the growth would cause real operational problems * no core Apache problems which lead to unavoidable memory growth problems in third-party modules
Re: httpd size grows on restart with mod_php enabled
On 4/5/06, pradeep kumar [EMAIL PROTECTED] wrote: Yep I tried that. without mod_php there is no growth in the size. So does that mean this is a bug with PHP then. PHP is the suspected component and would need to investigate.
Re: Bug in 2.0.56-dev
On 4/8/06, Alexander Lazic [EMAIL PROTECTED] wrote: on 05-04-2006 i have get the latest snapshots from: http://cvs.apache.org/snapshots/ httpd-2.0.x_20060405102636.tar.gz apr-0.9.x_20060405102142.tar.gz apr-util-0.9.x_20060405102200.tar.gz Build it on solaris 10 x86 with gcc. ./configure --prefix=/web/apache-2.0.56 --with-mpm=worker --enable-so \ --enable-rewrite --disable-userdir --disable-imap --disable-cgi \ --disable-cgid --disable-asis --enable-http --enable-ssl\ --enable-headers --enable-expires --enable-deflate \ --disable-charset-lite --enable-rule=SHARED_CORE \ CFLAGS='-DSHARED_CORE -DUSE_SSL' CPPFLAGS='-DSHARED_CORE -DUSE_SSL' \ --with-ssl=/usr/local/ssl --enable-proxy --enable-proxy-http After 'make install' i started apache, then some seconds later i got the message '...MaxClients reached...' but there was no entry in the access log, and nobody have make a request to this server. What i have also see httpd forks StartServers-processes. Is this a known bug?! y; I've been looking at this type of problem for a few days... hopefully I can post a patch before long Apache works fine except for that bogus message, right? There are problems accounting for child processes which are trying to initialize that result in the parent thinking it needs to create more children. The less harmful flavor is when it thinks (incorrectly) it is already at MaxClients and issues the reached MaxClients message. More disturbing is when MaxClients is very high and the parent keeps creating new children using exponential ramp-up. That can be very painful.
Re: Bug in 2.0.56-dev
On 4/10/06, Alexander Lazic [EMAIL PROTECTED] wrote: Hi, On Mon 10.04.2006 09:52, Jeff Trawick wrote: On 4/8/06, Alexander Lazic [EMAIL PROTECTED] wrote: Is this a known bug?! y; I've been looking at this type of problem for a few days... hopefully I can post a patch before long Thanx for your positive answer ;-) Apache works fine except for that bogus message, right? Hm yes but the multipart-post Bug# 37145 seams to be still a problem :-( fair enough; I should have asked about any ill behavior also attributed to the bogus reached MaxClients message ;)
Re: svn commit: r392948 - /httpd/httpd/branches/2.2.x/STATUS
On 4/10/06, Ruediger Pluem [EMAIL PROTECTED] wrote: On 04/10/2006 03:58 PM, trawick wrote: - +* htdbm: Warn when the user adds a plaintext password on a platform + with crypt(). The server will assume that the format is crypt(). +Trunk version of patch: + http://svn.apache.org/viewcvs?rev=392945view=rev I guess you mean r392944 :-). yes :)
Re: svn commit: r392948 - /httpd/httpd/branches/2.2.x/STATUS
On 4/10/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Nick Kew wrote: Whilst this is clearly an edge-case, is it necessarily true that any platform with APR_HAVE_CRYPT won't support plaintext passwords? AIUI - apache has always been an either or - it's either plaintext on platforms without crypt, or crypt on platforms with such support. Right; quite bogusly, the file format is even busted... There is a decoration for md5 hash and a decoration for sha1 has, but no decoration means: a) platform-has-crypt - treat the undecorated password hash as crypt-ed; no provision for plaintext b) platform-does-not-have-crypt - treat the undecorated password hash as plaintext
Re: svn commit: r393032 - /httpd/httpd/branches/2.0.x/STATUS
On 4/10/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: This pool is or is not created in the parent? If its the parent it's gotta be proc mutexed even if using prefork. It is created in the parent and used only during request processing. Why does it need to be proc mutexed? Each process has its own copy. There is no shared memory involved. (Windows: each child creates a copy when the config gets processed in the child) If it's process-local, then please don't depend on APR_THREADED, please please please poll the MPM to determine if the mpm has_threads? It's a huge waste for prefork users with a shared (threaded) apr :( That minor performance improvement for some (lots of?) prefork users should first be addressed in trunk, and implementation/backport of that should not hold up this critical bug fix.
Re: svn commit: r393032 - /httpd/httpd/branches/2.0.x/STATUS
On 4/11/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jeff Trawick wrote: On 4/10/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: This pool is or is not created in the parent? If its the parent it's gotta be proc mutexed even if using prefork. It is created in the parent and used only during request processing. Why does it need to be proc mutexed? Each process has its own copy. There is no shared memory involved. Ah... of course. The pages are copy-on-write. So there is no proc mutexing issue :) If it's process-local, then please don't depend on APR_THREADED, please please please poll the MPM to determine if the mpm has_threads? It's a huge waste for prefork users with a shared (threaded) apr :( That minor performance improvement for some (lots of?) prefork users should first be addressed in trunk, and implementation/backport of that should not hold up this critical bug fix. But the code is there, and what we are using in mod_ssl and others. Please don't inject a regression where we already cleaned these up once before :( Nobody ever cleaned up ldap. Now there are perhaps 9 occurrences of a pattern to replace instead of 8. (didn't count exactly) It is a HUGE stretch to call that a regression, since anybody that wants to fix it has to search for the pattern anyway. People have had several years to get around to that performance improvement and nobody cared so far.
Re: svn commit: r392948 - /httpd/httpd/branches/2.2.x/STATUS
On 4/11/06, Jorge Schrauwen [EMAIL PROTECTED] wrote: Can emulaion crypt on platforms that don't support it? or will this be to slow? A crypt() implementation could be provided for these platforms whose system libraries don't already have it.
migration concerns changing default hash in htpasswd/htdbm to sha1 for 2.2.x?
As long as the default doesn't change *to* crypt/plaintext, nobody is hurt, right? Or do we support the use of htpasswd/htdbm to build password files for other applications, which might not use apr-util to check the user/passwd record? (Those users would need to start overriding the defaults to make it store in the same format as before.)
Re: [PATCH] #39275 MaxClients on startup [Was: Bug in 2.0.56-dev]
On 4/11/06, Chris Darroch [EMAIL PROTECTED] wrote:
Hi --
Alexander Lazic wrote:
After 'make install' i started apache, then some seconds later i got the
message '...MaxClients reached...' but there was no entry in the access
log, and nobody have make a request to this server.
Jeff Trawick wrote:
There are problems accounting for child processes which are trying to
initialize that result in the parent thinking it needs to create more
children. The less harmful flavor is when it thinks (incorrectly) it
is already at MaxClients and issues the reached MaxClients message.
More disturbing is when MaxClients is very high and the parent keeps
creating new children using exponential ramp-up. That can be very
painful.
I have been seeing something similar with 2.2.0 using the worker
MPM, where with the following settings, I get over 10 child processes
initializing immediately (e.g., up to 15), and then they drop back to
10. I see the server reached MaxClients message as well right
after httpd startup, although nothing is connecting yet.
IfModule mpm_worker_module
StartServers 10
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 100
ThreadsPerChild 10
/IfModule
In my case, the problem relates to how long the child_init phase
takes to execute. I can tune this by raising DBDMin (and DBDKeep)
so that mod_dbd attempts to open increasingly large numbers of
DB connections during child_init. With DBDMin set to 0 or 1,
all is well; no funny behaviour. Up at DBDMin and DBDKeep at 3,
that's when (for me) things go pear-shaped.
In server/mpm/worker/worker.c, after make_child() creates a
child process it immediately sets the scoreboard parent slot's pid
value. The main process goes into server_main_loop() and begins
executing perform_idle_server_maintenance() every second; this
looks at any process with a non-zero pid in the scoreboard and
assumes that any of its worker threads marked SERVER_DEAD are,
in fact, dead.
However, if the child processes are starting slowly because
ap_run_child_init() in child_main() is taking its time, then
start_threads() hasn't even been run yet, so the threads aren't
marked SERVER_STARTING -- they're just set to 0 as the default
value. But 0 == SERVER_DEAD, so the main process sees a lot
of dead worker threads and begins spawning new child processes,
up to MaxClients/ThreadsPerChild in the worst case. In this case,
when no worker threads have started yet, but all possible child
processes have been spawned (and are working through their
child_init phases), then the following is true and the
server reached MaxClients message is printed, even though
the server hasn't started accepting connections yet:
else if (idle_thread_count min_spare_threads) {
/* terminate the free list */
if (free_length == 0) {
I considered wedging another thread status into the
scoreboard, between SERVER_DEAD (the initial value) and
SERVER_STARTING. The make_child() would set all the thread
slots to this value and start_threads() would later flip them
to SERVER_STARTING after actually creating the worker threads.
That would have various ripple effects on other bits of
httpd, though, like mod_status and other MPMs, etc.
In other words, breaks binary compatibility...
Other modules should see the threads in SERVER_STARTING state anyway.
IOW, I think we should set state to SERVER_STARTING before we do any
potentially-lengthy work like running child-init hooks so that the
state as seen from the outside makes sense. That also means resetting
the state if something fails (e.g., pthread_create()).
But that isn't needed for proper operation of the MPM, which is what
we're after at the moment... But it would be great to be able to see
from mod_status that a child is taking way too long in the
SERVER_STARTING state.
So instead
I tried adding a status field to the process_score scoreboard
structure, and making the following changes to worker.c such that
this field is set by make_child to SERVER_STARTING and then
changed to SERVER_READY once the start thread that runs
start_threads() has done its initial work.
I was considering adding something to process_score for this issue but
I decided against it, hopefully for an bogus reason -- binary
compatibility breakage.
This isn't binary compatibility breakage since we provide
ap_get_scoreboard_process() for modules to retrieve a process_score
structure, and if fields get added to the end for the use of the MPM
then no worries since we don't support modules creating their own
process_score structures and stuffing them in the scoreboard.
(confirmation from the crowd?)
Instead of unsigned char status I'd prefer something like
apr_int32_t mpm_state; /* internal state for MPM; meaning may change
Re: svn commit: r393868 - in /httpd/httpd/trunk/server/mpm: experimental/event/event.c worker/worker.c
On 4/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: gregames
Date: Thu Apr 13 10:53:04 2006
New Revision: 393868
URL: http://svn.apache.org/viewcvs?rev=393868view=rev
Log:
MaxClients isn't the only reason the scoreboard can fill up. another
reason should be fixed soon.
if (!reported) {
-ap_log_error(APLOG_MARK, APLOG_ERR, 0,
- ap_server_conf,
- server reached MaxClients setting, consider
- raising the MaxClients setting);
+if (active_thread_count =
+ap_daemons_limit * ap_threads_per_child) {
+ap_log_error(APLOG_MARK, APLOG_ERR, 0,
+ ap_server_conf,
+ server reached MaxClients setting,
consider
+ raising the MaxClients setting);
+}
+else {
+ap_log_error(APLOG_MARK, APLOG_ERR, 0,
+ ap_server_conf,
+ scoreboard is full, not at MaxClients);
+}
reported = 1;
Plz confirm...
After a fix to prevent the fork bomb during slow child startup is
applied, something REALLY strange and completely unanticipated has to
happen to get the scoreboard is full, not at MaxClients message.
True? Otherwise, seeing one of these messages shouldn't prevent us
from ever seeing the other.
From a user support perspective, it is very handy to be able to have
the user grep for server reached MaxClients to rule out a particular
type of issue, without worrying if some odd temporary situation hid
that message forever.
Re: Large file support in 2.0.56?
On 4/15/06, Brandon Fosdick [EMAIL PROTECTED] wrote: I might have asked this before, but I've forgotten the answer, and so has google. Has any of the large file goodness from 2.2.x made it into 2.0.x? Will it ever? Different answer than you got before, but I think this is more accurate (Joe?): Turn on your OS's large file flags in CFLAGS make distclean CFLAGS=-D_something ./configure and you get the support. This isn't the default with APR 0.9.x (and thus Apache httpd 2.0.x) because it breaks binary compatibility with existing builds. As long as you use only modules that you can recompile and don't have bugs exposed only with large file support enabled you should be okay.
Re: [VOTE] Apache HTTP Server 1.3.35 Candidate
On 4/24/06, Jim Jagielski [EMAIL PROTECTED] wrote: Please test and vote on releasing Apache httpd 1.3.35 +1 tested on AIX 5.3; CC=xlc_r learned a new svn command after all these webyears svn diff http://svn.apache.org/repos/asf/httpd/httpd/tags/1.3/APACHE_1_3_34 http://svn.apache.org/repos/asf/httpd/httpd/tags/1.3/APACHE_1_3_35
Re: [VOTE] 2.0.58 Candidate
On 4/24/06, Colm MacCarthaigh [EMAIL PROTECTED] wrote: O.k., for the last time, hopefully :) A candidate for 2.0.58 is available for testing and voting at; http://httpd.apache.org/dev/dist/ +1 tested on AIX 5.3, CC=xlc_r
Re: [PATCH] #39275 MaxClients on startup [Was: Bug in 2.0.56-dev]
On 5/1/06, Greg Ames [EMAIL PROTECTED] wrote: Jeff Trawick wrote: after more thought, there is a simpler patch that should do the job. the key to both of these is how threads in SERVER_DEAD state with a pid in the scoreboard are treated. this means that p_i_s_m forked on a previous timer pop but some thread never made it into SERVER_STARTING state. the difference: this patch just counts those potential threads as idle, and allows MinSpareThreads worth of processes to be forked before putting on the brakes. the previous patch pauses the forking immediately when the strange situation is detected but requires more code and a new variable. new patch is fine with me; I think we've lost our other interested parties on this thread anyway ;)
Re: [PATCH] #39275 MaxClients on startup [Was: Bug in 2.0.56-dev]
On 5/2/06, Chris Darroch [EMAIL PROTECTED] wrote: If you can bear with me for a day or two more, I should have a collection of patches ready. These tackle the issue by tracking the start and listener threads in a nice new spot in the scoreboard, and also clean up various issues and bugs relating to fork(), ThreadLimit, ServerLimit, MaxClients, etc. They also tackle some issues raised in various XXX comments and clean up some stale cruft in scoreboard.h. Note that perform_idle_server_maintenance() can't depend on the child process to put stuff in the scoreboard in order to avoid a fork bomb. Assume fork() stalls for 30 seconds in the child before returning to our code, and make sure there is no opportunity for ramping up the number of processes while we wait for a child to get a chance to initialize.
Re: svn commit: r399665 - /httpd/httpd/trunk/modules/filters/mod_charset_lite.c
On 5/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: trawick Date: Thu May 4 04:18:45 2006 New Revision: 399665 URL: http://svn.apache.org/viewcvs?rev=399665view=rev Log: Stop returning DECLINED from the output filter for proxy requests. FWIW, this is a rather obscure codepath. mod_charset_lite won't insert its filters automatically for proxy requests. The user would have to explicitly add them via one of the filter configuration directives.
Re: svn commit: r404850 - in /httpd/httpd/trunk/server/mpm: experimental/event/event.c worker/worker.c
On 5/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: niq Date: Sun May 7 14:03:39 2006 New Revision: 404850 URL: http://svn.apache.org/viewcvs?rev=404850view=rev Log: Initialise server generation (Chris Darroch) Modified: httpd/httpd/trunk/server/mpm/experimental/event/event.c httpd/httpd/trunk/server/mpm/worker/worker.c Modified: httpd/httpd/trunk/server/mpm/experimental/event/event.c URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/server/mpm/experimental/event/event.c?rev=404850r1=404849r2=404850view=diff == --- httpd/httpd/trunk/server/mpm/experimental/event/event.c (original) +++ httpd/httpd/trunk/server/mpm/experimental/event/event.c Sun May 7 14:03:39 2006 @@ -395,7 +395,7 @@ static int volatile restart_pending; static int volatile is_graceful; static volatile int child_fatal; -ap_generation_t volatile ap_my_generation; +ap_generation_t volatile ap_my_generation = 0; Too many people are confused about what the value of global variables is guaranteed to be. IMHO, adding initialization of one variable just feeds the fire.
Re: svn commit: r404849 - /httpd/httpd/trunk/include/scoreboard.h
On 5/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: niq Date: Sun May 7 14:01:48 2006 New Revision: 404849 URL: http://svn.apache.org/viewcvs?rev=404849view=rev Log: Tidy up scoreboard.h (Chris Darroch) cool; forgot to +1 this and a couple of others
Re: svn commit: r404851 - /httpd/httpd/trunk/CHANGES
On 5/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: niq Date: Sun May 7 14:07:14 2006 New Revision: 404851 URL: http://svn.apache.org/viewcvs?rev=404851view=rev Log: Note scoreboard stuff in changes; leave the 'difficult' patches to see if they attract any more review. Modified: httpd/httpd/trunk/CHANGES Modified: httpd/httpd/trunk/CHANGES URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/CHANGES?rev=404851r1=404850r2=404851view=diff == --- httpd/httpd/trunk/CHANGES [utf-8] (original) +++ httpd/httpd/trunk/CHANGES [utf-8] Sun May 7 14:07:14 2006 @@ -2,6 +2,8 @@ Changes with Apache 2.3.0 [Remove entries to the current 2.0 and 2.2 section below, when backported] + *) Tidy up scoreboard [Chris Darroch chrisd pearsoncmg.com ] Remove some obsolete declarations and comments from scoreboard.h. [...] ? The scoreboard looks the same AFAICT ;) (Some programmers may care.)
Re: svn commit: r404851 - /httpd/httpd/trunk/CHANGES
On 5/7/06, Nick Kew [EMAIL PROTECTED] wrote: On Sunday 07 May 2006 22:35, Jeff Trawick wrote: Remove some obsolete declarations and comments from scoreboard.h. [...] ? The scoreboard looks the same AFAICT ;) (Some programmers may care.) There's the memory fix too. so extra memory was allocated on Win32 (is that where we do calloc?) But it's also a placeholder for the two remaining patches, which are still under discussion. okay, so when that's done then CHANGES will have some different text
Re: [PATCH 5/6] hard restart on Linux #38737
On 5/7/06, Nick Kew [EMAIL PROTECTED] wrote: On Thursday 04 May 2006 19:16, Chris Darroch wrote: +#ifdef HAVE_PTHREAD_KILL +unblock_signal(WORKER_SIGNAL); +apr_signal(WORKER_SIGNAL, dummy_signal_handler); +#endif + OK, unblock a signal. This happens after child_init, but presumably won't interfere with existing modules 'cos a module that attaches a handler for that in a child_init wouldn't have worked before, either. AP_SIG_GRACEFUL is our signal to play with. Modules can't change how that is delivered and expect the server to work reliably. Question: what other side-effects might this have? unpredictable if somebody/something sends AP_SIG_GRACEFUL to the child process; it will land on random worker thread (it might be nice for debugging if you could make processes gracefully exit by sending them the signal; but we don't have such code so I don't see how using it for this intra-child communication will break anything) APR generally eats signals. The app can set a flag in their signal handler and check later, but APR won't return EINTR except from a couple of functions (poll and accept perhaps?). So there is the possibility that the signal won't prod the worker thread from wherever it is But that's no worse than today, and we still close the socket. Anyone recollect why signals are commonly blocked in the child processes? We want the main thread in the child process to see any signals and the worker and listener threads to be oblivious to signals. If a third-party module has its own thread and uses a signal for its own purpose, it unblocks that signal on its thread and we're oblivious.
Re: Dealing with Regressions
On 5/8/06, Nick Kew [EMAIL PROTECTED] wrote: OK, we all know we get some embarrassing regressions in our new releases. PR#39490 in 1.3.35. Or 2.0.55 being effectively unusable in a proxy due to PR#37145. Look at the number of duplicates of 37145 - that's a lot of people with the confidence to report it, and who didn't find it 'cos it's marked as fixed (despite no fixed version being released until last week). We should do better than leaving the users to rediscover and deal with regressions themselves, once we know there's a problem. Can I suggest an Errata page, to list *all* known regressions in current/recent versions, linked from the main page alongside Download/New Features/Changelog? +1 [REGRESSION] in the changelog might be good too for permanent tracking. Most useful would be to ship a new version within a small amount of time that corrects only regressions and has no other changes (if at all practical; desire is to limit testing concern to speed up delivery).
conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
(ignore issues of support for particular versions of Apache) google pretends to know a lot about this general question, but it seems to be in discussions between general users with the same curiosity and there is little or no developer input. OTOH, there is a great indication that Tomcat connector FAQ and httpd documentation could help a lot of people by presenting the same conclusion, whatever that happens to be ;) Are there key design issues which will make one better than the other assuming each has enough developer attention to fix code bugs? Are there still fundamental pieces missing from mod_proxy_ajp + mod_proxy_balancer which have to be resolved before mod_proxy_ajp is the natural solution for anybody on Apache = 2.2? When should somebody use mod_proxy_http [+ mod_proxy_balancer] instead of one of these solutions? The Tomcat connectors FAQ says this: ---snip # mod_jk is great and should be used for production. It is getting fixes as needed (which is now rare). # mod_proxy. A cheap way to proxy without the hassles of configuring JK. This solution lacks sticky session load balancing. If you don't need some of the features of jk, jk2 - this is a very simple alternative. # mod_proxy_ajp. With apache 2.2, mod_proxy was rewritten to support load balancing as well as a new transport called mod_proxy_ajp. This module is distributed with the Apache http server, not the Tomcat server. ---snip--- Isn't pass-through of client SSL connection information another problem with mod_proxy? (servlets can't access cipher or client certificate)
Re: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
On 5/27/06, Ruediger Pluem [EMAIL PROTECTED] wrote: On 05/27/2006 03:58 PM, Jeff Trawick wrote: Are there still fundamental pieces missing from mod_proxy_ajp + mod_proxy_balancer which have to be resolved before mod_proxy_ajp is the natural solution for anybody on Apache = 2.2? Currently mod_proxy_balancer lacks the domain feature of mod_jk, but I do not know if this is regarded as fundamental piece. shrug Isn't pass-through of client SSL connection information another problem with mod_proxy? (servlets can't access cipher or client certificate) AFAIK not with mod_proxy_ajp. It seems to pass all these information to Tomcat. oops, I meant ... problem with using generic HTTP support with mod_proxy -- mod_proxy_http; I agree, the functional problem doesn't apply to mod_proxy_ajp
Re: svn commit: r411306 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c
On 6/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bnicholes Date: Fri Jun 2 15:01:53 2006 New Revision: 411306 URL: http://svn.apache.org/viewvc?rev=411306view=rev Log: Fix a problem with invalid auth error detection for LDAP client SDKs that don't support LDAP_SECURITY_ERROR macro. PR#39529 Should we define our own macro which uses LDAP_SECURITY_ERROR or the more detailed logic, to keep the mainline code cleaner and support reuse in other paths?
Re: AW: restructuring mod_ssl as an overlay
On 6/8/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Plüm wrote: Von: Joe Orton I don't see why it's necessary for the ASF to be in the business of distributing binaries; letting other people assume the technical and legal responsibilites for doing that seems reasonable. Ahhh, the preface of what Roy pointed out. Yes of course, since that's what pays your salary I'm not terribly surprised... tread lightly... very easy to be misinterpreted here, particularly by random users... (other people being the Red Hats, IBMs, Covalents, HPs, Suns etc etc.) Just curious: does anybody in that boat actually think that anything we httpd-ers could do with packaging httpd (binaries, SSL,etc.) would conceivably compete with what our employers are providing? (I find that preposterous personally) (OTOH, if there is a solid business case for providing simply a binary of httpd with suitable features that is known to work on at least some handful of machines, please let me know ;) )
Re: debug apache
On 6/17/06, Nick Kew [EMAIL PROTECTED] wrote: On Saturday 17 June 2006 09:47, Ruediger Pluem wrote: On 06/17/2006 08:57 AM, Alexander Lazic wrote: On Sam 17.06.2006 00:54, Ruediger Pluem wrote: From my current point of view the answer is: No, this is not possible out of the box. It may be possible if you modify the hook macros. yep Getting inside these macros is what enables diagnostic features such as a) mod_status display of where a request is being held up b) pinpoint of the crashing module in a mod_whatkilledus report c) logging the module and phase where a request was handled/failed in the access log (put a string in r-subprocess_env for logging when a module causes the hook run to stop) And do you think that the developer would accept a patch for apache 2.x and would apply it? Depends on the patch :-). Please take into account that these macros are part of apr-util. So this discussion belongs to [EMAIL PROTECTED] Currently I have not made any thoughts how these macros could be modified in a way such that they play together with httpd logging. I think you'd be far better off with a generic trace such as strace. They're made for precisely this kind of thing. Solaris truss can be used to obtain this type of information. I don't know how to accomplish it elsewhere.
Re: debug apache
On 6/18/06, Ruediger Pluem [EMAIL PROTECTED] wrote:
On 06/18/2006 04:03 PM, Jeff Trawick wrote:
On 06/17/2006 08:57 AM, Alexander Lazic wrote:
On Sam 17.06.2006 00:54, Ruediger Pluem wrote:
From my current point of view the answer is: No, this is not
possible
out of the box.
It may be possible if you modify the hook macros.
yep
Getting inside these macros is what enables diagnostic features such as
a) mod_status display of where a request is being held up
But this feature is not in our codebase, right? Is it a patch to the macros
+ an additional module that hooks itself into the status_hook? Just curious.
not in our code base
what I do is replace stuff like
ap_run_handler (a macro)
with
foo_run_handler (a function)
which will check ap_extended_status; if off, it will just return
ap_run_handler;
otherwise, it essentially has the macro expansion, but it has the
following logic around the module call:
worker_score-module_index = handler_modindexes[n];
rv = pHook[n].dummy(r);
if (rv != DECLINED) {
worker_score-module_index = 0;
apr_table_set(r-subprocess_env,
REQUEST_ENVVAR,
apr_psprintf(r-pool,
(%s/%d/handler),
modnames[handler_modindexes[n]],
rv);
return rv;
}
If we reach the end without a module handling it:
worker_score-module_index = 0;
return DECLINED;
At initialization, the handler_modindexes function is built to
correspond to the hook_array.
Meanwhile, mod_status and a few other diagnostic modules know how to
turn a module index into a module name.
I put this problem determination aid in four hook calls which have
proven interesting w.r.t. third-party modules: handler, access
checker, check user id, log transaction. I didn't care about any
performance difference between a hook macro in mainline vs. call to a
function which checks ap_extended_status and then invokes the macro.
I did check the CPU usage difference between ExtendedStatus on and
ExtendedStatus off after adding this logic. It is still in the
neighborhood of a 1-2% increase, which is well worth it.
--/--
[EMAIL PROTECTED] or [EMAIL PROTECTED]
Implementation wise, what we are using is not a simple function call
or two which could be cleanly inserted into the apr-util hook macro
expansion. The problem determination aid is dependent on
* the data structures behind the hook macros
* the Apache module index, which needs to be stored in those data
structures or in a parallel data structure so that it can be accessed
efficiently while walking through the hook array
* the worker_score
If httpd *developers* are interested, we should decide what type of
processing is acceptable/required first and worry about whether it can
be fitted into apr second. As I recall from the last discussion of
this perhaps 15 months ago, most all of the interest was from web
admin lurkers, and there was insufficient developer interest anyway.
Re: debug apache
On 6/20/06, Alexander Lazic [EMAIL PROTECTED] wrote: On Mon 19.06.2006 07:07, Jeff Trawick wrote: If httpd *developers* are interested, we should decide what type of processing is acceptable/required first and worry about whether it can be fitted into apr second. As I recall from the last discussion of this perhaps 15 months ago, most all of the interest was from web admin lurkers, and there was insufficient developer interest anyway. Ok from your point of view *all* admins *must* be a little *developer* to be able to dig into the httpd/apr-source if a wished config don't work as assumed, no help from poduct to help to find the error :-( Well i'am very unhappy about this conclusion but well it's an market leader worthily. From me i take that in the near future there will not be a help to find config errors without truss/strace or other generic tools. I certainly don't mean any negative feelings towards admins. My conclusion is simply the combination of * firm belief that this type of feature shouldn't be added to the software without multiple motivated developers * expectation that there wouldn't be multiple motivated developers A past discussion of very closely related functionality, though not exactly what you asked for originally, yielded multiple interested admin-type folks and no developers expressing interest other than myself.
Re: [Patch 39806] Add env vars to mod_proxy_balancer to allow more control
On 6/20/06, Brian Rectanus [EMAIL PROTECTED] wrote: I have a minor patch to mod_proxy_balancer that I would like to get applied. The patch adds some environment vars to balancer requests to export info on the chosen route so that it possible to control sticky sessions entirely from the reverse proxy instead of modifying the backend app/server to add a route. http://issues.apache.org/bugzilla/show_bug.cgi?id=39806 Comments? +1 (concept; I like the idea but need to review code a little more closely) Any other opinions on the simple patch?
Re: Help Please
On 7/4/06, Tiago Semprebom [EMAIL PROTECTED] wrote: ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,IP value: %d,csd-connected); Why the csd don't appear to me like a structure allow-me to access their filds like connected, remote_addr, etc? The structure definition is available only within the implementation of APR; it is not available within the web server. FWIW, the connected flag down in APR is not so interesting anyway. What are you trying to debug or trace?
Re: svn commit: r425561 - /httpd/httpd/branches/2.2.x/STATUS
On 7/26/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: * mod_isapi: Simply backport the host of fixes for compilation on unix, PR#'s 15993 29098 30022 16637 30033 28089 by pushing to trunk/ rev 416293 of modules/arch/win32/mod_isapi.[ch] which compiles without changes. Source + Binary posted at http://people.apache.org/~wrowe/mod_isapi-416293.zip - +1 wrowe + +1 wrowe , fielding Thanks Roy. We have a number of positive responses to the half dozen bugzilla incidents this closed. Apparently, for some time since the core request handling was changed in httpd 2.0 (pre 2.2) mod_isapi was invalidated. I'd like to push this out ASAP to 2.2 and 2.0 with the TR this week, if a few others would cast their votes. It is a bit odd to have to download a zip and (I guess) create my own diff against the appropriate branch. Feel free to convert this into byte-sized chunks that require a minimum of fuss if you don't get another review in the desired timeframe.
Re: High CPU utilization on using Apache as a reverse proxy
On 8/14/06, pradeep kumar [EMAIL PROTECTED] wrote: More info.. The problem is seen with 2.0.55. It wasn't seen with 2.0.53. Haven't tried 2.0.58 or 2.0.59 yet. The change log for 2.0.58 doesn't seem to indicate any fix for this problem. Here is a patch for the proxy connect path for a similar problem: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c?r1=154199r2=306878sortby=date The fix is not in 2.0.x. Do you have proxy connect enabled?
Re: [PATCH 40026] ServerTokens Off
On 8/11/06, Sebastian Nohn [EMAIL PROTECTED] wrote: And now patches against trunk are available too (attached to this mail). A little more work is required. With this trunk patch and ServerTokens Off, this is logged at startup: [Mon Aug 14 13:54:19 2006] [notice] configured -- resuming normal operations By default: [Mon Aug 14 13:53:45 2006] [notice] Apache/2.3.0-dev (Unix) DAV/2 configured -- resuming normal operations The issue is that ap_get_server_version() is used for multiple uses: a) a banner (for the lack of a better word) to be used on the wire b) a string that tells the version of the server What do folks think about the following change? Rename existing ap_get_server_version() to ap_get_server_banner() Change code that builds strings to send on the wire to call ap_get_server_banner() instead. ap_get_server_version() always spits out something like Apache/2.2.4-dev (AP_SERVER_BASEVERSION AFAICT)
Re: [PATCH 40026] ServerTokens Off
On 8/14/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jeff Trawick wrote: ap_get_server_version() always spits out something like Apache/2.2.4-dev (AP_SERVER_BASEVERSION AFAICT) Plus wiring in the registered module strings? I think that's extraordinarily useful information when walking in blind to a configuration problem, and would hate to lose it. ... So if the 'version' flavor includes the extra modules and long version number tokens, I'm ++1 for the change. No problems here... I'll work up a patch just to distinguish between banner and version. Any subsequent ServerTokens None patch would then be a modification to ap_get_server_banner().
Re: High CPU utilization on using Apache as a reverse proxy
On 8/16/06, pradeep kumar [EMAIL PROTECTED] wrote:
Yep, proxy_connect has been enabled. So we dont have an equivalent patch for
2.0? As I mentioned the problem is seen with 2.0.55 and not 2.0.53.
There's no reason the patch can't be put into 2.0... Apply this patch
and report back on whether or not it resolves your problem, and we can
see about getting it in the next 2.0.x release. Thanks!
Index: modules/proxy/proxy_connect.c
===
--- modules/proxy/proxy_connect.c (revision 431472)
+++ modules/proxy/proxy_connect.c (working copy)
@@ -339,8 +339,10 @@
else
break;
}
-else if ((pollevent APR_POLLERR) || (pollevent APR_POLLHUP))
+else if ((pollevent APR_POLLERR) || (pollevent APR_POLLHUP)) {
+rv = APR_EOF;
break;
+}
}
else
break;
[PATCH] split ap_get_server_version() into two functions...
... so that ServerTokens doesn't affect what gets logged to the error
log at startup (or any other place where we want the description of
the server instead of the banner to be written over the network).
This patch axes ap_get_server_version() so that third-party modules
will be forced to make a choice in post-2.2.x versions -- call
ap_get_server_banner() to retrieve the string suitable for sending
over the network (as controlled by ServerTokens) or call
ap_get_server_description() to retrieve the string that describes the
server version and certain plug-in modules.
I haven't actually changed the returned strings with this patch, but
instead would like to see any comments on the direction. The two
functions are present and all httpd code has been modified to call the
proper function, which is also subject to a useful review. What about
status pages? Is the server version and module configuration somehow
more private than the status page itself, such that they should use
ap_get_server_banner() as in the current patch?
Index: server/mpm/winnt/service.c
===
--- server/mpm/winnt/service.c (revision 438471)
+++ server/mpm/winnt/service.c (working copy)
@@ -436,7 +436,7 @@
/* Time to fix up the description, upon each successful restart
*/
-full_description = ap_get_server_version();
+full_description = ap_get_server_description();
if ((osver.dwPlatformId == VER_PLATFORM_WIN32_NT)
(osver.dwMajorVersion 4)
Index: server/mpm/winnt/mpm_winnt.c
===
--- server/mpm/winnt/mpm_winnt.c(revision 438471)
+++ server/mpm/winnt/mpm_winnt.c(working copy)
@@ -1705,7 +1705,7 @@
/* A real-honest to goodness parent */
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
%s configured -- resuming normal operations,
- ap_get_server_version());
+ ap_get_server_description());
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
Server built: %s, ap_get_server_built());
Index: server/mpm/mpmt_os2/mpmt_os2.c
===
--- server/mpm/mpmt_os2/mpmt_os2.c (revision 438471)
+++ server/mpm/mpmt_os2/mpmt_os2.c (working copy)
@@ -207,7 +207,7 @@
int listener_num, num_listeners, slot;
ULONG rc;
-printf(%s \n, ap_get_server_version());
+printf(%s \n, ap_get_server_description());
set_signals();
if (ap_setup_listeners(ap_server_conf) 1) {
@@ -270,7 +270,7 @@
ap_scoreboard_image-global-restart_time = apr_time_now();
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
%s configured -- resuming normal operations,
-ap_get_server_version());
+ap_get_server_description());
ap_log_error(APLOG_MARK, APLOG_INFO, 0, ap_server_conf,
Server built: %s, ap_get_server_built());
#ifdef AP_MPM_WANT_SET_ACCEPT_LOCK_MECH
Index: server/mpm/netware/mpm_netware.c
===
--- server/mpm/netware/mpm_netware.c(revision 438471)
+++ server/mpm/netware/mpm_netware.c(working copy)
@@ -723,7 +723,7 @@
request_count = 0;
ClearScreen (getscreenhandle());
-printf(%s \n, ap_get_server_version());
+printf(%s \n, ap_get_server_description());
for (i=0;iSERVER_NUM_STATUS;i++) {
status_array[i] = 0;
@@ -793,7 +793,7 @@
ap_listen_rec *lr;
module **m;
-printf(%s\n, ap_get_server_version());
+printf(%s\n, ap_get_server_description());
if (ap_my_addrspace (ap_my_addrspace[0] != 'O') (ap_my_addrspace[1]
!= 'S'))
printf( Running in address space %s\n, ap_my_addrspace);
@@ -899,7 +899,7 @@
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
%s configured -- resuming normal operations,
-ap_get_server_version());
+ap_get_server_description());
ap_log_error(APLOG_MARK, APLOG_INFO, 0, ap_server_conf,
Server built: %s, ap_get_server_built());
#ifdef AP_MPM_WANT_SET_ACCEPT_LOCK_MECH
@@ -1204,7 +1204,7 @@
restart();
}
else if (!strnicmp(VERSION,szcommandLine[iCommandLen],3)) {
-printf(Server version: %s\n, ap_get_server_version());
+printf(Server version: %s\n, ap_get_server_description());
printf(Server built: %s\n, ap_get_server_built());
}
else if (!strnicmp(MODULES,szcommandLine[iCommandLen],3)) {
Index: server/mpm/beos/beos.c
===
--- server/mpm/beos/beos.c (revision 438471)
+++ server/mpm/beos/beos.c (working copy)
@@ -935,7 +935,7 @@
*/
ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, ap_server_conf,
%s
Re: [PATCH] split ap_get_server_version() into two functions...
On 9/1/06, Joe Orton [EMAIL PROTECTED] wrote: On Wed, Aug 30, 2006 at 09:18:02AM -0400, Jeff Trawick wrote: ... so that ServerTokens doesn't affect what gets logged to the error log at startup (or any other place where we want the description of the server instead of the banner to be written over the network). This patch axes ap_get_server_version() so that third-party modules will be forced to make a choice in post-2.2.x versions -- call ap_get_server_banner() to retrieve the string suitable for sending over the network (as controlled by ServerTokens) or call ap_get_server_description() to retrieve the string that describes the server version and certain plug-in modules. Looks good to me. I haven't actually changed the returned strings with this patch, but instead would like to see any comments on the direction. The two functions are present and all httpd code has been modified to call the proper function, which is also subject to a useful review. What about status pages? Is the server version and module configuration somehow more private than the status page itself, such that they should use ap_get_server_banner() as in the current patch? I'd agree with Sebastian here, the mod_status output should just use the more descriptive version, if you are revealing the server state in such detail you certainly have nothing to hide. Thanks to both for commenting and to Sebastian for carrying the patch further. I'll play with Sebastian's logic to return the proper strings with the plan to commit (but still no ServerTokens None at that point).
Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c
On Wed, 06 Oct 2004 15:52:43 +0200, Mladen Turk [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: ake 2004/10/06 06:33:29 Modified:modules/arch/win32 mod_win32.c server/mpm/winnt service.c support/win32 ApacheMonitor.c Log: WIN64: fix some windows specific 64bit warnings -if (!WriteConsole(hConErr, msg, strlen(msg), result, NULL) || !result) +if (!WriteConsole(hConErr, msg, (int)strlen(msg), result, NULL) || !result) -if (!WriteConsole(hConErr, count, strlen(count), result, NULL) +if (!WriteConsole(hConErr, count, (int)strlen(count), result, NULL) -lstrcpyn(szBuf, szImagePath, sPos - szImagePath); +lstrcpyn(szBuf, szImagePath, (int)(sPos - szImagePath)); -TextOut(lpdis-hDC, XBITMAP + 6, y, szBuf, strlen(szBuf)); +TextOut(lpdis-hDC, XBITMAP + 6, y, szBuf, (int)strlen(szBuf)); Please do not do that any more. I'm sorry but I'm vetoing your patches. Use the official API, it is well documented. strlen() returns size_t, TextOut() requires int; somewhere a cast is required, no? what is a better solution?
Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c
On Wed, 06 Oct 2004 16:15:51 +0200, Mladen Turk [EMAIL PROTECTED] wrote: Jeff Trawick wrote: Please do not do that any more. I'm sorry but I'm vetoing your patches. Use the official API, it is well documented. strlen() returns size_t, TextOut() requires int; somewhere a cast is required, no? what is a better solution? That's true, but the strlen can never be int (negative). The API is DWORD meaning 32 bit unsigned integer, so either cast to API or no cast. I'm confused. The only TextOut() doc I can find says int, not DWORD. Can you provide a link? Here is where I looked: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_5yd0.asp
Re: Bug: Apache hangs if script invokes fork/waitpid
On Wed, 6 Oct 2004 11:01:23 -0700, Naik, Roshan [EMAIL PROTECTED] wrote: The Problem: --- I notice Apache 2(worker mpm) is not able to correctly handle a fork/waitpid invoked by a script used with mod_perl. From Ulrich Drepper: No threaded programs must use anything but _exit or exec after fork. Perhaps a tiny bit harsh? What if you fork a copy of a mutex used by some third-party Apache module? That module would need to be using pthread_atfork() to make sure ownership is preserved properly. Apache/APR certainly doesn't do it with its mutexes. I think there needs to be a mod_fork which provides a more general purpose daemon than that used by mod_cgid, and some Apache API will know whether or not to send a request over there. This preserves the goal of having fork() called only by single-threaded processes so that all manner of pain is avoided.
Re: Apache1 and own ErrorLog-Handler?
On Fri, 8 Oct 2004 11:30:46 +0200, Timo Eckert [EMAIL PROTECTED] wrote: Hello, is it possible on Apache1 to pipe the Error-Logs to an own handler? no; unlike Apache 2, Apache 1.3 has no such capability
Re: Apache1 and own ErrorLog-Handler?
On Fri, 8 Oct 2004 12:07:45 +0200, Timo Eckert [EMAIL PROTECTED] wrote: On Fri, 8 Oct 2004 05:46:29 -0400 Jeff Trawick [EMAIL PROTECTED] wrote: is it possible on Apache1 to pipe the Error-Logs to an own handler? no; unlike Apache 2, Apache 1.3 has no such capability Ok, where have i to search in the source, that ErrorLog-Filenames will be parsed through strftime(); ? the log record is actually written somewhere in src/main/http_log.c; the function is called log_error_core() that code would need to be modified if you wanted to add a new type of action to take with the final log message
Re: Bug: Apache hangs if script invokes fork/waitpid
On Thu, 07 Oct 2004 12:53:47 -0700, Paul Querna [EMAIL PROTECTED] wrote: Jeff Trawick wrote: I think there needs to be a mod_fork which provides a more general purpose daemon than that used by mod_cgid, and some Apache API will know whether or not to send a request over there. This preserves the goal of having fork() called only by single-threaded processes so that all manner of pain is avoided. Big +1 from me in concept. I am not sure how to do the implementation best. mod_cgid doesn't really 'fork' in the sense most programs do, its mostly just starting up a cgi process -- from an executable on the file system. This seems drastically different from the requirements of a generic fork(). Any thoughts on how you would want to implement this in a generic manner for any call from anywhere for any module? it has to be extremely restricted; the obvious capability is to allow apr_proc_create() to be called, with pipes set up properly back to code running in the Apache thread; another possible service is to allow a new child to be created and then in that process call some specified function which was copied into the mod_fork daemon process at apache startup; maybe that code happens to be some part of mod_perl which can implement suitable services on behalf of a perl script I suspect that whatever restrictions on applications are necessary to implement such a service are the same restrictions which must be respected anyway in order to have an application which works reliably+portably in a threaded MPM.
Re: cvs commit: httpd-2.0/server protocol.c
On 25 Oct 2004 06:40:08 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Index: protocol.c
===
RCS file: /home/cvs/httpd-2.0/server/protocol.c,v
retrieving revision 1.155
retrieving revision 1.156
diff -u -r1.155 -r1.156
--- protocol.c23 Oct 2004 22:39:53 - 1.155
+++ protocol.c25 Oct 2004 06:40:08 - 1.156
@@ -603,7 +603,10 @@
r-proto_num = HTTP_VERSION(1,0);
r-protocol = apr_pstrdup(r-pool, HTTP/1.0);
}
-
+else if (r-connection-keepalive != AP_CONN_KEEPALIVE) {
+ap_log_rerror(APLOG_MARK, APLOG_NOTICE, rv, r,
+ request line read error.);
+}
1.3 issues such a message only if it is a timeout error. 1.3 uses
LOGLEVEL_INFO. With LOGLEVEL_NOTICE there is no way to keep this out
of the error log.
Some users have relatively large numbers of connection-oriented
problems (I see this most often with users in SE Asia). Something
like this will result in a lot of messages for the types of conditions
they encounter on a regular basis.
Checking specifically for a timeout error (like 1.3*) and using
LOGLEVEL_INFO seems appropriate.
*In 1.3, it is the timeout handling which issues the message; I don't
see any similar messages in 1.3 mainline.
Re: cvs commit: httpd-2.0/server protocol.c
On Tue, 26 Oct 2004 14:51:59 +0100, Ivan Ristic [EMAIL PROTECTED] wrote: Sure, you may need to have some logic to determine what makes an attack and what not, but you must have the log entry to begin with so you feed it to the algorithm. Something I'm still curious about: Was the logging with Apache 1.3 not sufficient (logging only for the timeout error)? It still seems that Apache 2 is going to be logging more than Apache 1.3, which is something that deserves a bit of scrutiny.
[PATCH] ap_log_cerror()
I'm gonna puke if I see another connection-oriented error message with no client IP. Am I missing something basic, or is there really no reason NOT to have ap_log_cerror()? It seems so obvious. before: [Fri Oct 29 06:56:16 2004] [info] (32)Broken pipe: core_output_filter: writing data to the network after: [Fri Oct 29 06:56:54 2004] [info] [client 192.168.1.128] (32)Broken pipe: core_output_filter: writing data to the network There are probably a number of other places where this can be applied, and of course I need to add doc to http_log.h, but this is my sanity check that somebody here knows something that google doesn't. patch Description: Binary data
