Re: [PATCH] log path to config file during startup
On 10/16/06, Eric Covener [EMAIL PROTECTED] wrote: Patch below logs the path to the config file just before ap_mpm_run() Can help clear up some mysteries when posthumously analyzing an ErrorLog as a further aid, is it practical to add a list of defines used to parse the conf file? [notice] Using config file conf/foo.conf with -DHIGHPERF, -DPORTAL_REWRITES [notice] Using config file conf/foo.conf
vote on concept of ServerTokens Off
A lot of opinions were offered back in August. Some were negative but I don't see anything that looks like a veto. (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/[EMAIL PROTECTED]) A concern with the logging of server version has since been resolved, but implementation of the original feature died. Before Sebastian Nohn's patch is revised to fit in with the subsequent changes, I'd like to confirm that nobody has a strong (veto) objection to the feature, and that those in favor clearly out number those against. +1 from me
Re: vote on concept of ServerTokens Off
On 12/5/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jeff Trawick wrote: A lot of opinions were offered back in August. Some were negative but I don't see anything that looks like a veto. (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/[EMAIL PROTECTED]) A concern with the logging of server version has since been resolved, but implementation of the original feature died. Before Sebastian Nohn's patch is revised to fit in with the subsequent changes, I'd like to confirm that nobody has a strong (veto) objection to the feature, and that those in favor clearly out number those against. I recall the entire thread and two different implementations on trunk and branches/2.2 - and I'm entirely -0 on the feature, but am only -1 if it masks the information in the internal error.log. As I recall your patches split the API so that the MPM will log the 'true version' and that the patch will only affect the externally reported version. If my memory serves - then yes, let's proceed. yes, a new patch will only affect the externally reported version
Re: vote on concept of ServerTokens Off
On 12/5/06, Ruediger Pluem [EMAIL PROTECTED] wrote: On 12/05/2006 07:16 PM, Jim Jagielski wrote: On Dec 5, 2006, at 7:23 AM, Joe Orton wrote: On Tue, Dec 05, 2006 at 06:39:30AM -0500, Jeff Trawick wrote: A lot of opinions were offered back in August. Some were negative but I don't see anything that looks like a veto. (http://mail-archives.apache.org/mod_mbox/httpd-dev/200608.mbox/% [EMAIL PROTECTED]) A concern with the logging of server version has since been resolved, but implementation of the original feature died. Before Sebastian Nohn's patch is revised to fit in with the subsequent changes, I'd like to confirm that nobody has a strong (veto) objection to the feature, and that those in favor clearly out number those against. +1. Should be documented as a bad idea as Joshua notes in that thread. +1 (with that condition) +1 provided the condition above is true. What is the latest patch that should be applied? I'm pretty darn sure there is no latest ServerTokens Off patch to apply, because it needs to be reworked slightly to work with the patch/commit you refer to below. I just did a quick review of http://issues.apache.org/bugzilla/attachment.cgi?id=18775 and I think we should use the long version (aka ap_get_server_description()) in the output of mod_status and mod_info instead the possibly turned off version ap_get_server_description() better to review this commit: http://svn.apache.org/viewvc?view=revrevision=440337 or for 2.2.x http://svn.apache.org/viewvc?view=revrevision=446606 which does what you want. Maybe I was confused earlier ;) Reviewed by: rpluem, jim Thanks...
Re: vote on concept of ServerTokens Off
On 12/6/06, Jim Jagielski [EMAIL PROTECTED] wrote: Jorge Schrauwen wrote: On 12/6/06, Jim Jagielski [EMAIL PROTECTED] wrote: Joe Orton wrote: The motivation given by the submitter was that he pays per byte served, it seems entirely reasonable to allow the Server header to be disabled for such users. Can he install mod_security? Yes, mod_security evens allows you to change it I know... that's why I asked :) We're up to two great answers to disable some output from the server that isn't required by the HTTP protocol anyway: 1) modify the source 2) install third-party module
Re: vote on concept of ServerTokens Off
On 12/6/06, Lars Eilebrecht [EMAIL PROTECTED] wrote: According to Jeff: A lot of opinions were offered back in August. Some were negative but I don't see anything that looks like a veto. I voted -1 at that time which is a veto. oops, I didn't read all your messages --veto--- I fear that many users of Apache would actually turn off the Server header for no or for the wrong reasons (which may harm our market share), and therefore I'm -1 on including this patch. --veto--- That sounds like the web server with ego argument. Is this going to make much more difference than netcraft catching Apache hosting parked domain names one month and IIS the next? My opinion hasn't changed and I still think that it is a very stupid idea to add a feature that allows our users to do something which is stupid and absurd. *shrug* but as everyone seems to think that this is a good idea, feel free to ignore my veto. Retract the veto, or not.
Re: vote on concept of ServerTokens Off
On 12/6/06, Justin Erenkrantz [EMAIL PROTECTED] wrote: On 12/6/06, Jeff Trawick [EMAIL PROTECTED] wrote: We're up to two great answers to disable some output from the server that isn't required by the HTTP protocol anyway: 1) modify the source 2) install third-party module So, uh, why do we need to make it even easier for them? -- justin Neither of those is easy in some environments. Why other than ego do we want to make it hard to disable this output?
Re: vote on concept of ServerTokens Off
On 12/5/06, Jeff Trawick [EMAIL PROTECTED] wrote: A lot of opinions were offered back in August. Some were negative but I don't see anything that looks like a veto. Why do I care personally? I'd like to see an easy resolution to the common support question which doesn't involve recompiling the server*, installing third-party modules+, trying to explain that the server implementation can be easily reverse engineered anyway@, or trying to explain that attackers just send everything they have regardless of which server implementation they think it [EMAIL PROTECTED] *alas, not possible with my day job but I can solve that in a different way +not a simple task in many corporate environments @generally this seems to fall on deaf ears; I suspect that many of these people have to document exceptions to the report of some scanner every n months
Re: vote on concept of ServerTokens Off
On 12/6/06, Colm MacCarthaigh [EMAIL PROTECTED] wrote: On Wed, Dec 06, 2006 at 01:43:49PM -0500, Jeff Trawick wrote: * The Apache HTTP Server project believes that most people who want to avoid sending the Server header mistakenly think that doing so may protect their server from attacks based on known flaws in older Apache HTTPD releases, when in fact the only reasonable way to address these flaws is to upgrade to new Apache HTTPD releases which correct security problems affecting your configuration. By restricting the ability to configure Apache in this manner, we wish to raise awareness of the need to upgrade when critical vulnerabilities are addressed. (what other reasons go here?) I think the more important thing about the security reason, is that it actually *degrades* security, because it impedes the ability to audit. Finding out-of-date installations is an nmap one-liner if you leave the Server header alone. If you disable it, you have to start logging in to the boxes (and getting that access and so on) and check things locally. The admin who would want to code ServerTokens Off is already coding ServerTokens Prod, so that is an argument to stop doing what you've been able to do since 1.3.14.
Re: vote on concept of ServerTokens Off
On 12/6/06, Henrik Nordstrom [EMAIL PROTECTED] wrote: ons 2006-12-06 klockan 09:38 -0500 skrev Jeff Trawick: Why other than ego do we want to make it hard to disable this output? Technical reason: Not advertising the brand and version makes it very hard for clients (user-agents and proxies) to apply workarounds when needed. As an example Squid currently has a workaround for how Apache handles ETag in responses which has been modified by mod_deflate. In future we hope to be able to disable that for versions known to be fixed. http://issues.apache.org/bugzilla/show_bug.cgi?id=39727 Not sending the sever name and version will make this harder. Since this capability of working around issues in certain levels of Apache requires both the server name and version to be advertised, that is an argument against something you've been able to do since Apache 1.3.14 (hide the version). Colm had another argument in that category. So we could list some reasons to avoid using the existing capability to hide the server version: * make it easy to audit your web server installations for out of date versions * allow other software, such as proxy servers, to work around problems in your level of Apache
Re: Issue using piped logging
On 12/14/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am upgrading from Apache 2.0.53 to Apache 2.2.3 but recently I am facing some issues with piped logging in Apache 2.2 .Please let me know if anyone of you had also faced it. I used following in my httpd.conf for error logging ErrorLog |/bin/sh -c 'RUNTIME=/myruntime LD_LIBRARY_PATH=/myruntime/lib /myruntime/bin/mylogger -k file -d /myruntime/logs -f error_log' but this not working and httpd do not starts there are no logs about what happened , no idea here, but comparison of truss/strace/whatever between your 2.0.53 and 2.2.3 setups should yield some clues
Re: Piped logger nightmares
On 1/5/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: http://svn.apache.org/viewvc?view=revsortby=daterevision=104019 Sanity check... 1.3 used /bin/sh in-between httpd and the piped logger. 4513 execve(/bin/sh, [/bin/sh, -c, /scratch/inst/13/bin/rotatelogs ...], [/* 36 vars */] unfinished ... Why haven't these problems been seen there? Is the problem really triggered by some minor detail in the 2.x implementation which differs from 1.3, and not simply by letting the shell assist with the startup? The reason given; some examples use the shell... wasn't enough to make this the default behavior against all installations, IMHO. That plus the fact that 1.3 had the same behavior (at least at the high level; maybe some smaller detail is wrong) with nobody complaining... Perhaps in pre APR days the 1.3 implementation on Windows differed more greatly from Unix (e.g., shell wasn't even used on Windows)? Or perhaps it was busted on Windows there too but nobody cared? I'd suggest an alternate syntax; use |$ where a shell command is really actually demanded. So... That works for me, though it is an unexpected migration. Possible mitigation of the migration issue: * the '$' should be required in 2.0/2.2 on platform(s) where we know the shell causes actual problems, and starting with 2.4 it should be required everywhere * shell used automatically with 2.0/2.2 if it is obvious that the shell is needed (no path to the piped logger program, or shell redirection used) -/- Can you confirm that 1.3 was busted on Windows too?
Re: [VOTE] httpd-2.2.4 release candidate for review
On 1/6/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: [+1] Release httpd 2.2.4 tested with worker MPM on RedHat 4/ia32 and Solaris 10/SPARC32
Re: Piped logger nightmares
On 1/8/07, Sander Temme [EMAIL PROTECTED] wrote: On Jan 8, 2007, at 5:06 PM, Sander Temme wrote: Can you confirm that 1.3 was busted on Windows too? Starting 1.3.37 from the shell (not as a Service): I'm starting to engage myself in quite the conversation. Started 2.2.3 from the command line. It does the same thing as the service: two cmd.exe + rotatelogs.exe from the parent, two from the child. However, it also opens two empty cmd.exe *windows*. Killing he server by ^C in the cmd.exe that started it gives me two orphaned rotatelogs.exe processes, left behind by the child. This 1.3 code #elif defined(WIN32) shellcmd = getenv(COMSPEC); if (!shellcmd) shellcmd = SHELL_PATH; child_pid = spawnl(_P_NOWAIT, shellcmd, shellcmd, /c, (char *)cmd, NULL); return(child_pid); #elif defined(OS2) has been replaced with a lot of other code. Does anybody know how to tell which flags spawnl() passes to CreateProcess[W] when 1.3 starts its piped loggers (something like truss/strace I guess)?
Re: process the request
On 1/9/07, 张 臻博 [EMAIL PROTECTED] wrote: hello I am reading the code of apache. Is there anybody who knows whether ap_run_pre_connection() and ap_run_process_connection() are functions or macro? and where is the definition for those two , as i can not find any detailed code for them? macros The chase begins with http_connection.h: /** * This hook gives protocol modules an opportunity to set everything up * before calling the protocol handler. All pre-connection hooks are * run until one returns something other than ok or decline * @param c The connection on which the request has been received. * @param csd The mechanism on which this connection is to be read. *Most times this will be a socket, but it is up to the module *that accepts the request to determine the exact type. * @return OK or DECLINED */ AP_DECLARE_HOOK(int,pre_connection,(conn_rec *c, void *csd)) /** * This hook implements different protocols. After a connection has been * established, the protocol module must read and serve the request. This * function does that for each protocol module. The first protocol module * to handle the request is the last module run. * @param c The connection on which the request has been received. * @return OK or DECLINED */ AP_DECLARE_HOOK(int,process_connection,(conn_rec *c)) What do you want to find out? The actual implementation isn't so interesting. If you want to see how to implement your own connection hook, see how the process_connection string is used in Apache in a few macro invocations.
Re: Where is ap_run_default_port()?
On 1/15/07, Brandon Fosdick [EMAIL PROTECTED] wrote: I'm trying to use ap_default_port() in mod_log_dbd to get the port number from a request_rec, and apparently it's a macro in httpd.h that wraps ap_run_default_port(). But when I compile the module I get error: `ap_run_default_port' was not declared in this scope. mod_log_config.c seems to use it just fine, so I grep'd to see where it is... Are you including http_protocol.h to get the definition of ap_run_default_port()? svn/2.2.x/include/http_protocol.h:AP_DECLARE_HOOK(apr_port_t,default_port,(const request_rec *r))
Re: 2007 DST changes, and a non-issue statement...
On 1/25/07, Jim Jagielski [EMAIL PROTECTED] wrote: We did it with Y2K so +1... Is there anything to say other than (for httpd, for example): Apache httpd and bundled libraries do not maintain their own time zone information. Instead, information is retrieved from the operating system. Relevant operating system updates must be applied and the web server restarted to prevent potential time display problems with logging and server-generated reports. Web applications and third-party modules and libraries used with the web server must be investigated separately.
Re: 2007 DST changes, and a non-issue statement...
On 1/26/07, Nick Kew [EMAIL PROTECTED] wrote: Apache httpd and bundled libraries do not maintain their own time zone information. Instead, information is retrieved from the operating system. Relevant operating system updates must be applied and the web server restarted to prevent potential time display problems with logging and server-generated reports. Web applications and third-party modules and libraries used with the web server must be investigated separately. How about replacing must with may have to be? We're not in the business of saying someone else is guilty, only that we're innocent. Either way works for me. Is it a quick task for somebody on this thread to post it on the news page? Its definitely news right now, but we might want to put it in the FAQ for long-term, as surely this will come up again.
Re: [PATCH] exception hook for SIGFPE
On 1/26/07, Eric Covener [EMAIL PROTECTED] wrote: Single Unix Specification and sniff test* of a few operating systems says SIGFPE (floating point exception) results in a core, but we don't install the sig_coredump handler for this signal along with SIGSEGV, SIGILL, SIGBUS, etc. http://www.ibiblio.org/wm/paint/auth/munch/munch.scream.jpg test/commit is on my todo list for the weekend (
Re: 3.0 - Proposed Requirements
On 2/14/07, Paul Querna [EMAIL PROTECTED] wrote: This proposed list of requirements for a 3.0 platform. this list enables a 'base' level of performance and design decisions to be made. If others can make designs work with 'lessor' requirements, all the better, but I'm not worried about it. I'm not sure what that means. Other than perhaps the C99 stuff, I think we all take it for granted that the design should take proper advantage of the other features when available. So the topic for discussion is an absolute set of requirements, with the implementation not complicated by logic to support a lower set of system requirements. Either we design it to require fancy features to work at all or we don't. Proposed Requirements: - C99 Compiler. shrug (for some reason it seems more natural to me to follow APR on what language level is required) - High Performance Event System Calls (KQueue, Event Ports, EPoll, I/O Completion Ports). - Async Socket and Disk IO available. (POSIX AIO?) Designing the server so that it can take advantage of these when available but work fine without them is of tremendous value, not only for supporting older or different platforms but also for providing a simplified debugging/development environment for logic not directly tied to these features. I don't think we should force every module author to have to be aware of these aspects of the design (though they may have to require the use of a simpler MPM). And we don't want to keep 2.x healthy forever or chase people to other web servers. - Good Kernel Threading. Dealing with threads/no-threads definitely introduces clutter. Some new Apache helper functions that are no-ops when !APR_HAS_THREADS or the MPM has a single threaded process serving requests could clean up a lot of the code that cares about this, perhaps at a very slight performance cost for the non-threaded builds.
Re: svn commit: r507956 - /httpd/httpd/branches/2.2.x/STATUS
On 2/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jim Date: Thu Feb 15 07:14:25 2007 New Revision: 507956 URL: http://svn.apache.org/viewvc?view=revrev=507956 Log: Actually, I think this should be a show-stopper, since the current behavior is broke broke broke. I wouldn't call this a showstopper since it has worked that way for a while and does not represent a regression since the previous release. otoh, I could go for this heading ;) WE'RE PATHETIC IF WE SHIP ANOTHER RELEASE WITHOUT THESE APPROVED:
Re: util_ldap.c use of hardcoded sizelimit on ldap_search_ext_s causing error
On 2/15/07, David Jones [EMAIL PROTECTED] wrote: Currently util_ldap.c has a hard coded -1 as the search limit value (meaning infinite/no limit) on ldap_search_ext_s() calls. Some platforms cannot handle the -1, but need a 0. Linux, zoS (and others) have a LDAP_NO_LIMIT value in ldap.h. Below is a patch, allows those who have LDAP_NO_LIMIT value to take advantage of it, and others to continue using a -1 value. patch committed to trunk and proposed for backport 2.2.x my guess is that -1 is rarely/never the proper value, but that isn't so easy to confirm; hopefully the symbol is always available in modern SDK levels
Re: svn commit: r509629 - /httpd/httpd/branches/2.2.x/STATUS
On 2/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: bnicholes Date: Tue Feb 20 08:23:19 2007 New Revision: 509629 URL: http://svn.apache.org/viewvc?view=revrev=509629 Log: vote Modified: httpd/httpd/branches/2.2.x/STATUS Modified: httpd/httpd/branches/2.2.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?view=diffrev=509629r1=509628r2=509629 == --- httpd/httpd/branches/2.2.x/STATUS (original) +++ httpd/httpd/branches/2.2.x/STATUS Tue Feb 20 08:23:19 2007 @@ -180,3 +180,9 @@ * mod_ldap: Fix the search limit parameter to ldap_search_ext_s() http://svn.apache.org/viewvc?view=revrev=509237 +1: trawick + -0: bnicholes - The patch as it stands, could cause unpredictible + behavior across SDKs depending on whether or not the SDK + has defined LDAP_NO_LIMIT. The behavior of the ldap_search_ext_s() + call can be different if the sizelimit parameter is 0 vs -1. + At the very least, the patch needs to be revised so that the + behavior is common across all SDKs. Is this correct as far as you know? . 0 always means no client API limit . LDAP_NO_LIMIT, when defined, means no client API limit . when accepted as a parameter, -1 sometimes means some default (client API default?) and sometimes means unlimited (VERY UNCLEAR TO ME) . the search is always limited by the server limit, no matter what is specified in the client
Re: svn commit: r512848 - /httpd/httpd/trunk/VERSIONING
On 2/28/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: chrisd Date: Wed Feb 28 09:12:06 2007 New Revision: 512848 URL: http://svn.apache.org/viewvc?view=revrev=512848 Log: fix a minor typo Modified: httpd/httpd/trunk/VERSIONING Modified: httpd/httpd/trunk/VERSIONING URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/VERSIONING?view=diffrev=512848r1=512847r2=512848 == --- httpd/httpd/trunk/VERSIONING (original) +++ httpd/httpd/trunk/VERSIONING Wed Feb 28 09:12:06 2007 @@ -68,7 +68,7 @@ stable release due to API change requirements. * The stable subversion tree should not remain unstable at any time. Atomic -commits aught be used to introduce code from the development version to the +commits ought be used to introduce code from the development version to the that's how we remember who wrote that text ;)
Re: Module Crashes if build as a shared object
On 2/28/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all One of my apache module crashes if it is used as shared module but works fine if it is build as static module. Watch out for static variable usage in your module. That's a common cause of this type of problem. Static variables don't retain their values between the multiple calls to the post-config hook when your module is built as a DSO. Also it was working fine as shared module before I upgraded to kernel 2.6 and glibc 2.3.4. shrug Following is the back trace (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7d43bbb in pthread_setspecific () from /lib/libpthread.so.0 #2 0x080c92de in child_main (child_num_arg=0) at worker.c:1258 child_main doesn't call pthread_setspecific(), so some info is missing or just incorrect. I'd recommend stepping through your module's initialization hooks and looking for unexpected behavior.
Re: Small patch to ab apr_socket_recv error handling
On 3/2/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
is the patch below looking good?
does it need adjustments?
do I need to follow a different process?
Filip
Filip Hanik - Dev Lists wrote:
ok, final patch, this one also adds in Content-Length: 0 when keep
alive is used.
somehow, most containers will not do keep alive unless there is a
content length header.
That sounds very odd. Regardless, the important point for now is that
we don't want to combine two unrelated changes in one patch/commit.
The point of the patch on this discussion thread is to recover from
socket receive errors, so the patch under review/revision shouldn't
try to accomplish anything else.
Index: ab.c
===
--- ab.c (revision 511976)
+++ ab.c (working copy)
@@ -258,6 +258,7 @@
/* - GLOBALS */
int verbosity = 0; /* no verbosity by default */
+int recverrok = 0;
int posting = 0;/* GET by default */
int requests = 1; /* Number of requests to make */
int heartbeatres = 100; /* How often do we say we're alive */
@@ -1330,9 +1331,19 @@
/* catch legitimate fatal apr_socket_recv errors */
else if (status != APR_SUCCESS) {
err_except++; /* XXX: is this the right error counter? */
-/* XXX: Should errors here be fatal, or should we allow a
- * certain number of them before completely failing? -aaron */
-apr_err(apr_socket_recv, status);
+if ( recverrok ) {
no spaces around recverrok; should be
if (recverrok) {
+bad++;
+close_connection(c);
+if ( verbosity = 1 ) {
+char buf[120];
+fprintf(stderr,%s: %s (%d)\n,apr_socket_recv,
apr_strerror(status, buf, sizeof buf), status);
+}
+return;
+} else {
+/* XXX: Should errors here be fatal, or should we allow a
+ * certain number of them before completely failing? -aaron
*/
IMO that comment can die now because of this patch.
+apr_err(apr_socket_recv, status);
It would be nice to slip in a message such as Use the -r option to
continue after socket receive errors. but I don't see a trivial way
to add that in the natural message order (first the description of
what wrong, next the hint about how to take a different action when
that occurs). Punt for now unless you can think of a way to implement
that without butchering existing subroutines.
+}
}
}
@@ -1559,7 +1570,7 @@
(posting == 0) ? GET : HEAD,
(isproxy) ? fullurl : path,
AP_AB_BASEREVISION,
-keepalive ? Connection: Keep-Alive\r\n : ,
+keepalive ? Connection: Keep-Alive\r\nContent-Length: 0\r\n :
,
zap this part of the patch for now; start a discussion on that
separate issue after this patch is finished/committed
cookie, auth, host_field, colonhost, hdrs);
}
else {
@@ -1819,6 +1830,7 @@
fprintf(stderr, -S Do not show confidence estimators and
warnings.\n);
fprintf(stderr, -g filename Output collected data to gnuplot format
file.\n);
fprintf(stderr, -e filename Output CSV file with percentages
served\n);
+fprintf(stderr, -r Don't exit on apr_socket_recv
errors.\n);
IMO the usage statement should refer to socket receive errors, not
the name of a library function
fprintf(stderr, -h Display usage information (this
message)\n);
#ifdef USE_SSL
fprintf(stderr, -Z ciphersuite Specify SSL/TLS cipher suite (See
openssl ciphers)\n);
@@ -1981,7 +1993,7 @@
#endif
apr_getopt_init(opt, cntxt, argc, argv);
-while ((status = apr_getopt(opt,
n:c:t:b:T:p:v:kVhwix:y:z:C:H:P:A:g:X:de:Sq
+while ((status = apr_getopt(opt,
n:c:t:b:T:p:v:rkVhwix:y:z:C:H:P:A:g:X:de:Sq
#ifdef USE_SSL
Z:f:
#endif
@@ -2032,6 +2044,9 @@
exit(r);
}
break;
+case 'r':
+recverrok = 1;
+break;
case 'v':
verbosity = atoi(optarg);
break;
bad and err_except are incremented when a receive error occurs.
Previously, that wasn't so interesting since ab aborted immediately.
IMO it is worthwhile to have a separate counter.
if (bad)
printf( (Connect: %d, Receive: %d, Length: %d, Exceptions: %d)\n,
err_conn, err_recv, err_length, err_except);
Thanks!
Re: Small patch to ab apr_socket_recv error handling
On 3/7/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: ok, Jeff's feedback has been incorporated into this patch. Could you post the patch again as an attachment? Some whitespace oddity is making it hard to apply for me. Thanks!
Re: Small patch to ab apr_socket_recv error handling
On 3/8/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote: it is an attachment, chances are your mail reader is expanding it into your viewing window but you can also get it here http://www.hanik.com/fix-ab-recv-error.patch thanks; committed to trunk
Re: CGI app reports broken pipe error
On 3/14/07, Stas Oskin [EMAIL PROTECTED] wrote: Hi. I have a custom CGI application writing binary data to stdout. Recently, probably after some upgrade, I begin receiving write errors with the system error Broken pipe. that should mean that the web client disconnected, and your CGI shouldn't keep pumping out data Can someone advice how to debug this and find the issue? Also, are there any know recent changes (from this year beginning/last year end) which could have caused this? prefork MPM and strace -f
Re: PATCH: support utilities should enable crypt() , current htdbm checks broken
On 3/16/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Nope - it won't. Where does z/OS define the crypt() prototype? unistd.h is the common place, z/OS or not. http://www.opengroup.org/onlinepubs/007908799/xsh/crypt.html Apparently crypt_r() is often defined in crypt.h but not in unistd.h. The correct patch is to ask APR_HAS_CRYPT (which we need to provide by patching apr, if we don't already.) APR doesn't pretend to figure out for APR apps exactly what the system provides, though there is currently a spotty set of APR_HAS_foo. Meanwhile, httpd goes and searches on its own for things APR doesn't tell anyone about. I'm curious about other opinions on whether or not it is APR's job to tell what is available. (Sometimes I long for something like an apr-bootstrap component which owns the job of figuring out the characteristics of a system, and exports that information to all comers using its own namespace. APR or other apps/libraries then can use the information. So the very essence of this component is to make that type of information available, and the odd inconsistency of what APR exports or doesn't is no more.)
Re: PATCH: support utilities should enable crypt() , current htdbm checks broken
On 3/16/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Jeff Trawick wrote: APR doesn't pretend to figure out for APR apps exactly what the system provides, though there is currently a spotty set of APR_HAS_foo. Meanwhile, httpd goes and searches on its own for things APR doesn't tell anyone about. I'm curious about other opinions on whether or not it is APR's job to tell what is available. In httpd, we don't call crypt(), we call APR maybe this is the point of confusion... httpd does call crypt() $ grep crypt support/*c ... support/htdbm.c:apr_cpystrn(cpw, crypt(htdbm-userpass, salt), sizeof(cpw) - 1); ... support/htpasswd.c:apr_cpystrn(cpw, crypt(pw, salt), sizeof(cpw) - 1); ...
Re: [RFC] Guide to writing output filters
On 3/16/07, Joe Orton [EMAIL PROTECTED] wrote: http://people.apache.org/~jorton/output-filters.html I guess I'm confused about the up/down direction convention for output filters? I thought passing the next output filter is down and returning to the prior input filter is up? a few examples: Generally, all metadata buckets should be passed up the filter chain by an output filter. down the filter chain Filters can create FLUSH buckets and pass these up the filter chain if desired. down the filter chain An output filter should never pass an empty brigade up the filter chain. down the filter chain /* Pass brigade upstream. */ rv = ap_pass_brigade(f-next, tmpbb); /* Pass brigade downstream. */ minor grammatical tweaks: the number of times a filter is invoked for single response for a single response The PIPE bucket type is an example of a bucket type has an indeterminate length; a bucket type which has an indeterminate length Possible confusion: # Output filters which read all the buckets in a brigade must process a fixed number of buckets (or amount of data) at a time, to ensure that memory consumption is not proportional to the size of the content being filtered. This may be unclear, since you're not referring to buckets received on input to the filter but buckets returned by bucket-read (after morphing). Perhaps must process a fixed amount of data at a time is less subject to incorrect interpretation? How does this look? It looks like a great start to me. More detail about error handling would be invaluable. Something that has been a thorn in the past has been the two types of status and understanding the limited relationship: apr_status_t as returned by a filter HTTP status as returned by a handler What can a filter do to influence HTTP status (set r-status on first invocation for a response?)? What will be logged if a filter returns non-APR_SUCCESS?
Re: internal dummy connection again
On 3/16/07, Karl Chen [EMAIL PROTECTED] wrote: On 2007-03-05 13:24 PST, Joe Orton writes: Joe On Mon, Mar 05, 2007 at 09:33:56PM +0100, Ruediger Pluem wrote: On 03/03/2007 05:47 AM, Karl Chen wrote: present. Also other issues like noise in the log file. I've also seen people complaining that GET / might incur the cost of dynamic content generation for /. Hm. Just thinking loud. Can we avoid this if we replace GET / with OPTIONS /? Joe Doing OPTIONS * as Bill notes is probably the best Joe option available for the dummy connection, though it will Joe still be confusing for users (possible more confusing, Joe since that request rarely if ever seen in the wild). Thanks for the input everyone and pointers to the bugzilla issues. OPTIONS * is a definite improvement over GET / for performance. What about the NOOP idea? If the connection could be reliably detected to be coming from [EMAIL PROTECTED], would there still be a risk of an attack going unnoticed? What about having the MPM normally poll on a pipe in addition to listening sockets, and wake up the MPM with the pipe? How many of the folks with a single listening socket (i.e., avoiding the poll currently) would be harmed the extra syscall? Those who need/want to avoid the syscall can compile with a special flag and deal with the slight oddities caused by the dummy connection. Or, if we know there is no kernel accept filtering (this can only happen based on our configuration enabling it, right?), avoid sending the request at all. We only send a real request to get past a kernel filter.
Re: mod_cgid and accept() loop
On 3/17/07, Amol Dev [EMAIL PROTECTED] wrote:
After running the Apache-2.0.58 server on mod_cgid on HPUX B.11.23 PA for 3-4
days all of sudden I see the following errors in error_log.
[Fri Mar 16 07:23:53 2007] [error] (231)Software caused connection abort: Error
accepting on cgid socket
There were 18 millons such entries in 30 minutes which mean the cgid daemon was
under infinite loop.
len = sizeof(unix_addr);
sd2 = accept(sd, (struct sockaddr *)unix_addr, len);
if (sd2 0) {
if (errno != EINTR) {
ap_log_error(APLOG_MARK, APLOG_ERR, errno,
(server_rec *)data,
Error accepting on cgid socket);
}
continue;
}
Error '231' is ECONNABORTED, which is not handled by mod_cgid and puts the
accept() into infinite loop.
no, ECONNABORTED will generate a log message and go back into accept
and wait for a new connection; it takes an infinite number of such
connections (or kernel acting like there is) to create an infinite
loop there
perhaps the kernel is confused? some unknown glitch caused a
connection to be aborted once, and kernel has left it on an internal
queue even after accept() is called?
Not sure why would this socket be shutdown() by anything. But if it does get
ECONNABORTED how should mod_cgid handle it?
It handles it correctly today IMHO.
Without information on root cause of the kernel acting like there is
an endless number of aborted connections to the mod_cgid socket, I
wouldn't suggest any change to Apache.
Should we handle this error by setting daemon_should_exit++? Does that respawn
new daemon without interruption?
You may wish to make a local modification to have the cgid process
exit if, for example, 10 consecutive calls to accept() return
-1/ECONNABORTED.
You may first want to try to catch it happening again and use tusc to
see if child process(es) handling request are repeatedly trying to
connect to mod_cgid's socket. If they're not doing anything wrong,
see about applicable kernel patches.
If by chance you're using HP's Apache-based server and have support
for it, give them a call. If anybody has heard of this before they
would likely be in the know.
Re: mod_cgid and accept() loop
On 3/18/07, Amol Dev [EMAIL PROTECTED] wrote: Just have to make sure the daemon will be relaunched taking on requests without problem if that happens. Yes (not tested exactly like that however). Certainly the cgid daemon would be relaunched if it crashed.
Re: PATCH: support utilities should enable crypt() , current htdbm checks broken
On 3/20/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: httpd does not ;-) httpd the project (vs. apr, apr-util), not httpd the program (vs. htdbm, htpasswd) as in In httpd, we don't call crypt(), we call APR...
Re: svn commit: r518938 - /httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c
On 3/22/07, Jean-Frederic [EMAIL PROTECTED] wrote: I have ported it to httpd-2.2.x should I commit it? propose in 2.2.x/STATUS; await approval
Re: PATCH: support utilities should enable crypt() , current htdbm checks broken
On 3/23/07, David Jones [EMAIL PROTECTED] wrote: ok here's the simple patch at the 2.0.x level that just checks platforms for htdbm.c Can you post a post to htdbm.c at trunk?
Re: PATCH: support utilities should enable crypt() , current htdbm checks broken
On 4/4/07, Jeff Trawick [EMAIL PROTECTED] wrote: On 3/23/07, David Jones [EMAIL PROTECTED] wrote: ok here's the simple patch at the 2.0.x level that just checks platforms for htdbm.c Can you post a post to htdbm.c at trunk? whoops, make that Can you post a PATCH...
Re: ProxyErrorOverride and redirects (PR 39245)
On 4/5/07, Nick Kew [EMAIL PROTECTED] wrote: On Thu, 5 Apr 2007 10:04:19 +0100 Joe Orton [EMAIL PROTECTED] wrote: I agree that the intended behaviour of the original code was intuitively correct, only = 400 errors should be overriden, A redirection page is likely to include a redirected URL. In a reverse proxy situation, that may need to be rewritten. Use of ProxyErrorOverride could be a valid alternative to mod_proxy_html in that situation, couldn't it? Looks to me like a valid usage case for ProxyErrorOverride 3xx. We have a couple of people trying to make their actual problem go away permanently by keeping up with this thread and trying to match developer comments with patches. IMO we should go ahead and fix what is broken now, and let requirements for the new feature (ProxyErrorOverride nxx) present themselves in the fullness of time. If somebody is relying on the current feature-by-defect, then we'll find out soon enough. If there is never a compelling requirement, then we're left with the simpler code (which is already hard enough to keep working ;) ).
Re: PATCH: support utilities should enable crypt() , current htdbm checks broken
On 4/9/07, David Jones [EMAIL PROTECTED] wrote: patch for trunk: thanks; committed I'll propose for backport to 2.2.x shortly.
Re: ProxyErrorOverride and redirects (PR 39245)
On 4/9/07, Nick Kew [EMAIL PROTECTED] wrote:
On Mon, 9 Apr 2007 11:08:55 -0400
Jeff Trawick [EMAIL PROTECTED] wrote:
On 4/5/07, Nick Kew [EMAIL PROTECTED] wrote:
On Thu, 5 Apr 2007 10:04:19 +0100
Joe Orton [EMAIL PROTECTED] wrote:
I agree that the intended behaviour of the original code was
intuitively correct, only = 400 errors should be overriden,
A redirection page is likely to include a redirected URL.
In a reverse proxy situation, that may need to be rewritten.
Use of ProxyErrorOverride could be a valid alternative to
mod_proxy_html in that situation, couldn't it?
Looks to me like a valid usage case for ProxyErrorOverride 3xx.
We have a couple of people trying to make their actual problem go away
permanently by keeping up with this thread and trying to match
developer comments with patches.
Yep.
IMO we should go ahead and fix what is broken now, and let
requirements for the new feature (ProxyErrorOverride nxx) present
themselves in the fullness of time. If somebody is relying on the
current feature-by-defect, then we'll find out soon enough. If there
is never a compelling requirement, then we're left with the simpler
code (which is already hard enough to keep working ;) ).
Fine by me. I was ready to commit a give-the-users-the-choice patch,
then someone objected to it. If you want to commit the no-choice
patch instead, that's OK.
Either way, it'll want an accompanying documentation patch before it
goes into a release.
I wonder why Error in ProxyErrorOverride doesn't match the meaning
of ap_is_HTTP_ERROR(), as in the attached patch (with doc).
1xx isn't something the user should see/react to either.
Index: modules/proxy/mod_proxy_http.c
===
--- modules/proxy/mod_proxy_http.c (revision 527940)
+++ modules/proxy/mod_proxy_http.c (working copy)
@@ -1448,7 +1448,7 @@
* if we are overriding the errors, we can't put the content
* of the page into the brigade
*/
-if (!conf-error_override || ap_is_HTTP_SUCCESS(r-status)) {
+if (!conf-error_override || !ap_is_HTTP_ERROR(r-status)) {
/* read the body, pass it to the output filters */
apr_read_type_e mode = APR_NONBLOCK_READ;
int finish = FALSE;
@@ -1557,7 +1557,7 @@
if (conf-error_override) {
/* the code above this checks for 'OK' which is what the hook expects
*/
-if (ap_is_HTTP_SUCCESS(r-status))
+if (!ap_is_HTTP_ERROR(r-status))
return OK;
else {
/* clear r-status for override error, otherwise ErrorDocument
Index: docs/manual/mod/mod_proxy.xml
===
--- docs/manual/mod/mod_proxy.xml (revision 527940)
+++ docs/manual/mod/mod_proxy.xml (working copy)
@@ -1196,6 +1196,9 @@
the error code and act accordingly (default behavior would display
the error page of the proxied server, turning this on shows the SSI
Error message)./p
+
+pThis directive does not affect the processing of informational (1xx),
+normal success (2xx), or redirect (3xx) responses./p
/usage
/directivesynopsis
Re: svn commit: r527969 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy.xml modules/proxy/mod_proxy_http.c
On 4/12/07, Ruediger Pluem [EMAIL PROTECTED] wrote: On 04/12/2007 05:07 PM, [EMAIL PROTECTED] wrote: Author: trawick Date: Thu Apr 12 08:07:11 2007 New Revision: 527969 URL: http://svn.apache.org/viewvc?view=revrev=527969 Log: HTTP proxy ProxyErrorOverride: Leave 1xx and 3xx responses alone. Only processing of error responses (4xx, 5xx) will be altered. PR: 39245 This is based on a patch submitted by Bart van der Schans schans hippo.nl and tweaked slightly by me based on discussions on dev@ since April 2006. I think rpleum was the first to mention the 1xx issue. Thanks for fixing this. Just as a side note: ProxyErrorOverride does not work with ajp workers. It seems that it never has. I think this should be fixed sometime in the future. I saw that in the dev@ discussion and put HTTP proxy in the CHANGES entry, but I don't know if the ajp issue is something to document (impractical to fix) or something easily resolved with some code. Thanks, Jeff
Re: RFE -- external overload procedure
On 4/20/07, Juerg Umhang [EMAIL PROTECTED] wrote: hello please consider this posting as a request for enhancement httpd knows about his overload situation. [error] server reached MaxClients setting, consider raising the MaxClients setting this overload is easily created by an external attacker. in case of an attack you have to react. best done on a lower osi-layer (iptables, pf, ...). realtime log analysis has his own odds and twists. we would prefer a call to an 'external helper procedure'. in this context we have some questions: -- do you think it makes sense to implement this feature ? -- could it be done in a module (without the overhead of going through the scoreboard for each pre_connection call) ? It is reasonable to me for httpd to provide a module interface (hook) so that a third-party module can take action when httpd reaches the MaxClients (Unix) or ThreadsPerChild (Windows) condition. (Maybe the hook just provides some basic statistics, and the module can determine whether the absolute limit has been reached or its own configurable threshhold has been reached.) A way that a module can do something reasonable without modifying the server is to create a separate child process that monitors the scoreboard at its own interval, and takes whatever action is appropriate. That check can be infrequent enough that the performance overhead is negligible. -- can we expect this enhancement in a future release ? Some other committer can speak for themselves, but I wouldn't expect it without a patch submitted. btw: we hope to see separately configurable timeouts ( http://httpd.apache.org/docs/2.2/mod/core.html#timeout ) very soon. I don't recall anyone here interested in fulfilling the goal expressed in that comment.
Re: Apache 2.0.58 on i5/OS question
On 5/3/07, Henri Gomez [EMAIL PROTECTED] wrote: While working on porting latest mod_jk on i5/OS V5R4, I see on this platform a different behaviour than on stock Apache 2.0.x implementations. One way to look at it: You're working with an IBM product based on Apache, not Apache itself. Nobody here actually knows how some of the behaviors have been modified for that platform. Furthermore, the product Infocenter (documentation) apparently does not describe such differences, though it does make some reference to Apache and APR APIs. The way to resolve this is to open a PMR with IBM support to report that the product documentation is incomplete and that clarification of the behaviors in question is required to enable some third-party modules with the web server product. That should drive an update to the Infocenter as well as educate the developers that this type of information is required by some customers.
Re: [vote] Piped loggers and APR_SHELLCMD_ENV
On 5/23/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: While I'm working on a solution to permit cmd.exe to be launched from a service process within Win32, I'm still struck by the inefficiency here and feel we need to resolve the core issue. Regarding the inefficiency, it doesn't seem to be a big deal. It takes a trivial amount longer to start up the piped logger, and a process hangs around consuming a trivial amount of resources. I think it is more an issue of neatness -- does somebody want to see that process hanging around. Apparently it is a good APR testcase as well ;) So I brought up to the list 'fixing' this with an additional meta character to follow | that would distinguish sh from non-sh invocations, and permit both. Since we really need to fix this in 2.2 / 2.0 and want to do so harming as few users as possible (it would be clearly called out in CHANGES, but none the less) please vote between one of these two possible solutions that could be applied to 2.0 and 2.2 branches... [ ] Revert to |foo to invoke foo, and add |$foo syntax to launch foo via sh [ ] Retain |foo to invoke foo through sh, and add ||foo syntax to directly launch foo Just to be weird: |$foo syntax launches foo via sh ||foo syntax launches foo directly |foo tries to make the right decision: Windows: APR is busted, so launch foo directly Other platforms: starts with slash and contains no redirection? launches foo directly else launches foo via sh This is expected to do the right thing for just about everybody -- almost no regression, with neatness improvement (Unix users not needing to see the extra /bin/sh hanging around) or functional improvement (Windows users avoiding APR problem) for most folks. Drawback: Some people may not be ready to understand the resulting doc.
have any DAV-savants seen PR 42896 dav_method_put deletes entire file when PUT with content-range fails
(http://issues.apache.org/bugzilla/show_bug.cgi?id=42896) Someone pinged me about this PR thinking I might have a cl00, but alas they got rotten results from their intranet search. Does anyone find that PR interesting enough to respond to? Thanks! -- Born in Roswell... married an alien...
Re: svn commit: r549159 - in /httpd/httpd/trunk: CHANGES modules/generators/mod_status.c
On 6/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jorton Date: Wed Jun 20 10:29:24 2007 New Revision: 549159 URL: http://svn.apache.org/viewvc?view=revrev=549159 Log: Fix CVE-2006-5752: * modules/generators/mod_status.c (status_handler): Specify charset in content-type to prevent browsers doing charset detection, which allows an XSS attack. Use logitem-escaping on the request string to make it charset-neutral. assert( The part of the fix that addresses the vulnerability is providing the charset; the escaping change is just for predictable display. So the following is a simple, understandable circumvention. Location /server-status SetHandler server-status AddDefaultCharset ISO-8859-1 ... /Location ) ???
Re: svn commit: r549159 - in /httpd/httpd/trunk: CHANGES modules/generators/mod_status.c
On 7/18/07, Joe Orton [EMAIL PROTECTED] wrote: On Wed, Jul 18, 2007 at 08:25:59AM -0400, Jeff Trawick wrote: On 6/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jorton Date: Wed Jun 20 10:29:24 2007 New Revision: 549159 URL: http://svn.apache.org/viewvc?view=revrev=549159 Log: Fix CVE-2006-5752: * modules/generators/mod_status.c (status_handler): Specify charset in content-type to prevent browsers doing charset detection, which allows an XSS attack. Use logitem-escaping on the request string to make it charset-neutral. assert( The part of the fix that addresses the vulnerability is providing the charset; the escaping change is just for predictable display. So the following is a simple, understandable circumvention. Location /server-status SetHandler server-status AddDefaultCharset ISO-8859-1 ... /Location ) ??? That's all correct, yes, sorry if the wording is not clear above. no worries; better safe than sorry; thanks as always!
Re: svn commit: r556298 - in /httpd/httpd/branches/2.0.x: CHANGES STATUS server/mpm_common.c
On 7/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: sctemme Date: Sat Jul 14 10:03:18 2007 New Revision: 556298 URL: http://svn.apache.org/viewvc?view=revrev=556298 Log: Backport of 2.0.x PID table problem fix + *) SECURITY: CVE-2007-3304 (cve.mitre.org) + scoreboard pid protection fixes -- the only fix for 2.0.x is + to ensure a valid positive pid is passed to apr_proc_wait(); + the MPMs do not kill children directly as in 2.2.x. assert( CVE-2007-3304 does not apply to 2.0.x. This commit is a fix in the same general area as the 2.2.x vulnerability and should not have the SECURITY/CVE label. )
Re: svn commit: r556298 - in /httpd/httpd/branches/2.0.x: CHANGES STATUS server/mpm_common.c
On 7/19/07, Joe Orton [EMAIL PROTECTED] wrote: On Thu, Jul 19, 2007 at 08:30:37AM -0400, Jeff Trawick wrote: On 7/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: sctemme Date: Sat Jul 14 10:03:18 2007 New Revision: 556298 URL: http://svn.apache.org/viewvc?view=revrev=556298 Log: Backport of 2.0.x PID table problem fix + *) SECURITY: CVE-2007-3304 (cve.mitre.org) + scoreboard pid protection fixes -- the only fix for 2.0.x is + to ensure a valid positive pid is passed to apr_proc_wait(); + the MPMs do not kill children directly as in 2.2.x. assert( CVE-2007-3304 does not apply to 2.0.x. This commit is a fix in the same general area as the 2.2.x vulnerability and should not have the SECURITY/CVE label. ) I erroneously claimed that originally, then later found an attack vector for -3304 which did work for 2.0.x: http://mail-archives.apache.org/mod_mbox/httpd-dev/200706.mbox/[EMAIL PROTECTED] The wording above is not really appropriate for CHANGES, I've just fixed that. thanks for the big clues; any need to fix mitre.org text?
[PATCH] CVE-2006-5752 for 1.3.x
Index: src/modules/standard/mod_status.c === --- src/modules/standard/mod_status.c (revision 558006) +++ src/modules/standard/mod_status.c (working copy) @@ -221,7 +221,7 @@ if (r-method_number != M_GET) return DECLINED; -r-content_type = text/html; +r-content_type = text/html; charset=ISO-8859-1; /* * Simple table-driven form data set parser that lets you alter the header @@ -247,7 +247,7 @@ no_table_report = 1; break; case STAT_OPT_AUTO: - r-content_type = text/plain; + r-content_type = text/plain; charset=ISO-8859-1; short_report = 1; break; }
Re: [PATCH] CVE-2006-5752 for 1.3.x
On 7/20/07, Sander Temme [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 7:30 AM, Jeff Trawick wrote: Index: src/modules/standard/mod_status.c +1, it's the same stuff we did for 2.2 in r549159. What about the ap_escape_logitem stuff in that same commit, does that apply to 1.3? it is applicable; I forgot to port the other change over; I'll re-post when I get that tested
Re: [PATCH] CVE-2006-5752 for 1.3.x
On 7/20/07, Jeff Trawick [EMAIL PROTECTED] wrote:
On 7/20/07, Sander Temme [EMAIL PROTECTED] wrote:
On Jul 20, 2007, at 7:30 AM, Jeff Trawick wrote:
Index: src/modules/standard/mod_status.c
+1, it's the same stuff we did for 2.2 in r549159.
What about the ap_escape_logitem stuff in that same commit, does that
apply to 1.3?
unidiotified patch attached
(indentation looks slightly off due to use of tabs in original code)
browser appearance of ExtendedStatus section w/o ap_escape_logitem():
GET /cgi-bin/sleep.pl/fooýüûúùø÷ö HTTP/1.1
with:
GET /cgi-bin/sleep.pl/foo\xfd\xfc\xfb\xfa\xf9\xf8\xf7\xf6 HTTP/1.1
Index: src/modules/standard/mod_status.c
===
--- src/modules/standard/mod_status.c (revision 558006)
+++ src/modules/standard/mod_status.c (working copy)
@@ -221,7 +221,7 @@
if (r-method_number != M_GET)
return DECLINED;
-r-content_type = text/html;
+r-content_type = text/html; charset=ISO-8859-1;
/*
* Simple table-driven form data set parser that lets you alter the header
@@ -247,7 +247,7 @@
no_table_report = 1;
break;
case STAT_OPT_AUTO:
- r-content_type = text/plain;
+ r-content_type = text/plain; charset=ISO-8859-1;
short_report = 1;
break;
}
@@ -570,7 +570,8 @@
ap_rputs()\n, r);
ap_rprintf(r, i%s {%s}/i b[%s]/bbr\n\n,
ap_escape_html(r-pool, score_record.client),
- ap_escape_html(r-pool, score_record.request),
+ ap_escape_html(r-pool,
+ ap_escape_logitem(r-pool,
score_record.request)),
vhost ? ap_escape_html(r-pool,
vhost-server_hostname) : (unavailable));
}
@@ -657,7 +658,8 @@
ap_escape_html(r-pool, score_record.client),
vhost ? ap_escape_html(r-pool,
vhost-server_hostname) : (unavailable),
-ap_escape_html(r-pool, score_record.request));
+ap_escape_html(r-pool,
+ap_escape_logitem(r-pool,
score_record.request)));
} /* no_table_report */
} /* !short_report */
} /* if (active child) */
Re: x64/x86: Apache http server 2.0.55 is getting installed with some errors, server does not start after installation
On 7/31/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Hossein Kholdinasab (Siemens Business Services Inc) wrote: Hello, This is a follow up on the email I sent on June 6^th regarding a support status for Apache application on Windows LHS, could you please review this request and if necessary for ward it to an appropriate group responsible for this application and have contact me as soon as possible? That would be [EMAIL PROTECTED] Please don't email [EMAIL PROTECTED] without an undisclosed security vulnerability to report. As Microsoft is preparing to release Windows Longhorn Server in the near future, we would like to know your plans for supporting *x64/x86: Apache http server 2.0.55* on Windows Longhorn Server. You might be unfamiliar with the concept of open-source development. There are companies, including my employer, Covalent Technologies, who do stand behind this particular project with warranties and indemnities, but if you read the license to httpd; http://www.apache.org/licenses/LICENSE-2.0.txt you quickly realize there is no warranty by the ASF, ... ... ... great response possible faq entry
Re: svn commit: r567091 - in /httpd/httpd/trunk: CHANGES modules/ldap/util_ldap.c
On 8/17/07, Eric Covener [EMAIL PROTECTED] wrote: On 8/17/07, Jim Jagielski [EMAIL PROTECTED] wrote: Does this change really require a CHANGES entry?? [EMAIL PROTECTED] wrote: Author: covener Date: Fri Aug 17 10:33:11 2007 New Revision: 567091 URL: http://svn.apache.org/viewvc?view=revrev=567091 Log: AFAICT, LDAP_CACHE_LOCK was a no-op when virtualhosts were used I can expand or remove it; there's crash/hang potential (observed) as the cache code goes into shared memory. can't remove; problem was the wording *) Fix crashes, high CPU loops, or potentially other problems in mod_ldap by properly handling the cache lock when vhost configs are merged. or something like that
Re: svn commit: r567091 - in /httpd/httpd/trunk: CHANGES modules/ldap/util_ldap.c
On 8/17/07, Jim Jagielski [EMAIL PROTECTED] wrote: On Aug 17, 2007, at 1:46 PM, Eric Covener wrote: On 8/17/07, Jim Jagielski [EMAIL PROTECTED] wrote: Does this change really require a CHANGES entry?? [EMAIL PROTECTED] wrote: Author: covener Date: Fri Aug 17 10:33:11 2007 New Revision: 567091 URL: http://svn.apache.org/viewvc?view=revrev=567091 Log: AFAICT, LDAP_CACHE_LOCK was a no-op when virtualhosts were used I can expand or remove it; there's crash/hang potential (observed) as the cache code goes into shared memory. How about creating a PR about it and then closing it out. That way it's a documented bug that is closed; if it affects people, the PR will provide insight into what was wrong and what was fixed, and the CHANGES entry can be adjusted to reflect the PR number. I'm confused. Visually it doesn't look like Lotus Notes where I'm reading this, but the message better fits employer; corporate standards. (And yes, in that other world I'd want a formal external description of the problem with nice text for customers and support to use to know exactly what conditions they need the fix and what is changed and so on). That's very expensive, and also something that hasn't been done in the past when a developer has a fix to commit.
Re: resolving piped logging bugs...
On 8/20/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Just a quick update; I have windows running again after creating a NUL (/dev/null) association for the parent processes' stdout handle. It solves a regression introduced in r483967 on Windows. D00d!!
Re: svn commit: r571203 - /httpd/httpd/branches/2.2.x/modules/proxy/ajp_header.c
On 8/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: martin Date: Thu Aug 30 08:22:58 2007 New Revision: 571203 URL: http://svn.apache.org/viewvc?rev=571203view=rev Log: Add missing end-of-string checks by using strcmp in place of memcmp memcmp() is not needed when you know the length of one of the strings; there's no missing check. The style on the other hand is subject to debate. Meanwhile there may be a bug fix buried in here -- using case-insignificant comparison for a HTTP header field name.
Re: svn commit: r571203 - /httpd/httpd/branches/2.2.x/modules/proxy/ajp_header.c
On 8/30/07, Jeff Trawick [EMAIL PROTECTED] wrote: On 8/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: martin Date: Thu Aug 30 08:22:58 2007 New Revision: 571203 URL: http://svn.apache.org/viewvc?rev=571203view=rev Log: Add missing end-of-string checks by using strcmp in place of memcmp memcmp() is not needed when you know the length of one of the strings; there's no missing check. The style on the other hand is subject to debate. Meanwhile there may be a bug fix buried in here -- using case-insignificant comparison for a HTTP header field name. I guess it is shame on me for not reading prior [EMAIL PROTECTED] posts to understand the commit message.
Re: Want to kill Apache process when its parent process gets killed.
On 9/10/07, Ashwani Kumar Sharma [EMAIL PROTECTED] wrote:
In my application I am spawning httpd.exe from the parent process.
...
My requirement is that:
...
In the Abnormal termination of the parent process. The Apache should keep
looking for its parent process. If the parent process is not present
then the Apache web server should also kill itself.
How can I implement the 2nd point?
not even a half-baked idea:
Somebody gets the monitor hook called from the Windows MPM (i.e.,
fixes Apache on Windows to call a hook that is provided on
Unix/Linux).
General idea (mpm_winnt.c)
/* Wait for shutdown or restart events or for child death */
winnt_mpm_state = AP_MPMQ_RUNNING;
do {
rv = WaitForMultipleObjects(NUM_WAIT_HANDLES, (HANDLE *)
event_handles, FALSE, something-that-means-one-second);
if (rv == WAIT_TIMEOUT) {
ap_run_monitor(pconf);
}
} while (rv == WAIT_TIMEOUT);
(remove existing check for WAIT_TIMEOUT that considers it a fatal error)
Your application starts httpd.exe with a define like
-DMOD_FOO_MONITORED_PID=13579
and a config that loads a custom plug-in module provided by you which
implements the monitor hook that checks for when that pid goes away.
???How to make the monitor hook take down httpd? apache -k stop???
Re: Want to kill Apache process when its parent process gets killed.
On 9/11/07, Ashwani Kumar Sharma [EMAIL PROTECTED] wrote: Hi Jeff, Thanks for your reply. The httpd.exe of Apache web server has two processes running in windows. When we kill the parent httpd.exe the child httpd.exe is still running and listening to the web request. I don't want this. When you said In my application I am spawning httpd.exe from the parent process. I assumed thereafter that parent refers to your own application that starts the web server, but you have a different kind of issuefor which I have no ideas. Good luck...
Re: [PATCH 43415] Logging remote port.
On 9/18/07, Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote:
-Ursprüngliche Nachricht-
Von: Adam Hasselbalch Hansen
Gesendet: Dienstag, 18. September 2007 12:25
An: dev@httpd.apache.org
Betreff: [PATCH 43415] Logging remote port.
I have created a patch for httpd 2.2.6, giving the additional
LogFormat
directive %R, which logs the port of the host making the request.
This is due to new legislation in Denmark, requiring ISPs and hosting
companies to log the originating port of all traffic.
5 comments:
3. I am not too happy with using %R, but to be honest I have no better
proposal :-).
Maybe other have.
%{canonical}p (default)
%{local}p
%{remote}p
Re: [PATCH 43415] Logging remote port.
On 9/24/07, Ruediger Pluem [EMAIL PROTECTED] wrote:
On 09/23/2007 10:49 PM, Jeff Trawick wrote:
On 9/18/07, Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote:
-Ursprüngliche Nachricht-
Von: Adam Hasselbalch Hansen
Gesendet: Dienstag, 18. September 2007 12:25
An: dev@httpd.apache.org
Betreff: [PATCH 43415] Logging remote port.
I have created a patch for httpd 2.2.6, giving the additional
LogFormat
directive %R, which logs the port of the host making the request.
This is due to new legislation in Denmark, requiring ISPs and hosting
companies to log the originating port of all traffic.
5 comments:
3. I am not too happy with using %R, but to be honest I have no better
proposal :-).
Maybe other have.
%{canonical}p (default)
%{local}p
%{remote}p
Sounds good to me.
The attached patch works for me (though I haven't yet rebuilt the docs
to see what that looks like).
[EMAIL PROTECTED] httpd]$ egrep
'(^ServerName|^.VirtualHost|^Listen|ports$)'
/scratch/inst/23/conf/httpd.conf
Listen 8089
LogFormat %h %l %u %t \%r\ %s %b PORTS: %p %{canonical}p
%{local}p %{remote}p %{bogusarg}p ports
CustomLog logs/access_log ports
VirtualHost *:8089
ServerName localhost:
[EMAIL PROTECTED] httpd]$ tail -1 /scratch/inst/23/logs/access_log
127.0.0.1 - - [24/Sep/2007:07:56:55 -0400] GET / HTTP/1.0 200 45
PORTS: 8089 65001 bogusarg
--
Born in Roswell... married an alien...
Index: modules/loggers/mod_log_config.c
===
--- modules/loggers/mod_log_config.c(revision 578767)
+++ modules/loggers/mod_log_config.c(working copy)
@@ -633,8 +633,22 @@
static const char *log_server_port(request_rec *r, char *a)
{
-return apr_psprintf(r-pool, %u,
-r-server-port ? r-server-port :
ap_default_port(r));
+apr_port_t port;
+
+if (*a == '\0' || !strcmp(a, canonical)) {
+port = r-server-port ? r-server-port : ap_default_port(r);
+}
+else if (!strcmp(a, remote)) {
+port = r-connection-remote_addr-port;
+}
+else if (!strcmp(a, local)) {
+port = r-connection-local_addr-port;
+}
+else {
+/* bogus format */
+return a;
+}
+return pfmt(r-pool, (int)port);
}
/* This respects the setting of UseCanonicalName so that
Index: docs/manual/mod/mod_log_config.xml
===
--- docs/manual/mod/mod_log_config.xml (revision 578767)
+++ docs/manual/mod/mod_log_config.xml (working copy)
@@ -127,6 +127,12 @@
trtdcode%p/code/td
tdThe canonical port of the server serving the request/td/tr
+trtdcode%{varformat/var}p/code/td
+tdThe canonical port of the server serving the request or the
+server's actual port or the client's actual port. Valid formats
+are codecanonical/code, codelocal/code, or coderemote/code.
+/td/tr
+
trtdcode%P/code/td
tdThe process ID of the child that serviced the request./td/tr
Re: [PATCH 43415] Logging remote port.
On 9/24/07, Jeff Trawick [EMAIL PROTECTED] wrote:
On 9/24/07, Ruediger Pluem [EMAIL PROTECTED] wrote:
On 09/23/2007 10:49 PM, Jeff Trawick wrote:
On 9/18/07, Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote:
-Ursprüngliche Nachricht-
Von: Adam Hasselbalch Hansen
Gesendet: Dienstag, 18. September 2007 12:25
An: dev@httpd.apache.org
Betreff: [PATCH 43415] Logging remote port.
I have created a patch for httpd 2.2.6, giving the additional
LogFormat
directive %R, which logs the port of the host making the request.
This is due to new legislation in Denmark, requiring ISPs and hosting
companies to log the originating port of all traffic.
5 comments:
3. I am not too happy with using %R, but to be honest I have no better
proposal :-).
Maybe other have.
%{canonical}p (default)
%{local}p
%{remote}p
Sounds good to me.
The attached patch works for me (though I haven't yet rebuilt the docs
to see what that looks like).
I'm planning to commit sometime tomorrow unless somebody objects...
--
Born in Roswell... married an alien...
Re: [PATCH 43415] Logging remote port.
On 9/24/07, Ruediger Pluem [EMAIL PROTECTED] wrote:
On 09/24/2007 02:04 PM, Jeff Trawick wrote:
On 9/24/07, Ruediger Pluem [EMAIL PROTECTED] wrote:
On 09/23/2007 10:49 PM, Jeff Trawick wrote:
On 9/18/07, Plüm, Rüdiger, VF-Group [EMAIL PROTECTED] wrote:
-Ursprüngliche Nachricht-
Von: Adam Hasselbalch Hansen
Gesendet: Dienstag, 18. September 2007 12:25
An: dev@httpd.apache.org
Betreff: [PATCH 43415] Logging remote port.
I have created a patch for httpd 2.2.6, giving the additional
LogFormat
directive %R, which logs the port of the host making the request.
This is due to new legislation in Denmark, requiring ISPs and hosting
companies to log the originating port of all traffic.
5 comments:
3. I am not too happy with using %R, but to be honest I have no better
proposal :-).
Maybe other have.
%{canonical}p (default)
%{local}p
%{remote}p
Sounds good to me.
The attached patch works for me (though I haven't yet rebuilt the docs
to see what that looks like).
Patch looks good to me (including docs, which I rebuilt in my working copy),
but as most of the time some comments :-).
thanks, of course!
1. I would use strcasecmp instead of strcmp to avoid case issues in the
config.
sure; FWIW, some other format string comparisons are not case
insignificant, but those can be checked for in the fullness of time
2. We can save a few cycles by using apr_itoa instead of pfmt as IMHO port is
never
= 0.
BTW: I think format_integer should be removed as it is only used by pfmt. It
can be replaced
with apr_itoa. Just did this in r578927.
sure; I recall you mentioning apr_itoa() on this thread but I guess I forgot
I'll fix up before long.
Have fun!
Re: As we contemplate what to fix, and how to roll out 2.4 and 3.0
On 10/2/07, Jim Jagielski [EMAIL PROTECTED] wrote: On Oct 1, 2007, at 6:52 PM, William A. Rowe, Jr. wrote: William A. Rowe, Jr. wrote: Give that some thought :) One thing I'm pondering is a 2.3.0 alpha in the near future. If only to give the we stay back at version n.x-1 crowd something to chew on. Not to mention that it would be good for folks to start exploring what needs to be fixed in the API, etc. Well, we could do: o Apache 1.3 and 2.0 deprecated (deprecated == no fixes after some date) Somebody somewhere will patch 1.3.last with security fixes for newly-discovered vulnerabilities. If nowhere visible/common, then possibly 100s of individuals will be doing that for themselves. Is there really enough value in making a statement that we disagree with those many servers continuing to run 1.3 to justify sending Apache users somewhere else for fixes? (When there are fewer than 3 httpd developers willing to review/approve/publish security fixes for 1.3, this is of course irrelevant.)
Re: mod_substitute in 2.2's experimental?
On 10/8/07, Jim Jagielski [EMAIL PROTECTED] wrote: Thoughts on adding mod_substitute to 2.2.x under experimental? if in 2.2.x at all, why not in the normal modules directory? is it really experimental, or is experimental considered a political compromise, or is there something else I'm not thinking of?
Re: Error from DSOLoadLibrary in Apache2.0.61(64 bit) on AIX 5.3(64 bit)
On 10/9/07, Renu Tiwari [EMAIL PROTECTED] wrote: We are facing an issue in dynamically loading the thirdparty module to Apache2.0.61 server. Error shown in error_logs of Apache server is *Error from DSOLoadLibrary - Not enough space.* That's not an Apache message, FWIW. I can't find a reference to DSOLoadLibrary. googling indicates that some symbol table might be full and maybe some other ld options need to be used (something about big table of contents -- ld flag bigtoc) See if there is a LDR_CNTRL setting in bin/envvars. If there is one (I don't think there should be one for 64-bit), comment it out to confirm that it doesn't hurt this. Call AIX support. Work with AIX folks that help ISVs.
Re: Error from DSOLoadLibrary in Apache2.0.61(64 bit) on AIX 5.3(64 bit)
On 10/9/07, Renu Tiwari [EMAIL PROTECTED] wrote: Hi Thanks for the reply. Just wanted to confirm one thing. We have build the apache 2.0.61 source on AIX 5.2(64 bit) and than placed the resultant Apache folder structure to AIX5.3(64 bit) m/c. Can this cause some kind of discrepencies? It shouldn't ;)
[PATCH] fix 1.3's ap_proxy_date_canon error handling
like 2.0/2.2/trunk
I'm looking for a conceptual +1 out there.
I've barely tested it and need to summarize the diffs between ap_ and
apr_ functions again. (e.g., apr_date_parse_http supports format XXX
that ap_parseHTTPdate() doesn't support, but ap_proxy_date_canon()
didn't allow that before anyway so it doesn't regress...)
--
Born in Roswell... married an alien...
Index: src/modules/proxy/proxy_util.c
===
--- src/modules/proxy/proxy_util.c (revision 586541)
+++ src/modules/proxy/proxy_util.c (working copy)
@@ -267,61 +267,17 @@
* formatted, then it exits very quickly.
*/
const char *
- ap_proxy_date_canon(pool *p, const char *x)
+ ap_proxy_date_canon(pool *p, const char *date)
{
-int wk, mday, year, hour, min, sec, mon;
-char *q, month[4], zone[4], week[4];
+time_t t;
-q = strchr(x, ',');
-/* check for RFC 850 date */
-if (q != NULL q - x 3 q[1] == ' ') {
-*q = '\0';
-for (wk = 0; wk 7; wk++)
-if (strcmp(x, lwday[wk]) == 0)
-break;
-*q = ',';
-if (wk == 7)
-return x; /* not a valid date */
-if (q[4] != '-' || q[8] != '-' || q[11] != ' ' || q[14] != ':' ||
-q[17] != ':' || strcmp(q[20], GMT) != 0)
-return x;
-if (sscanf(q + 2, %u-%3s-%u %u:%u:%u %3s, mday, month, year,
- hour, min, sec, zone) != 7)
-return x;
-if (year 70)
-year += 2000;
-else
-year += 1900;
+t = ap_parseHTTPdate(date);
+if (t == BAD_DATE) {
+return date;
}
-else {
-/* check for acstime() date */
-if (x[3] != ' ' || x[7] != ' ' || x[10] != ' ' || x[13] != ':' ||
-x[16] != ':' || x[19] != ' ' || x[24] != '\0')
-return x;
-if (sscanf(x, %3s %3s %u %u:%u:%u %u, week, month, mday, hour,
- min, sec, year) != 7)
-return x;
-for (wk = 0; wk 7; wk++)
-if (strcmp(week, ap_day_snames[wk]) == 0)
-break;
-if (wk == 7)
-return x;
-}
-
-/* check date */
-for (mon = 0; mon 12; mon++)
-if (strcmp(month, ap_month_snames[mon]) == 0)
-break;
-if (mon == 12)
-return x;
-
-q = ap_palloc(p, 30);
-ap_snprintf(q, 30, %s, %.2d %s %d %.2d:%.2d:%.2d GMT, ap_day_snames[wk],
mday,
-ap_month_snames[mon], year, hour, min, sec);
-return q;
+return ap_gm_timestr_822(p, t);
}
-
/*
* Reads headers from a buffer and returns an array of headers.
* Returns NULL on file error
Re: [PATCH] fix 1.3's ap_proxy_date_canon error handling
On 10/23/07, Jim Jagielski [EMAIL PROTECTED] wrote: On Oct 22, 2007, at 7:20 PM, Jeff Trawick wrote: like 2.0/2.2/trunk I'm looking for a conceptual +1 out there. You got it. Conceptual +1 :) Thanks ;) Kind of silly I realize, but I wanted to make sure that if I spend more time on this then somebody is likely to read/review further.
1.3 pid table changes vs. uptime?
With 1.3.39, typically 16 bytes are lost forever in the parent process at child process creation with the ap_table_set(). Did anyone work through a rationalization of this? Perhaps we could say that 8MB is the amount by which the size of the parent could grow in three months before causing undue interest (i.e., wasting investigation time)... That allows around 500,000 process creations to leak 16 bytes each in the three months, which is around 5000 process creations a day. 5000 process creations a day doesn't seem at all out of range for a busy 1.3 server on Unix. 8MB doesn't seem out of range for growth for a closely watched server. 3 months doesn't seem at all longer than a desirable uptime. I don't see any hashing of keys for speedy lookups in 1.3 ap_table_get() to jpotentially ustify the memory overhead. Alternative opinions? -- Born in Roswell... married an alien...
Re: 1.3 pid table changes vs. uptime?
On 10/24/07, Jim Jagielski [EMAIL PROTECTED] wrote:
On Oct 24, 2007, at 8:54 AM, Jim Jagielski wrote:
On Oct 23, 2007, at 7:34 PM, Jeff Trawick wrote:
Alternative opinions?
Alternative implementations are welcomed.
Certainly one trade-off would be speed over space; having
pid_table an actual (C) array of pids.
current space before creating any child processes:
. a small bit of ap_table overhead
. an array of HARD_SERVER_LIMIT * sizeof(table_entry), where
table_entry is a couple of char *
. and more storage allocated/lost as we add entries to the table
future space before and after creating any child processes:
. an array of HARD_SERVER_LIMIT * sizeof(pid_t)
(though I see we pass pid around as an int so maybe sizeof(int) is a
more accurate way to describe it)
we just won the space trade-off
When setting we would
sequentially scan through that array for an empty
space and tuck the pid in there; when removing we would
scan though until we found our pid and unset it (0).
current lookup:
ap_snprintf(apid, sizeof(apid), %d, pid);
for (i = 0; i HARD_SERVER_LIMIT; i++) {
if (!strcasecmp(pid_table[i].key, apid) {
break;
}
}
future lookup:
for (i = 0; i HARD_SERVER_LIMIT; i++) {
if (pid_table[i] == pid) {
break;
}
}
we just won the speed tradeoff
currently, when we actually modify the table to add or remove a pid,
we do this sort of logic:
else { /* delete an extraneous element */
for (j = i, k = i + 1; k t-a.nelts; ++j, ++k) {
elts[j].key = elts[k].key;
elts[j].val = elts[k].val;
}
--t-a.nelts;
}
instead of simply setting the array element to 0
I haven't profiled this so it actually might be better
than the overhead of using ap_tables...
Should I look at something like the above?
please ;)
(I need to get back to analyzing the proposed 1.3 proxy change to
ensure that differences between 1.3 utility routines and apr versions
don't make that a bad idea, as well as actually test it with more than
a cut-n-paste of the time string example in the asctime man page)
Re: 1.3 pid table changes vs. uptime?
On 10/24/07, Jim Jagielski [EMAIL PROTECTED] wrote: On Oct 24, 2007, at 10:20 AM, Jim Jagielski wrote: Looking at the below... testing as we speak: Testing past and placed it on a test server which gets hit with goodly amounts of traffic. So far, so good :) The patch looks fine to me, but I'll try to do some gdb-ing through it tonight anyway.
Re: [PATCH] fix 1.3's ap_proxy_date_canon error handling
On 10/22/07, Jeff Trawick [EMAIL PROTECTED] wrote:
like 2.0/2.2/trunk
attached is an updated patch for the boil-the-ocean flavor; at the
bottom is a tiny alternative
some ways to slice through the big patch:
1. my BIG 1.3 patch vs. the 2.0 commit
essentially same changes except for
s/apr_date_parse_http(date)/ap_parseHTTPdate(date)/
s/apr_rfc822_date(ndate, time)/ap_gm_timestr_822(p, t)/
and the fact that 2.0.x previously made a copy of the input date
string before parsing
The old 1.3.x version, without the logic to make a copy of the input,
temporarily modified the input date string, but it always restored the
original contents before returning.
2. use of ap_proxy_date_canon() in 1.3.x vs. 2.0.x
proxy_http.c callers in 2.0.x are the same as proxy_http.c callers in 1.3.x but
1.3.x also has callers in proxy_cache.c:
/* get the If-Modified-Since date of the request, if it exists */
c-ims = BAD_DATE;
datestr = ap_table_get(r-headers_in, If-Modified-Since);
if (datestr != NULL) {
/* this may modify the value in the original table */
datestr = ap_proxy_date_canon(r-pool, datestr);
c-ims = ap_parseHTTPdate(datestr);
if (c-ims == BAD_DATE) /* bad or out of range date; remove it */
ap_table_unset(r-headers_in, If-Modified-Since);
}
/* get the If-Unmodified-Since date of the request, if it exists */
c-ius = BAD_DATE;
datestr = ap_table_get(r-headers_in, If-Unmodified-Since);
if (datestr != NULL) {
/* this may modify the value in the original table */
datestr = ap_proxy_date_canon(r-pool, datestr);
c-ius = ap_parseHTTPdate(datestr);
if (c-ius == BAD_DATE) /* bad or out of range date; remove it */
ap_table_unset(r-headers_in, If-Unmodified-Since);
}
The comment this may modify the value in the original table is
perhaps alarming, but since ap_proxy_date_canon() restored the
original value, proxy_cache.c isn't relying on the modification as a
useful side-effect.
The call to ap_parseHTTPdate() right after ap_proxy_date_canon() is
more obviously wasteful now, since ap_parseHTTPdate() is the first
thing that ap_proxy_date_canon() calls, and the new string is
discarded.Thus the block for handling each date header can be
simplified to:
/* get the If-Modified-Since date of the request, if it exists and
is valid */
datestr = ap_table_get(r-headers_in, If-Modified-Since);
if (datestr != NULL) {
c-ims = ap_parseHTTPdate(datestr);
if (c-ims == BAD_DATE) /* bad or out of range date; remove it */
ap_table_unset(r-headers_in, If-Modified-Since);
}
else {
c-ims = BAD_DATE;
}
The proxy_cache.c code could be left alone with its extra parsing and
formatting, but as it deserves testing anyway it is best to test the
simpler path than the more complex one.
3. apr_date_parse_http(date) vs. ap_parseHTTPdate(date)
apr_date_parse_http supports an additional RFC 1123 variation with
only one digit for day of month (6 Oct 2007 instead of 06 Oct
2007). The old ap_proxy_date_canon() didn't support either, so it
doesn't matter.
4. apr_rfc822_date(ndate, time) vs. ap_gm_timestr_822(p, t)
same format created
5. other comments
ap_parseHTTPdate() ignores the name of the day but old
ap_proxy_date_canon() verified it. ap_parseHTTPdate() doesn't
actually need the day name to compute the proper time.
The new version has some extra math in ap_gm_timestr_822()'s call to
gmtime() , and calls ap_psprintf() instead of ap_palloc(p, 30) +
ap_snprintf().
--/--
OTOH, a couple of strlen() calls in the original code would be a more
pragmatic solution.
Index: src/modules/proxy/proxy_util.c
===
--- src/modules/proxy/proxy_util.c (revision 588101)
+++ src/modules/proxy/proxy_util.c (working copy)
@@ -282,7 +282,8 @@
*q = ',';
if (wk == 7)
return x; /* not a valid date */
-if (q[4] != '-' || q[8] != '-' || q[11] != ' ' || q[14] != ':' ||
+if (strlen(q) != 24 ||
+q[4] != '-' || q[8] != '-' || q[11] != ' ' || q[14] != ':' ||
q[17] != ':' || strcmp(q[20], GMT) != 0)
return x;
if (sscanf(q + 2, %u-%3s-%u %u:%u:%u %3s, mday, month, year,
@@ -295,7 +296,8 @@
}
else {
/* check for acstime() date */
-if (x[3] != ' ' || x[7] != ' ' || x[10] != ' ' || x[13] != ':' ||
+if (strlen(x) != 24 ||
+x[3] != ' ' || x[7] != ' ' || x[10] != ' ' || x[13] != ':' ||
x[16] != ':' || x[19] != ' ' || x[24] != '\0')
return x;
if (sscanf(x, %3s %3s %u %u:%u:%u %u, week, month, mday, hour,
I vote for the small patch, and canl also throw in a spell check for
that last comment above.
Index: src/modules/proxy/proxy_util.c
===
--- src/modules/proxy/proxy_util.c (revision 586541
Re: 1.3 pid table changes vs. uptime?
On 10/24/07, Jeff Trawick [EMAIL PROTECTED] wrote: On 10/24/07, Jim Jagielski [EMAIL PROTECTED] wrote: On Oct 24, 2007, at 10:20 AM, Jim Jagielski wrote: Looking at the below... testing as we speak: Testing past and placed it on a test server which gets hit with goodly amounts of traffic. So far, so good :) The patch looks fine to me, but I'll try to do some gdb-ing through it tonight anyway. I ran for a while with MaxRequestsPerChild 1 ProxyPass / http://www.ibm.com/ ProxyPassReverse / http://www.ibm.com/ and jumped around that site for a while, then did apachectl restart and got [Wed Oct 24 21:52:40 2007] [error] Bad pid (1707) in scoreboard slot 4 [Wed Oct 24 21:52:40 2007] [error] Bad pid (1702) in scoreboard slot 5 [Wed Oct 24 21:52:40 2007] [error] Bad pid (1708) in scoreboard slot 6 [Wed Oct 24 21:52:40 2007] [error] Bad pid (1712) in scoreboard slot 7 [Wed Oct 24 21:52:40 2007] [error] Bad pid (1713) in scoreboard slot 8 [Wed Oct 24 21:52:40 2007] [error] Bad pid (1714) in scoreboard slot 9 [Wed Oct 24 21:52:40 2007] [error] Bad pid (1715) in scoreboard slot 10 [Wed Oct 24 21:52:40 2007] [error] Bad pid (1716) in scoreboard slot 11 [Wed Oct 24 21:52:40 2007] [error] Bad pid (1717) in scoreboard slot 12 [Wed Oct 24 21:52:40 2007] [notice] SIGHUP received. Attempting to restart I can't yet reproduce it at will, but will try again tomorrow. I doubt this has anything to do with your current patch.
bogus Bad pid (%d) in scoreboard slot %d messages when restarting 1.3
I think this is the problem: When a child is reaped normally after
exiting due to MaxSpareServers or MaxRequestsPerChild, it remains in
the scoreboard with status set to SERVER_DEAD, and it is removed from
the pid table.
Often that slot will be reused by a child created subsequently.
If it is never reused before termination or hard restart,
reclaim_child_processes() will see it in this code and complain that
it isn't in the pid table:
for (i = 0; i max_daemons_limit; ++i) {
int pid = ap_scoreboard_image-parent[i].pid;
if (pid == my_pid || pid == 0)
continue;
if (!in_pid_table(pid)) {
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, server_conf,
Bad pid (%d) in scoreboard slot %d, pid, i);
continue;
}
But it doesn't need to complain if the child is in the scoreboard with
state SERVER_DEAD, since that means it exited previously and is out of
the pid table.
Here's a hack to look out for that situation:
if (!in_pid_table(pid)) {
-ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, server_conf,
- Bad pid (%d) in scoreboard slot %d, pid, i);
+ /* Report an error if the scoreboard state for this child is
+ * something besides SERVER_DEAD or if we can't find the
+ * child slot.
+ *
+ * It is okay to find it with state SERVER_DEAD. The child
+ * exited normally, the state was set to SERVER_DEAD, and we
+ * didn't subsequently reuse that scoreboard slot for another
+ * child.
+ */
+int child_slot = find_child_by_pid(pid);
+
+if (child_slot 0
+||
ap_scoreboard_image-servers[child_slot].status != SERVER_DEAD) {
+ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR,
server_conf,
+ Bad pid (%d) in scoreboard slot %d, pid, i);
+}
+else {
+ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR,
server_conf,
+ avoided bad pid msg for %d;
child_slot %d, status %d,
+ pid, child_slot, child_slot = 0 ?
ap_scoreboard_image-servers[child_slot].status : -1);
+}
continue;
}
The avoided bad pid msg is just for debugging, of course.
This is perhaps not cool on whatever imaginary machines keep the
scoreboard in a file. I never fully grokked the sync-scoreboard-image
requirements.
Re: bogus Bad pid (%d) in scoreboard slot %d messages when restarting 1.3
On 10/25/07, Jim Jagielski [EMAIL PROTECTED] wrote: On Oct 25, 2007, at 11:00 AM, Jeff Trawick wrote: I think this is the problem: When a child is reaped normally after exiting due to MaxSpareServers or MaxRequestsPerChild, it remains in the scoreboard with status set to SERVER_DEAD, and it is removed from the pid table. Often that slot will be reused by a child created subsequently. If it is never reused before termination or hard restart, reclaim_child_processes() will see it in this code and complain that it isn't in the pid table: Yep... that appears to be it. When setting SERVER_DEAD we aren't resetting the pid as well. Instead of working around that, wouldn't the most straightforward approach be to sync setting SERVER_DEAD status with also setting pid to 0? This could be done in ap_update_child_status() which would also hopefully address those file-based scoreboards as well. sure; I'm lacking cycles at the moment to start looking through the code for potential fallout; hope to start looking soon
Re: svn commit: r589602 - /httpd/httpd/branches/1.3.x/src/main/http_main.c
On 10/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jim
Date: Mon Oct 29 05:42:13 2007
New Revision: 589602
URL: http://svn.apache.org/viewvc?rev=589602view=rev
Log:
When setting status to SERVER_DEAD, reset pid as well.
Modified:
httpd/httpd/branches/1.3.x/src/main/http_main.c
Modified: httpd/httpd/branches/1.3.x/src/main/http_main.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/1.3.x/src/main/http_main.c?rev=589602r1=589601r2=589602view=diff
==
--- httpd/httpd/branches/1.3.x/src/main/http_main.c (original)
+++ httpd/httpd/branches/1.3.x/src/main/http_main.c Mon Oct 29 05:42:13 2007
@@ -2661,6 +2661,7 @@
if (status == SERVER_DEAD) {
ss-my_access_count = 0L;
ss-my_bytes_served = 0L;
+ap_scoreboard_image-parent[child_num].pid = 0;
}
ss-conn_count = (unsigned short) 0;
ss-conn_bytes = (unsigned long) 0;
+1
A CHANGES entry nothing the resolution of the bogus error message
would be helpful.
Re: svn commit: r592761 - /httpd/httpd/branches/2.2.x/STATUS
On Nov 7, 2007 4:21 PM, Nick Kew [EMAIL PROTECTED] wrote: On Wed, 07 Nov 2007 14:34:10 - [EMAIL PROTECTED] wrote: Author: trawick Date: Wed Nov 7 06:34:09 2007 New Revision: 592761 URL: http://svn.apache.org/viewvc?rev=592761view=rev Log: one commit to address multiple distinct issues can result in perpetual confusion :-) I missed your 2.2.x patch earlier. If it's important, I have no problem changing my comment to +1 for that alone. But preferably drop the reference to r571798. I'll try to find the time to create a master patch for the dbd+EBCDIC backport proposal to help get that unstuck... Then everybody gets their desired fix into 2.2.x.
Re: svn commit: r593778 - /httpd/httpd/branches/2.2.x/STATUS
On Nov 10, 2007 9:14 AM, Nick Kew [EMAIL PROTECTED] wrote:
On Sat, 10 Nov 2007 14:00:16 -
[EMAIL PROTECTED] wrote:
+ * mod_charset_lite: Remove Content-Length when output filter can
+ invalidate it. Warn when input filter can invalidate it.
+ trunk:
+http://svn.apache.org/viewvc?view=revrevision=380232
+ 2.2.x:
+Trunk version of patch works
+ +1: trawick
+
-0.
As you note, that's a non-fix for the input filter.
Unsetting content-length for input should move to the
find_code_page function (on a fixup hook).
That would break reading the request body (assuming client used c-l).
ap_http_filter(), which runs after the fixup hook, must see the c-l.
I don't see a way to indicate that the Content-Length may not be
correct. CGIs could break.
The attached patch describes the situation more accurately and doesn't
raise a concern unless the request actually had a c-l header.
I haven't thought of how to get to the end of the rainbow starting at either
* create a way to indicate to the handler that c-l is unknown without
breaking the reading of the request body
* provide an optional filter to compute c-l (buffering up to some
configured limit)
Thoughts?
Index: modules/filters/mod_charset_lite.c
===
--- modules/filters/mod_charset_lite.c (revision 593813)
+++ modules/filters/mod_charset_lite.c (working copy)
@@ -1060,15 +1060,21 @@
if (!ctx-ran) { /* filter never ran before */
chk_filter_chain(f);
ctx-ran = 1;
-if (!ctx-noop !ctx-is_sb) {
-/* We're not converting between two single-byte charsets, so note
- * that some handlers can't deal with it.
- * It doesn't help to unset Content-Length in the input header
- * table since in all likelihood the handler has already seen it.
+if (!ctx-noop !ctx-is_sb
+ apr_table_get(f-r-headers_in, Content-Length)) {
+/* A Content-Length header is present, but it won't be valid after
+ * conversion because we're not converting between two single-byte
+ * charsets. This will affect most CGI scripts and may affect
+ * some modules.
+ * Content-Length can't be unset here because that would break
+ * being able to read the request body.
+ * Processing of chunked request bodies are not impacted by this
+ * filter since the the length was not declared anyway.
*/
if (dc-debug = DBGLVL_PMC) {
ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, f-r,
- Request body length may change, breaking some
requests);
+ Request body length may change, resulting in
+ misprocessing by some modules or scripts);
}
}
}
Re: svn commit: r593778 - /httpd/httpd/branches/2.2.x/STATUS
On Nov 11, 2007 7:44 AM, Nick Kew [EMAIL PROTECTED] wrote: On Sat, 10 Nov 2007 21:08:37 -0500 Jeff Trawick [EMAIL PROTECTED] wrote: As you note, that's a non-fix for the input filter. Unsetting content-length for input should move to the find_code_page function (on a fixup hook). That would break reading the request body (assuming client used c-l). ap_http_filter(), which runs after the fixup hook, must see the c-l. I don't see a way to indicate that the Content-Length may not be correct. CGIs could break. Erm, right. Now you spell it out, yes, that's the same issue we had recently with mod_deflate, and my initial fix to that broke for the same reason. So +1 to your patch: it's the best we can do without a deeper change. Thanks for the extra thinking and review! The attached patch describes the situation more accurately and doesn't raise a concern unless the request actually had a c-l header. I haven't thought of how to get to the end of the rainbow starting at either * create a way to indicate to the handler that c-l is unknown without breaking the reading of the request body Note incoming c-l much earlier in the request processing cycle, and use that for ap_http_filter? This would make sense for apps that don't require c-l. Noting c-l earlier is part of it. I would distinguish between the cases apps that require c-l present vs. apps that require accurate c-l however. (I'm hoping you'll correct me on this ;) ) Currently, the mere presence of t-e or c-l in r-headers_in is the way a module determines if there is a request body. Unsetting it at any stage is going to confuse some module somewhere even if it doesn't require an accurate c-l. It seems that for 2.4/3.0 we need to provide more formal APIs for modules to use in lieu of checking for t-e or c-l headers. * provide an optional filter to compute c-l (buffering up to some configured limit) ISTR hacking up such a thing, then stumbling upon someone else's implementation of same (possibly in mod_proxy, which may have to insert a C-L for an HTTP/1.0 backend). Providing a filter to compute c-l seems to have a role in helping one glitch or another. Perhaps this hypothetical filter in combination with a run-very-first handler could pre-read the request body and calculate the final c-l so that the real handler checking c-l would find the proper value (assuming the body isn't too large to buffer).
Re: Please just apply my one-liner fix to bug #42035 and be done with it, no?
On Nov 12, 2007 8:22 AM, Dominique Quatravaux [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Orton just closed #42035 with status fixed while posting this enigmatic comment at http://issues.apache.org/bugzilla/show_bug.cgi?id=42035#c4: Backport status needs to be tracked in the appropriate STATUS file, not in bugzilla. What the blue badger is this supposed to mean? That Bugzilla is not to be used to report bugs in the 2.0 branch ?! You can use Bugzilla to report bugs in any version and we can consider it resolved in Bugzilla when we fix them in any version. There is a separate, developer-driven procedure for backporting changes to stable branches. You took the hint to post to dev@ (though perhaps not exactly as intended); I'll see that your fix is proposed for backport to 2.0.x, and developers will have a chance to approve it. Peace! Don't waste so much of your patience or others' over a one line patch which you can apply to new source distributions in almost no time at all.
Re: Please just apply my one-liner fix to bug #42035 and be done with it, no?
On Nov 12, 2007 6:47 PM, Jeff Trawick [EMAIL PROTECTED] wrote: I'll see that your fix is proposed for backport to 2.0.x, and developers will have a chance to approve it. http://svn.apache.org/viewvc?rev=594358view=rev
keepalive connections and exiting MPM processes
When the MPM process handling the connection is or will be exiting, we
can incorrectly tell the client that the connection will be held open
after the current request. This can result in user intervention
(retry the POST?) or failures for some requests sent subsequently on
that connection.
The case where we already know we're exiting at the time we determine
the keep-alive setting is simple to handle:
Index: modules/http/http_protocol.c
===
--- modules/http/http_protocol.c(revision 593813)
+++ modules/http/http_protocol.c(working copy)
@@ -48,6 +48,7 @@
#include util_charset.h
#include util_ebcdic.h
#include util_time.h
+#include ap_mpm.h
#include mod_core.h
@@ -187,6 +188,7 @@
* or they're a buggy twit coming through a HTTP/1.1 proxy
* andthe client is requesting an HTTP/1.0-style keep-alive
* or the client claims to be HTTP/1.1 compliant (perhaps a proxy);
+ * and this MPM process is not already exiting
* THEN we can be persistent, which requires more headers be output.
*
* Note that the condition evaluation order is extremely important.
@@ -212,7 +214,8 @@
(!apr_table_get(r-subprocess_env, nokeepalive)
|| apr_table_get(r-headers_in, Via))
((ka_sent = ap_find_token(r-pool, conn, keep-alive))
-|| (r-proto_num = HTTP_VERSION(1,1 {
+|| (r-proto_num = HTTP_VERSION(1,1)))
+ !ap_graceful_stop_signalled()) {
int left = r-server-keep_alive_max - r-connection-keepalives;
r-connection-keepalive = AP_CONN_KEEPALIVE;
It isn't so clear how to handle the remaining window, in which the MPM
process starts exiting while we send the response (and after we've
already determined the keepalive setting).
From ap_process_http_connection():
if (r-status == HTTP_OK) {
cs-state = CONN_STATE_HANDLER;
ap_process_request(r);
r = NULL;
}
if (c-keepalive != AP_CONN_KEEPALIVE || c-aborted)
break;
XXX
We could skip checking for graceful exit here since it is checked
as part of the keepalive determination, but the MPM process
could remain active much longer than expected (maybe we just
downloaded a very large file).
XXX
if (ap_graceful_stop_signalled())
break;
For the remaining timing window, I'm afraid that a vhost-specific
setting is needed to control whether we respect the connection
keepalive setting or the MPM state. (The latter is apparently good
enough for most folks, and it does avoid unexpected delays in child
processes exiting and switching to new configs.)
Thoughts?
Re: keepalive connections and exiting MPM processes
On Nov 13, 2007 8:57 AM, Plüm, Rüdiger, VF-Group
[EMAIL PROTECTED] wrote:
-Ursprüngliche Nachricht-
Von: Jeff Trawick
Gesendet: Dienstag, 13. November 2007 14:31
An: dev@httpd.apache.org
Betreff: keepalive connections and exiting MPM processes
When the MPM process handling the connection is or will be exiting, we
can incorrectly tell the client that the connection will be held open
after the current request. This can result in user intervention
(retry the POST?) or failures for some requests sent subsequently on
that connection.
...
It isn't so clear how to handle the remaining window, in which the MPM
process starts exiting while we send the response (and after we've
already determined the keepalive setting).
From ap_process_http_connection():
if (r-status == HTTP_OK) {
cs-state = CONN_STATE_HANDLER;
ap_process_request(r);
r = NULL;
}
if (c-keepalive != AP_CONN_KEEPALIVE || c-aborted)
break;
XXX
We could skip checking for graceful exit here since
it is checked
as part of the keepalive determination, but the MPM process
could remain active much longer than expected (maybe we just
downloaded a very large file).
XXX
if (ap_graceful_stop_signalled())
break;
For the remaining timing window, I'm afraid that a vhost-specific
setting is needed to control whether we respect the connection
keepalive setting or the MPM state. (The latter is apparently good
I guess we can leave it as it is in this situation. Although we SHOULD
send connection: close if want to close the connection it is no MUST
(8.1.2.1, last sentence first paragraph). And for pipelined requests the
client must be prepared to resend anyway if we do not process all pipelined
requests (8.1.2.2).
Apart from the SHOULD vs. MUST is the end-user issue when the client
software can't or won't retry automatically when confronted with a
validly-dropped connection ;)
[1.3 PATCH] another fix for Bad pid ... in scoreboard ... message
The last fix had a simple mistake: Good logic was inadvertently
trapped inside if (ap_extended_status), so a bunch of Bad pid
messages could show up at termination for folks with the default (off)
setting for ExtendedStatus.
Proposed fix:
Index: src/main/http_main.c
===
--- src/main/http_main.c(revision 594940)
+++ src/main/http_main.c(working copy)
@@ -2661,7 +2661,6 @@
if (status == SERVER_DEAD) {
ss-my_access_count = 0L;
ss-my_bytes_served = 0L;
-ap_scoreboard_image-parent[child_num].pid = 0;
}
ss-conn_count = (unsigned short) 0;
ss-conn_bytes = (unsigned long) 0;
@@ -2689,7 +2688,10 @@
ss-vhostrec = r-server;
}
}
-if (status == SERVER_STARTING r == NULL) {
+if (status == SERVER_DEAD) {
+ap_scoreboard_image-parent[child_num].pid = 0;
+}
+else if (status == SERVER_STARTING r == NULL) {
/* clean up the slot's vhostrec pointer (maybe re-used)
* and mark the slot as belonging to a new generation.
*/
Re: keepalive connections and exiting MPM processes
On Nov 13, 2007 10:38 AM, Jeff Trawick [EMAIL PROTECTED] wrote:
On Nov 13, 2007 8:57 AM, Plüm, Rüdiger, VF-Group
[EMAIL PROTECTED] wrote:
-Ursprüngliche Nachricht-
Von: Jeff Trawick
Gesendet: Dienstag, 13. November 2007 14:31
An: dev@httpd.apache.org
Betreff: keepalive connections and exiting MPM processes
When the MPM process handling the connection is or will be exiting, we
can incorrectly tell the client that the connection will be held open
after the current request. This can result in user intervention
(retry the POST?) or failures for some requests sent subsequently on
that connection.
...
It isn't so clear how to handle the remaining window, in which the MPM
process starts exiting while we send the response (and after we've
already determined the keepalive setting).
From ap_process_http_connection():
if (r-status == HTTP_OK) {
cs-state = CONN_STATE_HANDLER;
ap_process_request(r);
r = NULL;
}
if (c-keepalive != AP_CONN_KEEPALIVE || c-aborted)
break;
XXX
We could skip checking for graceful exit here since
it is checked
as part of the keepalive determination, but the MPM process
could remain active much longer than expected (maybe we just
downloaded a very large file).
XXX
if (ap_graceful_stop_signalled())
break;
For the remaining timing window, I'm afraid that a vhost-specific
setting is needed to control whether we respect the connection
keepalive setting or the MPM state. (The latter is apparently good
I guess we can leave it as it is in this situation. Although we SHOULD
send connection: close if want to close the connection it is no MUST
(8.1.2.1, last sentence first paragraph). And for pipelined requests the
client must be prepared to resend anyway if we do not process all pipelined
requests (8.1.2.2).
Apart from the SHOULD vs. MUST is the end-user issue when the client
software can't or won't retry automatically when confronted with a
validly-dropped connection ;)
Here's a patch to address that issue:
http://people.apache.org/~trawick/keepalive.txt
(KeepAliveWhileExiting On|Off, default Off)
It comes down to this check in ap_process_http_connection():
while ((r = ap_read_request(c)) != NULL) {
...
if (c-keepalive != AP_CONN_KEEPALIVE || c-aborted)
break;
...
if (!c-base_server-keep_alive_while_exiting
ap_graceful_stop_signalled())
break;
}
The only commentary I've seen on the general idea so far is that the
RFC doesn't force us to respect that persistence.
Re: svn commit: r596698 - in /httpd/httpd/trunk: CHANGES support/rotatelogs.c
On Nov 20, 2007 9:46 AM, [EMAIL PROTECTED] wrote: Author: trawick Date: Tue Nov 20 06:46:52 2007 New Revision: 596698 URL: http://svn.apache.org/viewvc?rev=596698view=rev Log: improve command-line parsing This is a first pass to identifying some parameter combinations that shouldn't be or don't happen to be implemented. It will change soon with a patch to address some of the don't happen to be implemented combinations.
Re: svn commit: r595954 - /httpd/httpd/trunk/modules/http/http_filters.c
On Nov 17, 2007 9:36 AM, [EMAIL PROTECTED] wrote:
Author: niq
Date: Sat Nov 17 06:36:58 2007
New Revision: 595954
URL: http://svn.apache.org/viewvc?rev=595954view=rev
Log:
Safer fix to PR43882 than in r595672.
Modified:
httpd/httpd/trunk/modules/http/http_filters.c
Modified: httpd/httpd/trunk/modules/http/http_filters.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?rev=595954r1=595953r2=595954view=diff
==
--- httpd/httpd/trunk/modules/http/http_filters.c (original)
+++ httpd/httpd/trunk/modules/http/http_filters.c Sat Nov 17 06:36:58 2007
@@ -115,11 +115,11 @@
lenp = apr_table_get(f-r-headers_in, Content-Length);
if (tenc) {
-/* RFC2616 allows qualifiers, so use strncasecmp */
-if (!strncasecmp(tenc, chunked, 7) !ap_strchr_c(tenc, ','))
{
+if (!strcasecmp(tenc, chunked)) {
ctx-state = BODY_CHUNK;
}
-else {
+ /* test lenp, because it gives another case we can handle */
+else if (!lenp) {
/* Something that isn't in HTTP, unless some future
* edition defines new transfer ecodings, is unsupported.
The overall flow now looks like:
if Transfer-Encoding {
if Transfer-Encoding == chunked {
respect it
}
else if no Content-Length {
log it and return an error
}
else {
UNHANDLED case with unrecognized Transfer-Encoding as well as
Content-Length
}
}
else if Content-Length {
respect CL
}
What is the intention for the UNHANDLED case?The code/comments
seem to imply we'll end up in the respect CL path.
Re: svn commit: r595954 - /httpd/httpd/trunk/modules/http/http_filters.c
On Nov 26, 2007 11:50 AM, Nick Kew [EMAIL PROTECTED] wrote:
On Mon, 26 Nov 2007 10:38:28 -0500
Jeff Trawick [EMAIL PROTECTED] wrote:
What is the intention for the UNHANDLED case?The code/comments
seem to imply we'll end up in the respect CL path.
Exactly.
Cool; we're in sync so far, which brings us to my concern: We won't
end up in the respect CL path ;)
Finding any Transfer-Encoding, supported or not, results in bypassing
this support for CL:
else if (lenp) {
char *endstr;
ctx-state = BODY_LENGTH;
errno = 0;
memory leak in 2.2.x balancer?
looks like a leak to me; what do you think?
Index: modules/proxy/mod_proxy_balancer.c
===
--- modules/proxy/mod_proxy_balancer.c (revision 598305)
+++ modules/proxy/mod_proxy_balancer.c (working copy)
@@ -654,7 +654,7 @@
const char *val;
if ((val = apr_table_get(params, ss))) {
if (strlen(val))
-bsel-sticky = apr_pstrdup(conf-pool, val);
+bsel-sticky = apr_pstrdup(r-pool, val);
else
bsel-sticky = NULL;
}
trunk looks much different here. Does anyone plan to backport the
larger changes to 2.2.x in the near term, or should we go for this
tweak?
Re: memory leak in 2.2.x balancer?
On Nov 27, 2007 8:47 AM, Plüm, Rüdiger, VF-Group
[EMAIL PROTECTED] wrote:
-Ursprüngliche Nachricht-
Von: Jeff Trawick
Gesendet: Dienstag, 27. November 2007 14:21
An: dev@httpd.apache.org
Betreff: memory leak in 2.2.x balancer?
looks like a leak to me; what do you think?
Index: modules/proxy/mod_proxy_balancer.c
===
--- modules/proxy/mod_proxy_balancer.c (revision 598305)
+++ modules/proxy/mod_proxy_balancer.c (working copy)
@@ -654,7 +654,7 @@
const char *val;
if ((val = apr_table_get(params, ss))) {
if (strlen(val))
-bsel-sticky = apr_pstrdup(conf-pool, val);
+bsel-sticky = apr_pstrdup(r-pool, val);
else
bsel-sticky = NULL;
}
trunk looks much different here. Does anyone plan to backport the
larger changes to 2.2.x in the near term, or should we go for this
tweak?
This is no leak as if it were possible to adjust the balancer settings via
the balancer manager their memory would need to be taken from a long living
pool or more precise from the shared memory. This is not implemented now.
So it makes no sense to adjust the balancer settings via the balancer manager.
For this reason this possibility was removed from trunk. So far no one has
found the energy to propose a clear backport of this change.
So if someone find the energy soon, fine. If not please leave everything as it
is as we face segfaults otherwise.
Thanks for the explanation. I'll try to find time to find a patch to
remove this misfeature from the 2.2.x branch.
[PATCH] axe ancient BIG_SECURITY_HOLE message
If you should conceivably use that hack, you already know about it.
Logging spits out \t and \n literally anyway so message looks horrible.
Practically all users seeing this message just need to change User and
get on with life.
--
Born in Roswell... married an alien...
Index: os/unix/unixd.c
===
--- os/unix/unixd.c (revision 599438)
+++ os/unix/unixd.c (working copy)
@@ -169,17 +169,11 @@
unixd_config.user_name = arg;
unixd_config.user_id = ap_uname2id(arg);
-#if !defined (BIG_SECURITY_HOLE) !defined (OS2)
+#if !defined (OS2)
if (unixd_config.user_id == 0) {
-return Error:\tApache has not been designed to serve pages while\n
-\trunning as root. There are known race conditions that\n
-\twill allow any local user to read any file on the system.\n
-\tIf you still desire to serve pages as root then\n
-\tadd -DBIG_SECURITY_HOLE to the CFLAGS env variable\n
-\tand then rebuild the server.\n
-\tIt is strongly suggested that you instead modify the User\n
-\tdirective in your httpd.conf file to list a non-root\n
-\tuser.\n;
+return Error: A root user id must not be used for request processing.
+ Modify the User directive in your httpd.conf file to list a
+ non-root user.;
}
#endif
Re: [PATCH] axe ancient BIG_SECURITY_HOLE message
On Nov 29, 2007 8:36 AM, Jeff Trawick [EMAIL PROTECTED] wrote: If you should conceivably use that hack, you already know about it. Logging spits out \t and \n literally anyway so message looks horrible. Practically all users seeing this message just need to change User and get on with life. patch was broken ;) this line must be left unchanged so that BIG_SECURITY_HOLE still works for those few -#if !defined (BIG_SECURITY_HOLE) !defined (OS2) +#if !defined (OS2)
Re: [PATCH] Case insensitive username matching for WIN32 and BS2000 (and OS2?)
On Dec 4, 2007 11:54 AM, Guenter Knauf [EMAIL PROTECTED] wrote: Hi Martin, The usernames in WIN32 are, IIRC , case insensitive (and they are in BS2000, and perhaps in OS2?). when authenticating against system accounts then NetWare is insensitive too. Some of the username auth code uses tables, and thus case insensitive matching, but at some places, user names are compared literally. The appended patch tries to make these literal comparisons case insensitive, too, by using strcasecmp() in place of strcmp(). just a thought: if we would create a new API like ap_cmp_username() we could use a configure flag like AuthCmpUserCaseInSensitive, and let the user self control the behavior instead of having it hardcoded platform-dependent; f.e. I think that if you use file-based auth on Win32 why shouldnt that be case-sensitive if the user wants that? Or am I missing something here? FWIW, z/OS system accounts are case insensitive too, and an auth module which checks the system account database needs to perform case insignificant comparisons just like telnetd or other servers would. But I like the idea that these non-system-account auth modules perform the same type of comparison on all platforms, and the administrator anywhere could opt for case-insignificant comparisons where appropriate.
Re: [PROPOSAL] introduce a global define for including unixd.h
On Dec 7, 2007 2:43 PM, Guenter Knauf [EMAIL PROTECTED] wrote:
Hi,
I came a couple of times already over the ifdefs to avoid the inclusion of
unixd.h;
also many 3rd party modules have this problem;
therefore I would like to see a global define somewhere for that, f.e.
AP(R?)_NEEDS_UNIXD_H or such; can we perhaps introduce that?
This would in future avoid such platform-ifdefs like this:
http://svn.apache.org/viewvc?view=revrevision=522933
Backing up a little, the interesting part that requires that header file is
#if !defined(OS2) !defined(WIN32) !defined(BEOS) !defined(NETWARE)
if (geteuid() == 0) {
chown(fsc-limitdbfile, unixd_config.user_id, -1);
chown(apr_pstrcat(p, fsc-limitdbfile, .LoCK, NULL),
unixd_config.user_id, -1);
chown(apr_pstrcat(p, fsc-limitdbfile, .db, NULL),
unixd_config.user_id, -1);
chown(apr_pstrcat(p, fsc-limitdbfile, .dir, NULL),
unixd_config.user_id, -1);
chown(apr_pstrcat(p, fsc-limitdbfile, .pag, NULL),
unixd_config.user_id, -1);
}
#endif
Consider providing a function in core that sets ownership of a file to
the user id of web server child processes when appropriate, and let
the file that implements that function worry about whether or not
unixd.h is needed. All platforms can implement the function, no-op or
not.
ssl_scache_dbm.c has chown() logic like that above. I don't know if
there are slight variations which should be accommodated.
Re: proxy returning apr_status_t to handler?
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
Re: proxy returning apr_status_t to handler?
On Dec 7, 2007 5:55 PM, Eric Covener [EMAIL PROTECTED] wrote: The particular instance I'm looking at is during the write of the post body. In this case I assume HTTP_BAD_GATEWAY should be returned from proxy_http instead of the status returned from pass_brigade? I'd guess HTTP_GATEWAY_TIME_OUT if we get a timeout error code, and HTTP_BAD_GATEWAY otherwise...
