Re: svn commit: r360461 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/httpd.h server/protocol.c
Roy T. Fielding wrote: On Jan 2, 2006, at 2:14 PM, Roy T. Fielding wrote: Now, if you want to tell me that those changes produced a net performance benefit on prefork (and thus are applicable to other MPMs), then I am all ears. I am easily convinced by comparative performance figures when the comparison is meaningful. lol, of course you choose the non-threaded MPM as a reference, which therefore should receive no meaningful performance change. The difference between an async wakeup and a poll result should be null for one socket pool, one process, one thread (of course select is a differently ugly beast, and if there were a platform that supported async with no poll, I'd laugh.) BTW, part of the reason I say that is because I have considered replacing the same code with something that doesn't parse the header fields until the request header/body separator line is seen, since that would allow the entire request header to be parsed in-place for the common case. Well ... you are using protocol knowledge that will render us http-bound when it comes time to efficently bind waka (no crlf delims in a binary format protocol, no?) or ftp (pushes a 'greeting' before going back to sleep.) But I'd agree these changes are radical enough that maintaining the async branch a while longer is probably a good thing. Bill
Re: svn commit: r360461 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/httpd.h server/protocol.c
On Jan 2, 2006, at 3:41 PM, Justin Erenkrantz wrote:
+static apr_status_t process_request_line(request_rec *r, char *line,
+ int skip_first)
+{
+if (!skip_first (r-the_request == NULL)) {
+/* This is the first line of the request */
+if ((line == NULL) || (*line == '\0')) {
+/* We skip empty lines because browsers have to tack
a CRLF
on to the end + * of POSTs to support old CERN
webservers.
+ */
+int max_blank_lines = r-server-limit_req_fields;
+if (max_blank_lines = 0) {
+max_blank_lines = DEFAULT_LIMIT_REQUEST_FIELDS;
+}
+r-num_blank_lines++;
+if (r-num_blank_lines max_blank_lines) {
+return APR_SUCCESS;
+}
+}
+set_the_request(r, line);
+}
This will cause a segfault if line is null and we are at or above
max_blank_lines. Perhaps you meant for an else clause here?
Yes, thanks for catching that.
+else {
+/* We've already read the first line of the request.
This is
either + * a header field or the blank line terminating
the header
+ */
+if ((line == NULL) || (*line == '\0')) {
+if (r-pending_header_line != NULL) {
+apr_status_t rv = set_mime_header(r,
r-pending_header_line); +if (rv != APR_SUCCESS) {
+return rv;
+}
+r-pending_header_line = NULL;
+}
+if (r-status == HTTP_REQUEST_TIME_OUT) {
+apr_table_compress(r-headers_in,
APR_OVERLAP_TABLES_MERGE);
+r-status = HTTP_OK;
Say what? ...looks at rest of file...
Is this because r-status is unset and we're saying that's it's
'okay' to proceed with the request. If so, this *really* needs a
comment to that effect. It makes no sense whatsoever otherwise.
(We should probably remove the hack to set it to
HTTP_REQUEST_TIME_OUT initially as part of these changes.)
Yeah, setting r-status to HTTP_OK is done here solely to make it work
with the existing logic about HTTP_REQUEST_TIME_OUT meaning still
reading the request header.
+1 for of removing the HTTP_REQUEST_TIME_OUT hack. I was trying
to be conservative by preserving that part of the original logic, but
now
that you mention it, we might as well replace it with something less
subtle
in 2.3. This will break any 3rd party modules that depend upon the
HTTP_REQUEST_TIME_OUT convention, but for a major release
like 2.4 or 3.0 that's a defensible choice.
+}
+}
+else {
+if ((*line == ' ') || (*line == '\t')) {
+/* This line is a continuation of the previous
one */
+if (r-pending_header_line == NULL) {
+r-pending_header_line = line;
+r-pending_header_size = 0;
+}
+else {
+apr_size_t pending_len =
strlen(r-pending_header_line);
+apr_size_t fold_len = strlen(line);
This seems really expensive. You shouldn't need to recount
pending_len each time.
Good point; I'll add something to keep track of the length.
+}
+break;
If I understand your direction, it'd bail out here if it ever got
EAGAIN?
Yes indeed. That's what the version on the async-read-dev branch does.
+request_rec *ap_read_request(conn_rec *conn)
+{
+request_rec *r;
+apr_status_t rv;
+
+r = init_request(conn);
+
+rv = read_partial_request(r);
+/* TODO poll if EAGAIN */
+if (r-status != HTTP_OK) {
+ap_send_error_response(r, 0);
+ap_update_child_status(conn-sbh, SERVER_BUSY_LOG, r);
+ap_run_log_transaction(r);
+return NULL;
+}
Obviously, this can't be the case if you want to do real polling.
This would be the wrong place to poll. You have to exit out of
ap_read_request and go back up to an 'event thread' that waits
until there's data to read on any incoming sockets. Then, you'd
have to call ap_read_request again to 'restart' the parser whenever
there is more data to read.
In my opinion, this code isn't even close to being async.
I'm relieved to hear that it's not async, since you're looking at the
blocking
version. :-) See ap_read_async_request() (still on the async-read-
dev branch).
So, I wonder why it was even merged to trunk right now. You'd
have to deal with partial lines and the state the header parser is
in when it gets the next chunk of data - which this code doesn't
even try to do. The current code is just going to bail when it
doesn't have a 'complete' line.
My hunch is that you plan to build up pending_header_line and delay
parsing until you have the line terminators; but that's not going
to work really well with non-blocking sockets as you have to store
the data you just read
RE: RLimitCPU is not working
Title: RE: RLimitCPU is not working Does RLimitCPU limit CPU usage by putting a Setrlimit on the subsequent child processes ?? I cannot find the limits in utask.uu_rlmit[0] in proc. structure of the repective httpd processes. How is the time limited then ? I am keen to know how exactly it is implemented and how it limits CPU usage of httpd child process. Thanks, Rajesh R -- This space intentionally left non-blank -Original Message- From: Colm MacCarthaigh [mailto:[EMAIL PROTECTED]] Sent: Monday, January 02, 2006 5:28 PM To: dev@httpd.apache.org Subject: Re: RLimitCPU is not working On Mon, Jan 02, 2006 at 02:45:30PM +0530, R, Rajesh (STSD) wrote: The RlimitCPU directive is not limiting the cgi program's CPU usage to 2 seconds. The program keeps continuing forever. Are there any known issues or am I missing something ? Is this with mod_cgid? RlimitCPU doesn't work with cgid. -- Colm MacCárthaigh Public Key: [EMAIL PROTECTED]
Re: AW: AW: AW: 2.2 mod_http_proxy and partial pages
On 01/03/2006 03:52 AM, Justin Erenkrantz wrote: On Mon, Jan 02, 2006 at 10:18:19PM +0100, Ruediger Pluem wrote: [..cut..] 2. Proposal If a subrequest has a broken backend do not sent the error bucket. Only set r-no_cache to ensure that this subrequest response does not get cached. I think we still need to ensure that an error bucket is sent too, right? Otherwise, the connection will be reused - what am I missing? -- justin No, you are not missing anything. The question to me was: Do we need to close a keepalive on the main request just because a subrequest failed in the middle of the response? Or to be more precise: Should the behaviour to cut off the keepalive be the default behaviour in such cases with the chance for subrequest creators to remove the error bucket and to make the response cacheable again or should it be the other way round that the subrequest creator is reponsible for preventing caching and closing the keepalive by sending the error bucket by himself if he thinks that this is needed? While writing this I personally come to the conclusion that the 1. proposal (sending the error bucket) is saver as a default behaviour. Regards Rüdiger
Re: RLimitCPU is not working
On Tue, Jan 03, 2006 at 03:16:18PM +0530, R, Rajesh (STSD) wrote: Does RLimitCPU limit CPU usage by putting a Setrlimit on the subsequent child processes ?? When it works, yes. I cannot find the limits in utask.uu_rlmit[0] in proc. structure of the repective httpd processes. How is the time limited then ? I am keen to know how exactly it is implemented and how it limits CPU usage of httpd child process. The best way to do this is to read the source :) In the meantime, can you tell me are you using mod_cgid or mod_cgi? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
RE: RLimitCPU is not working
I was using mod_cgid. Later I disabled it and couldn't execute cgi program without it. In the directory /cgi-bin I gave options ExecCGI but I get the code being displayed every time I try to run the program from browser. Is there a way to run cgi without mod_cgid ??? Or does RLimitCPU work with mod_cgi ?? Rajesh R -- This space intentionally left non-blank. -Original Message- From: Colm MacCarthaigh [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 03, 2006 4:21 PM To: dev@httpd.apache.org Subject: Re: RLimitCPU is not working On Tue, Jan 03, 2006 at 03:16:18PM +0530, R, Rajesh (STSD) wrote: Does RLimitCPU limit CPU usage by putting a Setrlimit on the subsequent child processes ?? When it works, yes. I cannot find the limits in utask.uu_rlmit[0] in proc. structure of the repective httpd processes. How is the time limited then ? I am keen to know how exactly it is implemented and how it limits CPU usage of httpd child process. The best way to do this is to read the source :) In the meantime, can you tell me are you using mod_cgid or mod_cgi? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: RLimitCPU is not working
On Tue, Jan 03, 2006 at 04:27:01PM +0530, R, Rajesh (STSD) wrote: I was using mod_cgid. Later I disabled it and couldn't execute cgi program without it. The setrlimit calls have been commented out for mod_cgid for a long long time, so they don't take effect. A simple workaround is to use the shell ulimit built-in to change the limits in the init-script before httpd is executed. Standard Unix inheritance should take care of it after that. In the directory /cgi-bin I gave options ExecCGI but I get the code being displayed every time I try to run the program from browser. Is there a way to run cgi without mod_cgid ??? Or does RLimitCPU work with mod_cgi ?? Using ulimit is probably your best option. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
RE: RLimitCPU is not working
Point taken.Thanks. Is there any specific reason why setrlimit is disabled for mod_cgid ?? Rajesh R -- This space intentionally left non-blank. -Original Message- From: Colm MacCarthaigh [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 03, 2006 4:35 PM To: dev@httpd.apache.org Subject: Re: RLimitCPU is not working On Tue, Jan 03, 2006 at 04:27:01PM +0530, R, Rajesh (STSD) wrote: I was using mod_cgid. Later I disabled it and couldn't execute cgi program without it. The setrlimit calls have been commented out for mod_cgid for a long long time, so they don't take effect. A simple workaround is to use the shell ulimit built-in to change the limits in the init-script before httpd is executed. Standard Unix inheritance should take care of it after that. In the directory /cgi-bin I gave options ExecCGI but I get the code being displayed every time I try to run the program from browser. Is there a way to run cgi without mod_cgid ??? Or does RLimitCPU work with mod_cgi ?? Using ulimit is probably your best option. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: RLimitCPU is not working
On Tue, Jan 03, 2006 at 05:00:03PM +0530, R, Rajesh (STSD) wrote: Point taken.Thanks. Is there any specific reason why setrlimit is disabled for mod_cgid ?? Not that I know of, no. But they've been commented out from the very start, the very first incarnation of mod_cgid was done that way. Fixing it might cause more instability than the absense ever created, but it's worth a look. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: svn commit: r365376 - /httpd/httpd/branches/fcgi-proxy-dev/modules/proxy/mod_proxy_fcgi.c
Garrett Rooney wrote: On 1/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jim Date: Mon Jan 2 08:52:58 2006 New Revision: 365376 URL: http://svn.apache.org/viewcvs?rev=3D365376view=3Drev Log: Avoid magic numbers. Since we are reading the header, let's be explicit about it. Also removes the need to clean up the readbuf again, and any potential for confusion on what we are doing ;) Um, doesn't this assume that there's no padding in the compiler's layout of the struct? Is that safe to do? I've always been under the impression that relying on such things is not portable. If nothing else we should probably have a compile time check that it's size =3D=3D 8, or something... I'm fine with removing the use of sizeof and sticking with '8', since it's a defined value in the FCGI protocol itself. But we use sizeof header in loads of other places there as well... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: mod_proxy, another case of ignoring the filter stack?
Sander Striker wrote: Ok, let me tell you why I want it. I want to implement a directive called CacheErrorServeStale, which, when it hits the CACHE_SAVE filter say with a 503 Service Temporarily Unavailable, and has a cache-stale_handle, continues as if it would have received a 304 Not Modified. That's one use of the request_status hook in mod_proxy. If mod_cache registered a handler for it, it could handle all instances where the proxy fails. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
RE: Apache 2.2.0 Listen Directive
Nothing is output by running ./apachectl start. The access_log and
error_log files are created, but do not contain anything. Running
./httpd output the following:
bash-2.05b$ ./httpd
httpd: Could not reliably determine the server's fully qualified domain
name, using 132.253.10.58 for ServerName
no listening sockets available, shutting down
Unable to open logs
I'll try to make time to try your patch, but I don't think I'll be able
to get to it right away.
,
Josh.
-Original Message-
From: Jeff Trawick [mailto:[EMAIL PROTECTED]
Sent: Friday, December 30, 2005 9:43 AM
To: dev@httpd.apache.org
Subject: Re: Apache 2.2.0 Listen Directive
On 12/28/05, Jeff Trawick [EMAIL PROTECTED] wrote:
On 12/28/05, Fenlason, Josh [EMAIL PROTECTED] wrote:
I'm running into an issue where Apache 2.2.0 on AIX won't
start if
there is more than one Listen directive.
Can you send me truss of startup using the failure configuration?
truss -o /tmp/startup -f bin/apachectl start
(trace received offline)
I don't see any socket errors. I jumped more than half-way
to a conclusion from your initial report (won't start) and
assumed that some sort of bind error occurred. It seems
somewhat likely that a crash is occurring, though I don't see
SIGSEGV being reported in the trace. Anything written to the
console by apachectl start? What is exit status of
apachectl start in the failure?
# bin/apachectl start
# echo $?
Anything written to error log?
AIX 5.1 doesn't have IPV6_V6ONLY socket option (added in
5.2), which does affect processing of sockets. Can you try this hack?
Index: server/listen.c
===
--- server/listen.c (revision 360100)
+++ server/listen.c (working copy)
@@ -408,11 +408,8 @@
if (previous != NULL
IS_INADDR_ANY(lr-bind_addr)
lr-bind_addr-port == previous-bind_addr-port
- IS_IN6ADDR_ANY(previous-bind_addr)
- apr_socket_opt_get(previous-sd, APR_IPV6_V6ONLY,
- v6only_setting) == APR_SUCCESS
- v6only_setting == 0) {
-
+ IS_IN6ADDR_ANY(previous-bind_addr)) {
+/* hacked to ignore IPV6_V6ONLY setting */
/* Remove the current listener from the list */
previous-next = lr-next;
continue;
Re: A Bloat of Libraries
Nick Kew wrote: How about modularised dependencies as a goal for 2.4? I agree with the idea, but I don't really think theres that manu libraries linked in... I've got a 2.0.55 with mp2, php4, ssl, ruby, python, mod_log_sql using a slew of config IfDevines, each server runs only what it needs. httpd.ssl: libz.so.3 = /lib/libz.so.3 (0x280b6000) libssl.so.4 = /usr/lib/libssl.so.4 (0x280c6000) libcrypto.so.4 = /lib/libcrypto.so.4 (0x280f4000) libaprutil-0.so.9 = /usr/local/lib/apache2/libaprutil-0.so.9 (0x281e6000) libldap-2.2.so.7 = /usr/local/lib/libldap-2.2.so.7 (0x281f8000) liblber-2.2.so.7 = /usr/local/lib/liblber-2.2.so.7 (0x28225000) libdb4.so.0 = /usr/local/lib/libdb4.so.0 (0x28231000) libexpat.so.5 = /usr/local/lib/libexpat.so.5 (0x282b7000) libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x282d5000) libapr-0.so.9 = /usr/local/lib/apache2/libapr-0.so.9 (0x283c2000) libm.so.4 = /lib/libm.so.4 (0x283dc000) libcrypt.so.3 = /lib/libcrypt.so.3 (0x283f2000) libc.so.6 = /lib/libc.so.6 (0x2840a000) libsasl2.so.2 = /usr/local/lib/libsasl2.so.2 (0x284e1000) Love is not the one you can picture yourself marrying, but the one you can't picture the rest of your life without. It takes a minute to have a crush on someone, an hour to like someone, and a day to love someone, but it takes a lifetime to forget someone... Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com
Re: A Bloat of Libraries
Nick Kew wrote: Amongst modules, we should apply the same principle: e.g. with mod_deflate and zlib. Or why not just have mod_deflate link against zlib and not have httpd do it. SSL seems to be the worst culprit. httpd gets linked against tons of stuff so that I cannot copy the binary to a non-ssl enabled host. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: svn commit: r365376 - /httpd/httpd/branches/fcgi-proxy-dev/modules/proxy/mod_proxy_fcgi.c
On 1/3/06, Jim Jagielski [EMAIL PROTECTED] wrote: Garrett Rooney wrote: On 1/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: jim Date: Mon Jan 2 08:52:58 2006 New Revision: 365376 URL: http://svn.apache.org/viewcvs?rev=3D365376view=3Drev Log: Avoid magic numbers. Since we are reading the header, let's be explicit about it. Also removes the need to clean up the readbuf again, and any potential for confusion on what we are doing ;) Um, doesn't this assume that there's no padding in the compiler's layout of the struct? Is that safe to do? I've always been under the impression that relying on such things is not portable. If nothing else we should probably have a compile time check that it's size =3D=3D 8, or something... I'm fine with removing the use of sizeof and sticking with '8', since it's a defined value in the FCGI protocol itself. But we use sizeof header in loads of other places there as well... The problem isn't just the number of bytes we read off the wire, it's also that if the compiler has introduced padding between elements of the struct when you recv directly into the struct the data is not aligned with the proper members, so when you later access it you get the wrong values. As for other places we're using sizeof(header), I didn't write those places, so I can't be sure without some more investigation, but they've potentially got the same problem. -garrett
Re: svn commit: r365376 - /httpd/httpd/branches/fcgi-proxy-dev/modules/proxy/mod_proxy_fcgi.c
Garrett Rooney wrote: The problem isn't just the number of bytes we read off the wire, it's also that if the compiler has introduced padding between elements of the struct when you recv directly into the struct the data is not aligned with the proper members, so when you later access it you get the wrong values. IIRC, since we are using chars, and no bit fields, any padding that would be done would only be to tile the struct into an array. Since we already tile into a 8byte/char array, no padding is done. If we have padding *between* elements then we are royally screwed, but the FCGI header struct was created (again, iirc) specifically so that we're byte stream oriented. In any case, I think it's safer to avoid the use of sizeof in those places where we are sending protocol information. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: svn commit: r360461 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/httpd.h server/protocol.c
On 1/3/06, Brian Pane [EMAIL PROTECTED] wrote: Yeah, setting r-status to HTTP_OK is done here solely to make it work with the existing logic about HTTP_REQUEST_TIME_OUT meaning still reading the request header. +1 for of removing the HTTP_REQUEST_TIME_OUT hack. I was trying to be conservative by preserving that part of the original logic, but now that you mention it, we might as well replace it with something less subtle in 2.3. This will break any 3rd party modules that depend upon the HTTP_REQUEST_TIME_OUT convention, but for a major release like 2.4 or 3.0 that's a defensible choice. +1. I'm relieved to hear that it's not async, since you're looking at the blocking version. :-) See ap_read_async_request() (still on the async-read- dev branch). AFAICT, ap_read_async_request() on the branch can't handle a partial line correctly. Noting of course that ap_core_input_filter is 'cute' and masks EAGAIN. So, you'll never see EAGAIN from this code path! As I said earlier, the EAGAIN logic in httpd is completely suspect. Furthermore, as I read it, ap_read_async_request is assuming that it gets a complete line from getline_nonblocking - which almost certainly won't be the case. -- justin
Re: AW: AW: AW: 2.2 mod_http_proxy and partial pages
On 1/3/06, Ruediger Pluem [EMAIL PROTECTED] wrote: 2. Proposal If a subrequest has a broken backend do not sent the error bucket. Only set r-no_cache to ensure that this subrequest response does not get cached. I think we still need to ensure that an error bucket is sent too, right? Otherwise, the connection will be reused - what am I missing? -- justin No, you are not missing anything. The question to me was: Do we need to close a keepalive on the main request just because a subrequest failed in the middle of the response? Or to be more precise: Should the behaviour to cut off the keepalive be the default behaviour in such cases with the chance for subrequest creators to remove the error bucket and to make the response cacheable again or should it be the other way round that the subrequest creator is reponsible for preventing caching and closing the keepalive by sending the error bucket by himself if he thinks that this is needed? While writing this I personally come to the conclusion that the 1. proposal (sending the error bucket) is saver as a default behaviour. Oh, I didn't realize you intended it as an either/or scenario. Then, yes, I agree that #1 is correct. =) -- justin
Re: AW: AW: AW: 2.2 mod_http_proxy and partial pages
On Jan 2, 2006, at 4:18 PM, Ruediger Pluem wrote: 1. Proposal If a subrequest has a broken backend also set r-no_cache for the main request and ensure that the chunk filter does not sent the last chunk marker in this case. 2. Proposal If a subrequest has a broken backend do not sent the error bucket. Only set r-no_cache to ensure that this subrequest response does not get cached. Proposal #1
Re: svn commit: r360461 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/httpd.h server/protocol.c
On Jan 3, 2006, at 12:02 AM, William A. Rowe, Jr. wrote: Roy T. Fielding wrote: On Jan 2, 2006, at 2:14 PM, Roy T. Fielding wrote: Now, if you want to tell me that those changes produced a net performance benefit on prefork (and thus are applicable to other MPMs), then I am all ears. I am easily convinced by comparative performance figures when the comparison is meaningful. lol, of course you choose the non-threaded MPM as a reference, which therefore should receive no meaningful performance change. The difference between an async wakeup and a poll result should be null for one socket pool, one process, one thread (of course select is a differently ugly beast, and if there were a platform that supported async with no poll, I'd laugh.) You seem to misunderstand me -- if I compare two prefork servers, one with the change and one without the change, and the one with the change performs better (by whatever various measures of performance you can test), then that is an argument for making the change regardless of the other concerns. If, instead, you say that the change improves the event MPM by 10% and degrades performance on prefork by 1%, then I am -1 on that change. Prefork is our workhorse MPM. The task then is to isolate MPM-specific changes so that they have no significant impact on the critical path of our primary MPM, even if that means using #ifdefs. Alternatively, rewrite the server to remove all MPMs other than event and then show that the new server is better than our existing server, and we can adopt that for 3.0. BTW, part of the reason I say that is because I have considered replacing the same code with something that doesn't parse the header fields until the request header/body separator line is seen, since that would allow the entire request header to be parsed in-place for the common case. Well ... you are using protocol knowledge that will render us http- bound when it comes time to efficently bind waka (no crlf delims in a binary format protocol, no?) or ftp (pushes a 'greeting' before going back to sleep.) Well, I am assuming that the MIME header parsing code is in the protocol-specific part of the server, yes. Roy
Re: mod_proxy, another case of ignoring the filter stack?
Brian Akins wrote: Sander Striker wrote: Ok, let me tell you why I want it. I want to implement a directive called CacheErrorServeStale, which, when it hits the CACHE_SAVE filter say with a 503 Service Temporarily Unavailable, and has a cache-stale_handle, continues as if it would have received a 304 Not Modified. That's one use of the request_status hook in mod_proxy. If mod_cache registered a handler for it, it could handle all instances where the proxy fails. No, mod_cache doesn't have to know what the origin is. It can be anything from a custom handler, a cgi, etc. This list happens to include mod_proxy, but I don't think we need to handle mod_proxy any differently. Rudigers suggestion of pushing an error bucket down the filter stack seems the best solution, which I'm working on implementing. Sander
Re: A Bloat of Libraries
--On January 3, 2006 10:18:06 AM -0500 Brian Akins [EMAIL PROTECTED] wrote: Nick Kew wrote: Amongst modules, we should apply the same principle: e.g. with mod_deflate and zlib. Or why not just have mod_deflate link against zlib and not have httpd do it. SSL seems to be the worst culprit. httpd gets linked against tons of stuff so that I cannot copy the binary to a non-ssl enabled host. Nice idea, but libtool doesn't support any of this in a portable manner - some OSes support DSOs having their own dependencies, a number just don't. If you want to completely rip apart libtool and write your own, feel free. Been there, done that, got the t-shirt. -- justin
Re: A Bloat of Libraries
On Tuesday 03 January 2006 15:18, Brian Akins wrote: Nick Kew wrote: Amongst modules, we should apply the same principle: e.g. with mod_deflate and zlib. Or why not just have mod_deflate link against zlib and not have httpd do it. It does that now - if built from ./configure. That gets confusing - and has potential for segfaults - when there's some other module or library that needs zlib. Indeed, it's worse than that. Here's after a configure+make: $ ldd .libs/mod_deflate.so linux-gate.so.1 = (0xe000) libz.so.1 = /lib/libz.so.1 (0xb7fc9000) libpthread.so.0 = /lib/libpthread.so.0 (0xb7f76000) libc.so.6 = /lib/libc.so.6 (0xb7e5e000) /lib/ld-linux.so.2 (0x8000) $ apxs -c mod_deflate.c [chop] $ ldd .libs/mod_deflate.so linux-gate.so.1 = (0xe000) libc.so.6 = /lib/libc.so.6 (0xb7ec1000) /lib/ld-linux.so.2 (0x8000) That's a difference of *two* libs! Since libz isn't linked in httpd, we get: # apxs -i mod_deflate.la [chop] # apachectl configtest httpd: Syntax error on line 263 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache2/modules/mod_deflate.so into server: /usr/local/apache2/modules/mod_deflate.so: undefined symbol: deflate Ouch! That is of course resolved by LoadFile /lib/libz.so, which is what I contend should be standard practice. So when another module relies on libz, there's no side effect that manifests mysteriously according to whether and when mod_deflate is loaded. SSL seems to be the worst culprit. httpd gets linked against tons of stuff so that I cannot copy the binary to a non-ssl enabled host. Indeed. That principle applies equally to SQL client libs for DBD, to DBM libs, and somewhat even to things like expat. -- Nick Kew
Re: A Bloat of Libraries
On Tuesday 03 January 2006 15:13, Philip M. Gollucci wrote: Nick Kew wrote: How about modularised dependencies as a goal for 2.4? I agree with the idea, but I don't really think theres that manu libraries linked in... I've got a 2.0.55 with mp2, php4, ssl, ruby, python, mod_log_sql using a slew of config IfDevines, each server runs only what it needs. httpd.ssl: libz.so.3 = /lib/libz.so.3 (0x280b6000) libssl.so.4 = /usr/lib/libssl.so.4 (0x280c6000) libcrypto.so.4 = /lib/libcrypto.so.4 (0x280f4000) Why do any of those have to be linked rather than loaded? libaprutil-0.so.9 = /usr/local/lib/apache2/libaprutil-0.so.9 (0x281e6000) OK, that's pretty integral to it. libldap-2.2.so.7 = /usr/local/lib/libldap-2.2.so.7 (0x281f8000) liblber-2.2.so.7 = /usr/local/lib/liblber-2.2.so.7 (0x28225000) libdb4.so.0 = /usr/local/lib/libdb4.so.0 (0x28231000) Again, LoadFile them! libexpat.so.5 = /usr/local/lib/libexpat.so.5 (0x282b7000) libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x282d5000) Borderline cases I guess ... libapr-0.so.9 = /usr/local/lib/apache2/libapr-0.so.9 (0x283c2000) OK, we need apr_dso linked in:-) libm.so.4 = /lib/libm.so.4 (0x283dc000) libcrypt.so.3 = /lib/libcrypt.so.3 (0x283f2000) libc.so.6 = /lib/libc.so.6 (0x2840a000) libsasl2.so.2 = /usr/local/lib/libsasl2.so.2 (0x284e1000) Libsasl is surely another LoadFile. And maybe libcrypt. -- Nick Kew
Re: A Bloat of Libraries
--On January 3, 2006 11:09:34 PM + Nick Kew [EMAIL PROTECTED] wrote: That is of course resolved by LoadFile /lib/libz.so, which is what I contend should be standard practice. So when another module relies on libz, there's no side effect that manifests mysteriously according to whether and when mod_deflate is loaded. I strongly disagree. Forcing the user to manually track all of the library dependencies is insane. If someone wants to shoot themselves in the foot, fine - you can do it. But, we shouldn't force everyone to fit your preferred model because you want a few less libraries. Again, there are substantial libtool issues that come into play that limit what we can realistically do. SSL seems to be the worst culprit. httpd gets linked against tons of stuff so that I cannot copy the binary to a non-ssl enabled host. Indeed. That principle applies equally to SQL client libs for DBD, to DBM libs, and somewhat even to things like expat. Expat is brought in by apr-util, so you'd have to add dynamic loading of expat to apr-util. In my opinion, it's a maze of twisty passages that isn't worth the payoff. -- justin
Re: A Bloat of Libraries
Brian Akins wrote: Nick Kew wrote: Amongst modules, we should apply the same principle: e.g. with mod_deflate and zlib. Or why not just have mod_deflate link against zlib and not have httpd do it. SSL seems to be the worst culprit. httpd gets linked against tons of stuff so that I cannot copy the binary to a non-ssl enabled host. That's what I do, I'll submit a patch shortly. Similarly with other .so's, my httpd 2.0 build links the ldap provider to mod_ldap/mod_auth_ldap, by querying apr-util (which my 0.9 flavor splits the ldflags between core, and added dependencies against ldap). My issue, none of this works anymore in 2.2 because libaprutil.so now needs to bind directly to libldap/liblber :( Bill
Re: svn commit: r360461 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/httpd.h server/protocol.c
Roy T. Fielding wrote: Alternatively, rewrite the server to remove all MPMs other than event and then show that the new server is better than our existing server, and we can adopt that for 3.0. Well that's a bit silly, leave the others for those who must have an entirely non-threaded server or other options; but prove that event is more performant and quite stable for all platforms, if they would only take the time to use threaded-compatible 3rd party modules, then make event the default 3.0 mpm... Now that's a metric I'll buy. Bill
Re: A Bloat of Libraries
Justin Erenkrantz wrote: Nice idea, but libtool doesn't support any of this in a portable manner - some OSes support DSOs having their own dependencies, a number just don't. Name a few? Or one?
Re: A Bloat of Libraries
On Wed, Jan 04, 2006 at 12:12:18AM -0600, William A. Rowe, Jr. wrote: Justin Erenkrantz wrote: Nice idea, but libtool doesn't support any of this in a portable manner - some OSes support DSOs having their own dependencies, a number just don't. Name a few? Or one? In my experience, most versions of GNU libtool don't do the right thing for inter-library dependencies on Solaris or Darwin. (I've seen it barf on Linux once or twice too.) On those platforms, it may not link the dependency into the DSO and forces the main binary to link against the DSO dependency when the main binary links to the first DSO's .la file. In short, it'll usually disregard your 'cleverness' and link the binary to all of the implicit dependencies anyway. However, in certain circumstances, libtool will just fall over and screw the linking process up entirely. Subversion relies upon this working in a few cases and occassionally gets really weird error reports that have to do with libtool screwing this step up. If you *really* want to go make this work, be prepared to toss GNU libtool and spend a lot of time working on a replacement to get platform parity with GNU libtool. I think that's a really poor idea (having written a libtool-replacement myself). -- justin
