Re: perchild on FreeBSD 5?
"Pier Fumagalli" <[EMAIL PROTECTED]> wrote: > If your problem is thread safety, use PREFORK, it works allright, and AFAICS > (from my tests and my experience, I don't want to push my results as "global", > PREFORK works at least as good as the old 1.3. Yeah, but if you need to use mod_perl at all you're using a whole lot of alpha code if you use Apache 2.0, even with the prefork mpm... not exactly something you want to let a lot of revenue ride on if you make much money through your web site. The problem isn't that Apache itself is too early to upgrade, but rather that mod_perl is for many people, so if those people depend at all on mod_perl then they must not upgrade to apache 2.0 yet! A similar situation exists with mod_php. I'm still on the fence as to the original comment that apache should say something in the release notes: on the one hand this mod_perl/mod_php being behind issue does affect a tremendous number of people, but on the other hand it's really a third party module dependancy problem not an apache core issue at all. I guess because of the large number of people it affects it could be considered courtesy to at least say something even though technically it's "not our problem" so to speak... ;o) Dave
RE: perchild on FreeBSD 5?
> > Apache 2 is being pitched as a production-quality web server without any > > mention of the fact that over half of the current Apache sites probably > > should not upgrade at this point. > > Sorry to disagree, Rasmus, but if you're talking about PERCHILD, that's a > threaded MPM that will not solve your problem with those libraries used by > PHP which are not thread safe. > > If your problem is thread safety, use PREFORK, it works allright, and AFAICS > (from my tests and my experience, I don't want to push my results as "global", > PREFORK works at least as good as the old 1.3. > > Plus 2.0 has WORKER, that for less-than-half of this planet is, IMVHO, a > great improvement over the old 1.3 when thread safety is not a problem. > > So, what's your point? Apache 2.0 _already_ delivers, for what I can see and > experience on my silly little websites doing several millions hits/day. It can > be used AS 1.3, _and_ it has something extra. > > I really don't see your point... My point is that people blindly install the latest stable PHP with the latest stable Apache and they end up something that is not stable at all. They don't understand what an MPM is, much less which MPM to use for what. The troublesome part here is that this is actually more than half of all the current Apache users that will end up getting bitten if they blindly upgrade. Nowhere in the release notes do we warn people that things are likely to break if they choose a threaded MPM and have PHP and/or mod_perl. -Rasmus
Re: cache_pq in right order??
On Tue, 13 Aug 2002, Cliff Woolley wrote: > I have reason to believe that the cache_pq code isn't working quite right. > I'm not sure why yet (and for all I know it's my fault since I touched > that code last). Just wanted to give you guys a heads-up. Well, the good news is that the PQ seems to be in working order. The main bug was a single missing minus sign in *my* code (not the PQ). Sheeeiitt. Turns out, though, that the main reason the bug snuck in was because of the funky API of change_priority(), which I'll probably change soonish. Anyway, I'm pretty confident in the PQ code at this point. :) I still need to test the remove() function and I need to make sure I didn't break its iteraction with cache_cache.c in some unexpected way, but I don't forsee any major problems. I'll clean up the bits tomorrow. --Cliff
Re: Re[2]: perchild on FreeBSD 5?
On Tue, Aug 13, 2002 at 02:11:08PM -0400, Ryan Bloom wrote: > well. If I can't make it work on my BSD machine (because it is FreeBSD), > then I will most likely need an account on a Net or Open BSD box. We got NetBSD installed on one of our machines (dodo.betaversion.org)... It should be in line this week-end. Let me know if you need access. Pier (playing with OSes)
RE: perchild on FreeBSD 5?
Quoting Rasmus Lerdorf <[EMAIL PROTECTED]>: > Apache 2 is being pitched as a production-quality web server without any > mention of the fact that over half of the current Apache sites probably > should not upgrade at this point. Sorry to disagree, Rasmus, but if you're talking about PERCHILD, that's a threaded MPM that will not solve your problem with those libraries used by PHP which are not thread safe. If your problem is thread safety, use PREFORK, it works allright, and AFAICS (from my tests and my experience, I don't want to push my results as "global", PREFORK works at least as good as the old 1.3. Plus 2.0 has WORKER, that for less-than-half of this planet is, IMVHO, a great improvement over the old 1.3 when thread safety is not a problem. So, what's your point? Apache 2.0 _already_ delivers, for what I can see and experience on my silly little websites doing several millions hits/day. It can be used AS 1.3, _and_ it has something extra. I really don't see your point... Pier (2.0 enthusiast!)
Re: cvs commit: httpd-2.0/modules/experimental cache_pqueue.ccache_pqueue.h
On 14 Aug 2002 [EMAIL PROTECTED] wrote:
>void *cache_pq_pop(cache_pqueue_t *q)
>{
> -void *tmp;
> -void *d;
> -int i = 1;
> -int j;
> +void *head;
>
>if (!q || q->size == 1)
>return NULL;
>
> -d = q->d[1];
> -tmp = q->d[--q->size];
> -while (i <= q->size / 2) {
> -j = 2 * i;
> -if (j < q->size && q->pri(q->d[j]) < q->pri(q->d[j + 1])) {
> -j++;
> -}
> -if (q->pri(q->d[j]) <= q->pri(tmp)) {
> -break;
> -}
> -q->d[i] = q->d[j];
> -q->set(q->d[i], i);
> -i = j;
> -}
> -q->d[i] = tmp;
> -q->set(q->d[i], i);
> -return d;
> +head = q->d[1];
> +q->d[1] = q->d[--q->size];
> +cache_pq_percolate_down(q, 1);
> +
> +return head;
>}
Oops! This part wasn't supposed to go in this commit. It should be a
valid change, but I haven't tested it yet. Will do that now.
--Cliff
Re: HTTP headers on 'trailing slash' redirects?
>> Seems to me that a URL pointing to a directory always has to end with a >> slash, and therefor it is permanent. Why would it be temporary? > > Hmm... I'm not entirely sure, to be honest. I wouldn't really > consider myself experienced in any way with the inner workings of web > servers. > However. > It does strike me that the object could concievably change between > being a directory and being a file, for example, meaning that a cached > redirect (Which is what seems to happen with a permanent redirect) is > an annoyance. The object is not relevant -- the original request is to a bad URL. The server should return a 404, but for reasons of "typical user error" it returns a permanent redirect instead in the hope that the goobers will fix their link. > Also, it appears that IIS (at least 5.0, which I've tested for this) > and Apache 1.2b8 (from that changelog I found) do respond with a 302 > (temporary redirect). I'm wondering why the current Apache's behaviour > is different, that's all. Because we corrected the prior behavior inherited from NCSA httpd to be more conformant to the HTTP standard. > Also, is there any way to persuade apache to do this right with > mod_rewrite? You can persuade mod_rewrite to do most anything, whether it is right or wrong. However, it is categorically insane to insist that the user agent always perform an unnecessary redirect just because some goofball thinks the URL looks better without a slash on the end. That is bad for the server and bad for the Internet in general. Roy
Re: Why can't ap_send_error_response() count on charset?
On Tue, 13 Aug 2002, Roy T. Fielding wrote: > Someone could try adding the meta tag to the HTML output instead of > on the content-type, but then they would have to check to see if this > still reduces the cross-site scripting problems that Marc found earlier. My recollection (I would have to check my notes to be sure) is that it is not sufficient to put it as a meta tag to attempt to protect from charset related cross site scripting attacks because it can be overidden. In fact, the exact browser bug that this thread is trying to work around (redirect with an explicit encoding in the HTTP headers results in that encoding being used for the target of the redirect instead of anything specified in a meta tag in that document) is one good example of why setting it in the meta tag ourself wouldn't be sufficient to avoid charset related cross site scripting attacks on browsers with this bug... since the attacker site could just set one in their HTTP headers.
cache_pq in right order??
I have reason to believe that the cache_pq code isn't working quite right. I'm not sure why yet (and for all I know it's my fault since I touched that code last). Just wanted to give you guys a heads-up. Basically it's just popping things in not quite the right order. For example: popped value = -1.305 followed by a cache_pq_dump(): posnleftright parent minchild... 1 2 3 0 3 (-1.305/1) 2 4 5 1 4 (-1.305/2) 3 6 7 1 7 (-1.305/3) 4 8 9 2 8 (-1.305/4) 5 10 11 2 10 (-1.305/5) 6 12 13 3 13 (-1.305/6) 7 14 15 3 14 (-1.305/7) 8 16 17 4 17 (-1.305/8) 9 18 19 4 19 (-1.305/9) 10 20 21 5 20 (-1.419/10) 11 22 23 5 22 (-1.430/11) 12 24 25 6 24 (-1.459/12) 13 26 27 6 27 (-1.305/13) 14 28 29 7 28 (-1.305/14) 15 30 31 7 31 (-1.305/15) 16 32 33 8 33 (-1.305/16) 17 34 35 8 34 (-1.305/17) 18 36 37 9 36 (-3.260/18) 19 38 39 9 38 (-1.374/19) 20 40 41 10 41 (-1.449/20) 21 42 43 10 43 (-1.854/21) 22 44 45 11 44 (-1.683/22) 23 46 47 11 46 (-2.396/23) 24 48 49 12 48 (-1.591/24) 25 50 51 12 51 (-1.597/25) 26 52 53 13 53 (-1.683/26) 27 54 55 13 55 (-1.305/27) 28 56 57 14 56 (-1.305/28) 29 58 59 14 59 (-2.001/29) 30 60 61 15 61 (-1.421/30) 31 62 63 15 63 (-1.305/31) 32 64 65 16 64 (-1.459/32) 33 66 67 16 67 (-1.374/33) 34 68 69 17 68 (-1.305/34) 35 70 71 17 70 (-1.378/35) 36 72 73 18 73 (-1.448/36) 37 74 75 18 75 (-1.449/37) 38 76 77 19 76 (-1.683/38) 39 78 79 19 78 (-1.683/39) 40 80 81 20 80 (-1.509/40) 41 82 83 20 83 (-1.459/41) 42 84 85 21 84 (-1.261/42) 43 86 87 21 87 (-1.130/43) 44 88 89 22 88 (-1.261/44) [snip] There are many more entries in this particular PQ, but what's here is enough to see the problem. I popped the top value which was -1.305 and then immediately dumped the rest of the PQ. You can clearly see that of the entries shown here, -1.130 should have been the thing popped, not -1.305. It's moderately likely that the bug is in the change_priority function, as I have a test program that inserts and then removes a set of values, and that works fine. More details as I figure out what's up. --Cliff
Re: Why can't ap_send_error_response() count on charset?
>> Can you try it again with current cvs HEAD? I'm not familiar with the >> W3C >> Validator test, but I would hope that if it saw a good http Content-Type >> header, >> it wouldn't need the stuff in the html meta line. > > Me too but I found a problem/feature due to the validator so I just wrote > the > following email to the w3c validator team: Just turn off the validator feature for detecting charset through the META tag. That check is bogus anyway and the W3C knows it. The charset of the error documents is iso-8859-1, which is the default for HTTP. Someone could try adding the meta tag to the HTML output instead of on the content-type, but then they would have to check to see if this still reduces the cross-site scripting problems that Marc found earlier. Roy
Patch to enable large file support in APR
The following patch and file allows for the detection and use of POSIX large file implentations that exist in most modern OSes. "Large files" refers to files that are greater than 2GB in size. Without LF support, a program will typically crash or otherwise fail if an attempt is made to open or write/read to a file (or memeory-mapped region) that is over 2GB in size. In terms of Apache, this allows log files to grow beyond 2GB, as well as the ability to serve files that are > 2GB. *Possible* Caveat: Attempting to serve a large file over a SSL connection can possibly fail. This is not the fault of Apache or APR, but with the OpenSSL routines that Apache uses to manage SSL connections. A work-around is to recompile OpenSSL with large file support, or to serve the content via a non-SSL connetion if possible. I havnt had the time to test this theory, but I ran into it while benchmarking OpenSSH (which uses OpenSSL) not too long ago. The fix there as to recompile OpenSSL with LF support. I gather the situation would be the same here, too. If anyone has a chance to give this a whirl, let me or the list know. Anyhow, the patch to apr/configure.in and a new file, apr/build/apr_largefile.m4 are attached. /dale Index: apr/configure.in === RCS file: /home/cvspublic/apr/configure.in,v retrieving revision 1.474 diff -u -r1.474 configure.in --- apr/configure.in5 Aug 2002 09:28:24 - 1.474 +++ apr/configure.in13 Aug 2002 22:13:19 - @@ -14,6 +14,7 @@ sinclude(build/apr_common.m4) sinclude(build/apr_network.m4) sinclude(build/apr_threads.m4) +sinclude(build/apr_largefile.m4) sinclude(build/apr_hints.m4) sinclude(build/libtool.m4) @@ -299,6 +300,26 @@ APR_SETVAR(AR,ar) ;; esac + +dnl Disable largefiles on OSes that support largefiles. +dnl Largefiles is enabled by default +AC_ARG_ENABLE(largefiles, +[ --disable-largefilesDisable support for large (>2GB) files], +[ +if test "$enableval" = "no"; then +user_disabled_largefiles=1 +fi ], +[ +user_disabled_largefiles=0 +]) + +AC_MSG_CHECKING(whether to enable large file support) +if test "$user_disabled_largefiles" = 1; then +AC_MSG_RESULT(no -- disabled by user) +else +AC_MSG_RESULT(yes -- determining needed flags...) +APR_SYS_LARGEFILE +fi dnl force_atomic_generic flag dnl this will be set we find a cpu/OS combo dnl By default, many hosts won't let programs access large files; dnl one must use special compiler options to get large-file access to work. dnl For more details about this brain damage please see: dnl http://www.sas.com/standards/large.file/x_open.20Mar96.html dnl Written by Paul Eggert <[EMAIL PROTECTED]>. dnl (Modified to not collide with autoconf 2.50+'s AC_SYS_LARGEFILE) dnl Modified by Dale Ghent <[EMAIL PROTECTED]> dnl for a better fit into the APR autoconf adventure. dnl Internal subroutine of APR_SYS_LARGEFILE. dnl APR_SYS_LARGEFILE_TEST_INCLUDES AC_DEFUN(APR_SYS_LARGEFILE_TEST_INCLUDES, [[#include /* Check that off_t can represent 2**63 - 1 correctly. We can't simply "#define LARGE_OFF_T 9223372036854775807", since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ # define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; ]]) dnl Internal subroutine of APR_SYS_LARGEFILE. dnl APR_SYS_LARGEFILE_MACRO_VALUE(C-MACRO, VALUE, CACHE-VAR, COMMENT, INCLUDES, FUNCTION-BODY) AC_DEFUN(APR_SYS_LARGEFILE_MACRO_VALUE, [AC_CACHE_CHECK([for $1 value needed for large files], $3, [$3=no AC_TRY_COMPILE([$5], [$6], , [AC_TRY_COMPILE([#define $1 $2] [$5] , [$6], [$3=$2])])]) if test "[$]$3" != no; then APR_ADDTO(CPPFLAGS, [-D$1=$2]) fi]) AC_DEFUN(APR_SYS_LARGEFILE, [AC_REQUIRE([AC_PROG_CC]) AC_CACHE_CHECK([for special C compiler options needed for large files], ac_cv_sys_largefile_CC, [ac_cv_sys_largefile_CC=no if test "$GCC" != yes; then # IRIX 6.2 and later do not support large files by default, # so use the C compiler's -n32 option if that helps. AC_TRY_COMPILE(APR_SYS_LARGEFILE_TEST_INCLUDES, , , [ac_save_CC="$CC" CC="$CC -n32" AC_TRY_COMPILE(APR_SYS_LARGEFILE_TEST_INCLUDES, , ac_cv_sys_largefile_CC=' -n32') CC="$ac_save_CC"]) fi]) if test "$ac_cv_sys_largefile_CC" != no; then CC="$CC$ac_cv_sys_largefile_CC" fi APR_SYS_LARGEFILE_MACRO_VALUE(_FILE_OFFSET_BITS, 64, ac_cv_sys_file_offset_bits, [Number of bits in a file offset, on hosts w
help with input filters
I was wondering if someone could give me a hand with input filters. I tried to write my own filter (CONNECTION), but ap_get_brigade never came back with APR_SUCCESS. Why? I then tried using mod_case_filter_in. In this case, ap_get_brigade returned APR_SUCCESS twice (for one request), but both time the bucket was the EOS bucket. The third time (for the same request), ap_get_brigade failed. Needless to say, the content was not modified. Yet, I tried the ssl module, and there ap_get_brigade worked fine (proven both by attaching to a debugger, and sniffing the network traffic). Can someone tell me what I need to do in order to get the request from an input filter. Thanks --- Aryeh Katz VASCO www.vasco.com
Re: AllowOverride - Doc bug vs. Code bug
* Brad Nicholes wrote:
> Could somebody clarify this? The documentation for AllowOverride
> states that the default for the directive is "AllowOverride All".
That's right as far I can see.
> But if you add an alias to a directory and do not include a ..> block for the aliased directory or if you simply exclude the
> AllowOverride directive from the block, Apache will
> ignore the .htaccess file even if it exists.
ehm...sorry,
maybe you forgot to remove the default
AllowOverride None
container...?
> The default in create_core_dir_config() is to set the override field
> to OR_UNSET.
huh?
conf->override = dir ? OR_UNSET : OR_UNSET|OR_ALL;
nd
--
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;
# André Malo # http://www.perlig.de #
RE: Re: Apache dies on large error_log (possible remote DoS)
The problem is not that the log file consumes all disk space, it's that httpd terminates (the parent process, and all children) when the log file reaches 2GB. Supporting LARGEFILE would fix that. You're right that a problem would remain about an attacker simply filling all disk space, but that's more manageable (disks are bigger than 2GB), and this condition doesn't kill httpd. Graham Wiseman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 13, 2002 2:18 PM To: [EMAIL PROTECTED] Cc: Graham Wiseman; Richard Reiner Subject: Re: Apache dies on large error_log (possible remote DoS) On Tue, Aug 13, 2002 at 11:54:14AM -0400, Cliff Woolley wrote: > This has always been the case for both Apache 2.0 and 1.3 and is a > well-known issue. It's up to the administrator to have appropriate log > rotation and monitoring in place, as there's not much we can really do > about this from within the server itself. We *could* teach httpd about LARGEFILE so if the OS supports it we can have large logs, but, the essential problem still remains - you can easily get the log file to eat up all disk space. -- justin
Re: Re[2]: perchild on FreeBSD 5?
On Tue, Aug 13, 2002 at 02:11:08PM -0400, Ryan Bloom wrote: > I don't honestly know. The problem is that there are mulitple ways to > pass file descriptors between processes based on the Unix that you are > using. Assuming FreeBSD, NetBSD, and OpenBSD all have good thread > libraries and that they all support the fd passing mechanism that Liux > uses, yes everything will work. IF they don't support the same fd passing > logic, then it is a simple matter of implementing the other fd passing > logic, which should be easy to do. Assuming I get Perchild working this > week, I will try to get it working on a BSD machine that I have as > well. If I can't make it work on my BSD machine (because it is FreeBSD), > then I will most likely need an account on a Net or Open BSD box. I most probably can help for OpenBSD. I'm maintaining our in-tree apache (1.3.27 w/ local changes), and 2.0 could/should be in ports/. I'm not going to import 2.0 in the near future, though. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
AllowOverride - Doc bug vs. Code bug
Could somebody clarify this? The documentation for AllowOverride states that the default for the directive is "AllowOverride All". But if you add an alias to a directory and do not include a block for the aliased directory or if you simply exclude the AllowOverride directive from the block, Apache will ignore the .htaccess file even if it exists. The default in create_core_dir_config() is to set the override field to OR_UNSET. This would imply that the default behavior of AllowOverride would be either undetermined or to inherit the parent directory's overrides. Is this a bug in the documentation or the source code? Or can somebody explain how the documentation reflects the source code? thanks, Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com
Re: Apache dies on large error_log (possible remote DoS)
On Tue, Aug 13, 2002 at 11:54:14AM -0400, Cliff Woolley wrote: > This has always been the case for both Apache 2.0 and 1.3 and is a > well-known issue. It's up to the administrator to have appropriate log > rotation and monitoring in place, as there's not much we can really do > about this from within the server itself. We *could* teach httpd about LARGEFILE so if the OS supports it we can have large logs, but, the essential problem still remains - you can easily get the log file to eat up all disk space. -- justin
Re: Re[2]: perchild on FreeBSD 5?
On Tue, 13 Aug 2002, Gabriel Ambuehl wrote: > -BEGIN PGP SIGNED MESSAGE- > > Hello Ryan, > > Tuesday, August 13, 2002, 6:10:21 PM, you wrote: > > > > Assuming that FreeBSD 5 solves the threading problems with FreeBSD, > then > > That's what we've been told by the people working on 5.0 at least. I > dunno whether they actually understand the issue though as they claim > that FreeBSD 4.X supports threading, too. > > > yes, Perchild will work on that platform. The problem right now is > that > > PErchild doesn't work at all. I am hoping to have time to work on > > PErchild on Thursday or Friday to finish the work on that MPM. > > On another note: will it already work on NetBSD or OpenBSD once it > will be back in service on Linux? I don't honestly know. The problem is that there are mulitple ways to pass file descriptors between processes based on the Unix that you are using. Assuming FreeBSD, NetBSD, and OpenBSD all have good thread libraries and that they all support the fd passing mechanism that Liux uses, yes everything will work. IF they don't support the same fd passing logic, then it is a simple matter of implementing the other fd passing logic, which should be easy to do. Assuming I get Perchild working this week, I will try to get it working on a BSD machine that I have as well. If I can't make it work on my BSD machine (because it is FreeBSD), then I will most likely need an account on a Net or Open BSD box. I have recently lost access to most of my different types of machines, and while I'll get some access to new boxes starting next week, it won't be specifically for Apache work. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re[2]: perchild on FreeBSD 5?
-BEGIN PGP SIGNED MESSAGE- Hello Ryan, Tuesday, August 13, 2002, 6:10:21 PM, you wrote: > Assuming that FreeBSD 5 solves the threading problems with FreeBSD, then That's what we've been told by the people working on 5.0 at least. I dunno whether they actually understand the issue though as they claim that FreeBSD 4.X supports threading, too. > yes, Perchild will work on that platform. The problem right now is that > PErchild doesn't work at all. I am hoping to have time to work on > PErchild on Thursday or Friday to finish the work on that MPM. On another note: will it already work on NetBSD or OpenBSD once it will be back in service on Linux? Best regards, Gabriel -BEGIN PGP SIGNATURE- Version: PGP 6.0.2i iQEVAwUBPVk4qcZa2WpymlDxAQE4ugf+IUHJ5PdrfKNYptwaTnh52JanT3LWHDB9 hy0vjobrBrrzaNikcNqtIgz/+q+pCsfcz3FeA4fXk3Z1q0Zs+wXD4uD+wx9LdsuW rAlmq5fqKBBWFjSXIEb1t2w6yRq+xzleeDnS9ndBN8NJDJV1u7PVYA5tYCDZ6sJB YNI4Yv4LDTmpuSv+ONWCvap2RUeHadAbNfbEkQzONOkl92fBUzDnmkyjEEOycUHq hoYxvN9T4zIspW+c+QJPdHQoKNWWXvAY1vyVxUqGxVEYikY3gd1P3DcJ37JRM6B+ hFrjyphdnWScaIQcPZ30/b3DTumeMjS/Hb4bzyX2r8TNJ10f261Qsg== =3o7K -END PGP SIGNATURE-
Re: Why can't ap_send_error_response() count on charset?
Carlo Perassi wrote: > > On Tue, Aug 13, 2002 at 11:06:57AM -0400, Greg Ames sent those random bytes: > > Can you try it again with current cvs HEAD? I'm not familiar with the W3C > > Validator test, but I would hope that if it saw a good http Content-Type header, > > it wouldn't need the stuff in the html meta line. > it's trivial to change the Apache C code to generate W3C pages but they have > technical reasons which don't permit to define a meta tag with charset > definition... Well, really it's more of a philosophical issue than a technical reason. This code should be as simple as possible due to its use in error situations, plus I dislike the idea of having to maintain the same information in two different places. But if the meta tag is necessary for some reason (which I don't understand) we can easily add it, as you pointed out. What do the html experts think? Joshua? Cliff? > so some minutes ago, on the Apache CVS tree it's appeared a fix > for a header problem, and as Greg Ames <[EMAIL PROTECTED]> said > "I would hope that if (the Validator) saw a good http Content-Type header, > it wouldn't need the stuff in the html meta line." > > Before trying the new Apache CVS code... Carlo, I don't think the fix I commited will make a difference here, now that I see what you are doing. So trying cvs HEAD would be a waste of your time. It only improves things when an ErrorDocument local redirect fails. You are already getting a good http Content-Type header from apache.org, but no meta tag in the html. I am curious to hear what the W3C Validator people say. > carlo@voyager:~$ telnet www.apache.org 80 > Trying 63.251.56.142... > Connected to daedalus.apache.org. > Escape character is '^]'. > GET http://www.apache.org/doesntexist.html HTTP/1.0 > > HTTP/1.1 404 Not Found > Date: Tue, 13 Aug 2002 15:41:38 GMT > Server: Apache/2.0.40 (Unix) > Content-Length: 287 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > > > > 404 Not Found > > Not Found > The requested URL /doesntexist.html was not found on this server. > > Apache/2.0.40 Server at www.apache.org Port 80 > > Connection closed by foreign host. Greg
Re: perchild on FreeBSD 5?
Assuming that FreeBSD 5 solves the threading problems with FreeBSD, then yes, Perchild will work on that platform. The problem right now is that PErchild doesn't work at all. I am hoping to have time to work on PErchild on Thursday or Friday to finish the work on that MPM. Ryan On Tue, 13 Aug 2002, Gabriel Ambuehl wrote: > Hello, > I've more or less accepted that perchild on FreeBSD 4.X isn't going to > happen (as sad as it is, I always considered it to be THE feature [1] in > 2.0 that would warrant an upgrade for us) but what I'd like to know is > if there is any chance to see perchild on FreeBSD 5 which gets wholly > new threading and SMP libs? > > > My company would happily pay someone a few thousand US$ to come up > with a working perchild implementation on FreeBSD 5 and from what > I've gathered on the FreeBSD mailing lists, there might be other > parties that would contribute to the funding, too. We haven't got any > reasonable in-house knowhow to contribute with code but we'd surely > help beta testing. > > > > > [1] Name based vhosts with PHP scripts running under the UID > of the user. Great for all ISPs out there. > > > Regards, > Gabriel > -- ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
RE: perchild on FreeBSD 5?
> > I am sure it does, but you also need to recognize that around 40% of all > > Apache installations have PHP on them. And 30% or so have mod_perl. Many > > actually have both, so there is some overlap, but I would say that over > > half of all Apache installs have one or both of PHP or mod_perl. > > > > Apache 2 is being pitched as a production-quality web server without any > > mention of the fact that over half of the current Apache sites probably > > should not upgrade at this point. > > This is definitely worth mentioning in the 2.0 Announcements. Have the > problems in mod_perl and mod_php been identified, so folks can at least make > an educated guess whether their site will tickle the known bugs? Nope, we really have no idea which libraries are threadsafe and which ones aren't. -Rasmus
Re: Why can't ap_send_error_response() count on charset?
On Tue, Aug 13, 2002 at 11:06:57AM -0400, Greg Ames sent those random bytes: > Can you try it again with current cvs HEAD? I'm not familiar with the W3C > Validator test, but I would hope that if it saw a good http Content-Type header, > it wouldn't need the stuff in the html meta line. Me too but I found a problem/feature due to the validator so I just wrote the following email to the w3c validator team: /* Hi all the default "404 Not Found" page generated by the latest version of Apache HTTP Server (and the similar pages) doesn't pass the W3C Validator test ( it's a HTML 2.0 code shipped without a meta tag with charset value: try this foo page to see it: http://www.apache.org/doesntexist.html ) As I explain to the Apache developers ( see http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=102918549709592&w=2 and http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=102925143132691&w=2 ) it's trivial to change the Apache C code to generate W3C pages but they have technical reasons which don't permit to define a meta tag with charset definition... so some minutes ago, on the Apache CVS tree it's appeared a fix for a header problem, and as Greg Ames <[EMAIL PROTECTED]> said "I would hope that if (the Validator) saw a good http Content-Type header, it wouldn't need the stuff in the html meta line." Before trying the new Apache CVS code... I found a "problem": when your Validator found a "404" on the response header of the server, it doesn't parse the HTML provided anymore. see this session and, trust me, the validator doesn't parse the code below: # # BEGIN # carlo@voyager:~$ telnet www.apache.org 80 Trying 63.251.56.142... Connected to daedalus.apache.org. Escape character is '^]'. GET http://www.apache.org/doesntexist.html HTTP/1.0 HTTP/1.1 404 Not Found Date: Tue, 13 Aug 2002 15:41:38 GMT Server: Apache/2.0.40 (Unix) Content-Length: 287 Connection: close Content-Type: text/html; charset=iso-8859-1 404 Not Found Not Found The requested URL /doesntexist.html was not found on this server. Apache/2.0.40 Server at www.apache.org Port 80 Connection closed by foreign host. # # END # My question is: why don't you drive the Validator to parse the html code, even when the return code is different from 200? If you do like this, Apache team will be able to check if the fix on the code which produces the header of the response is enough to pass the test. Thank you. */ So I (we) should wait their answer. Thanks. -- Carlo Perassi - http://www.linux.it/~carlo/ Do only what only you can do (Edsger Wybe Dijkstra: 1930-2002)
RE: perchild on FreeBSD 5?
> > > I agree with Pier, the threaded MPM has been a real lifesaver. > Supporting > > 10,000+ concurrent clients with Apache 1.3 (including some > complex modules) > > on AIX and Solaris is practically impossible. Quite doable > with Apache 2.0 > > and the worker MPM. > > I am sure it does, but you also need to recognize that around 40% of all > Apache installations have PHP on them. And 30% or so have mod_perl. Many > actually have both, so there is some overlap, but I would say that over > half of all Apache installs have one or both of PHP or mod_perl. > > Apache 2 is being pitched as a production-quality web server without any > mention of the fact that over half of the current Apache sites probably > should not upgrade at this point. This is definitely worth mentioning in the 2.0 Announcements. Have the problems in mod_perl and mod_php been identified, so folks can at least make an educated guess whether their site will tickle the known bugs? Bill
Re: Apache dies on large error_log (possible remote DoS)
On Tue, 13 Aug 2002 [EMAIL PROTECTED] wrote: > Bug in Apache 2.0.40 on Linux (possibly others): When error_log reaches > 2.0 GB in size, each httpd process (including the parent) will die > without warning on it's next write to error_log. This has always been the case for both Apache 2.0 and 1.3 and is a well-known issue. It's up to the administrator to have appropriate log rotation and monitoring in place, as there's not much we can really do about this from within the server itself. --Cliff
RE: perchild on FreeBSD 5?
> I agree with Pier, the threaded MPM has been a real lifesaver. Supporting > 10,000+ concurrent clients with Apache 1.3 (including some complex modules) > on AIX and Solaris is practically impossible. Quite doable with Apache 2.0 > and the worker MPM. I am sure it does, but you also need to recognize that around 40% of all Apache installations have PHP on them. And 30% or so have mod_perl. Many actually have both, so there is some overlap, but I would say that over half of all Apache installs have one or both of PHP or mod_perl. Apache 2 is being pitched as a production-quality web server without any mention of the fact that over half of the current Apache sites probably should not upgrade at this point. -Rasmus
Apache dies on large error_log (possible remote DoS)
Bug in Apache 2.0.40 on Linux (possibly others): When error_log reaches 2.0 GB in size, each httpd process (including the parent) will die without warning on it's next write to error_log. An attacker flooding the server with large invalid requests using Keep-Alives, can fill error_log at about a 1:1 ratio to the number of bytes transmitted (including TCP/IP overhead). A single attacker with a fast cable modem could bring down an Apache server in an evening using this method. Note: An email reporting this problem in more detail was sent to [EMAIL PROTECTED] a week ago without response. Graham Wiseman [EMAIL PROTECTED]
Re: perchild on FreeBSD 5?
Pier Fumagalli wrote: > "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote: > > >>>Hello, >>>I've more or less accepted that perchild on FreeBSD 4.X isn't going to >>>happen (as sad as it is, I always considered it to be THE feature [1] in >>>2.0 that would warrant an upgrade for us) but what I'd like to know is >>>if there is any chance to see perchild on FreeBSD 5 which gets wholly >>>new threading and SMP libs? >> >>I agree, and I have been preaching the same thing for a while. Almost no >>point in releasing Apache2 without a working perchild. Unfortunately >>there are other issues as well. A lot of the 3rd party libs that >>something like PHP or mod_perl depends on are not necessarily threadsafe. >>As witnessed by FreeBSD's incredibly buggy threading code there aren't a >>lot of things using threads heavily on UNIX. With some notable >>exceptions, of course, but very few try to pull in 30 or 40 3rd-party >>libraries as well. We are going to have to fix a bunch of them and mutex >>some others before Apache2 with a threaded MPM will be of any use with PHP >>or mod_perl. And I am not sure how to go about identifying the libraries >>that aren't qiute threadsafe. Problems generally only show up under load >>and only in certain circumstances. Especially for the libraries that >>claim to be threadsafe but aren't quite for whatever reason. > > > Luckily, in Java land things are more or less brighter, and I can say that > for what matters to me (I don't use PHP on big production servers, apart > from a couple of things which are thread safe - IMP and related), the > threaded MPM is giving me nothing but joy every single friggin' day! :) > > Keep up the "gud staf" guys! :) I'd just like to iterate that the WORKER and the threaded MPM do work. and make it worth considering apache 2.0 for production environments, where you are seeing your memory requirements get pushed to the limits, we have seen 1.3's servers happily use 1-4G of memory on our production boxes. under the same loads we see ~500M usage with 2.0 --Ian > > Pier (working his ass off on a deadline!) >
RE: perchild on FreeBSD 5?
> > "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote: > > >> Hello, > >> I've more or less accepted that perchild on FreeBSD 4.X isn't going to > >> happen (as sad as it is, I always considered it to be THE > feature [1] in > >> 2.0 that would warrant an upgrade for us) but what I'd like to know is > >> if there is any chance to see perchild on FreeBSD 5 which gets wholly > >> new threading and SMP libs? > > > > I agree, and I have been preaching the same thing for a while. > Almost no > > point in releasing Apache2 without a working perchild. Unfortunately > > there are other issues as well. A lot of the 3rd party libs that > > something like PHP or mod_perl depends on are not necessarily > threadsafe. > > As witnessed by FreeBSD's incredibly buggy threading code there aren't a > > lot of things using threads heavily on UNIX. With some notable > > exceptions, of course, but very few try to pull in 30 or 40 3rd-party > > libraries as well. We are going to have to fix a bunch of them > and mutex > > some others before Apache2 with a threaded MPM will be of any > use with PHP > > or mod_perl. And I am not sure how to go about identifying the > libraries > > that aren't qiute threadsafe. Problems generally only show up > under load > > and only in certain circumstances. Especially for the libraries that > > claim to be threadsafe but aren't quite for whatever reason. > > Luckily, in Java land things are more or less brighter, and I can say that > for what matters to me (I don't use PHP on big production servers, apart > from a couple of things which are thread safe - IMP and related), the > threaded MPM is giving me nothing but joy every single friggin' day! :) > > Keep up the "gud staf" guys! :) > > Pier (working his ass off on a deadline!) I agree with Pier, the threaded MPM has been a real lifesaver. Supporting 10,000+ concurrent clients with Apache 1.3 (including some complex modules) on AIX and Solaris is practically impossible. Quite doable with Apache 2.0 and the worker MPM. Bill
Re: Share data between servers
Sébastien Bonnegent wrote: > Graham Leggett wrote: > GL> Sébastien Bonnegent wrote: > GL> > GL> > Not necessarily, because I can detect in the proxy module when the server > GL> > responds with a 401 (need authentification) and in this case, I re-send > GL> > a request with a authentification field if the user is already authentified > GL> > on the proxy. And this, without any browser's cooperation. > GL> > GL> In that case I've lost you - can you explain again what you are trying > GL> to achieve? I understood that you were trying to force a transparent > GL> proxy to authenticate users through it, I don't see how the end server > GL> should get involved in any of this...? > > The server doesn't see that there is a proxy, the schema is as follow: > --- > | User Proxy --- Server | > --- > Get an URL > do nothing > Need auth >so ><(401) >If User is known >then > give user > auth header (auth)---> >else > <(401) > user provides > authentification > (auth)> catch the authentification header > and store it somewhere (auth)> > > (401) means "need authentification", a 401 request > (auth) means that the request contains an authentification header > > Is it more clear ? ok.. it seems like you need to cache the authentication header, so that based on whatever criteria you can re-add it to the proxied request. I'm not sure if you can do this at the moment with the current code. we have a hook in place which will let you inject the auth header into to proxied request, but I don't think there is a hook to grab the original auth-header recieved from the 'server' so you can cache it. so to summarise, you would need to write a authentication module which can grab the original authentication and cache it (you could use something similar in design to mod_mem_cache to do this). you can then inject it via the proxy hook into the proxied request. I haven't tried it, and I >think< this may work .. --Ian > > Best regards, > seß - sinad
Re: perchild on FreeBSD 5?
"Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote: >> Hello, >> I've more or less accepted that perchild on FreeBSD 4.X isn't going to >> happen (as sad as it is, I always considered it to be THE feature [1] in >> 2.0 that would warrant an upgrade for us) but what I'd like to know is >> if there is any chance to see perchild on FreeBSD 5 which gets wholly >> new threading and SMP libs? > > I agree, and I have been preaching the same thing for a while. Almost no > point in releasing Apache2 without a working perchild. Unfortunately > there are other issues as well. A lot of the 3rd party libs that > something like PHP or mod_perl depends on are not necessarily threadsafe. > As witnessed by FreeBSD's incredibly buggy threading code there aren't a > lot of things using threads heavily on UNIX. With some notable > exceptions, of course, but very few try to pull in 30 or 40 3rd-party > libraries as well. We are going to have to fix a bunch of them and mutex > some others before Apache2 with a threaded MPM will be of any use with PHP > or mod_perl. And I am not sure how to go about identifying the libraries > that aren't qiute threadsafe. Problems generally only show up under load > and only in certain circumstances. Especially for the libraries that > claim to be threadsafe but aren't quite for whatever reason. Luckily, in Java land things are more or less brighter, and I can say that for what matters to me (I don't use PHP on big production servers, apart from a couple of things which are thread safe - IMP and related), the threaded MPM is giving me nothing but joy every single friggin' day! :) Keep up the "gud staf" guys! :) Pier (working his ass off on a deadline!)
Re: perchild on FreeBSD 5?
> Hello, > I've more or less accepted that perchild on FreeBSD 4.X isn't going to > happen (as sad as it is, I always considered it to be THE feature [1] in > 2.0 that would warrant an upgrade for us) but what I'd like to know is > if there is any chance to see perchild on FreeBSD 5 which gets wholly > new threading and SMP libs? I agree, and I have been preaching the same thing for a while. Almost no point in releasing Apache2 without a working perchild. Unfortunately there are other issues as well. A lot of the 3rd party libs that something like PHP or mod_perl depends on are not necessarily threadsafe. As witnessed by FreeBSD's incredibly buggy threading code there aren't a lot of things using threads heavily on UNIX. With some notable exceptions, of course, but very few try to pull in 30 or 40 3rd-party libraries as well. We are going to have to fix a bunch of them and mutex some others before Apache2 with a threaded MPM will be of any use with PHP or mod_perl. And I am not sure how to go about identifying the libraries that aren't qiute threadsafe. Problems generally only show up under load and only in certain circumstances. Especially for the libraries that claim to be threadsafe but aren't quite for whatever reason. -Rasmus
Re: Why can't ap_send_error_response() count on charset?
Carlo Perassi wrote: > > Hi all. > In modules/http/http_protocol.c > the comment say > ap_send_error_response is used for any response that can be generated by the > server from the request record. This includes all [snip] messages that have > not been redirected to another handler via the ErrorDocument feature. > On line 2331 I read: > /* can't count on a charset filter being in place here, > * so do ebcdic->ascii translation explicitly (if needed) > */ This code produces worst-case error messages. We can't assume that mod_charset_lite's output filter (or any other resource filter) is present and working, because there are many reasons why it might be missing or non-functional, including user configuration errors. So on ebcdic platforms, we must explictly translate the error messages from the native charset used in the source code to ascii. In non-error situations, ebcdic->ascii charset translations (and vice versa) are done using filters. > Anyway... with the actual code, the html generated by ap_send_error_response > can't pass the W3C Validator test (with the missing meta line it would be ok). I just committed a fix a few minutes ago which should fix http header problems with the worst case error messages, as well as the ebcdic issue. With this fix, ap_send_error_message should *always* send a good http Content-Type header containing the values set up on line 2264: ap_set_content_type(r, "text/html; charset=iso-8859-1"); Can you try it again with current cvs HEAD? I'm not familiar with the W3C Validator test, but I would hope that if it saw a good http Content-Type header, it wouldn't need the stuff in the html meta line. Greg
Re: Share data between servers
So, Are there a solution to share some data between all the httpd process ? (Please) Best regards, seß - sinad -- GPG uid: 0xCB92591D ICQ: 60143970 LINUX - because life is too short to reboot ! -- Fortune: Talkers are no good doers. -- William Shakespeare, "Henry VI" msg11454/pgp0.pgp Description: PGP signature
perchild on FreeBSD 5?
Hello, I've more or less accepted that perchild on FreeBSD 4.X isn't going to happen (as sad as it is, I always considered it to be THE feature [1] in 2.0 that would warrant an upgrade for us) but what I'd like to know is if there is any chance to see perchild on FreeBSD 5 which gets wholly new threading and SMP libs? My company would happily pay someone a few thousand US$ to come up with a working perchild implementation on FreeBSD 5 and from what I've gathered on the FreeBSD mailing lists, there might be other parties that would contribute to the funding, too. We haven't got any reasonable in-house knowhow to contribute with code but we'd surely help beta testing. [1] Name based vhosts with PHP scripts running under the UID of the user. Great for all ISPs out there. Regards, Gabriel
Re: server push CGI problem
On Mon, 12 Aug 2002, Justin Erenkrantz wrote: > > I've got an update problem regarding apache 1.3.24/2.0.39 and a home-grown > > server-push webcam CGI. The CGI continuously reads images from the cam, > Can you try 2.0.40 as I believe some of the CGI handling was been > rewritten since .39? > > So, this already may have been resolved. -- justin I just did - without any effect. The normal CGI still continues to run after the connection to the browser has been closed with apache reading and discarding its output. The nph- variant doesn't seem to give a mime-type at all so that mozilla tries to download it as application/octet-stream and navigator 4.79 is showing the output literally. If someone could point me at the piece of source to look for that output-discarding I could start hacking about myself. I found something in mod_cgi.c already but that seems to apply to redirects only. The output discard after connection break seems to happen at the end of the filter stack. If it's of any relevance to the problem: The whole thing is running on an SGI Indigo2 with IRIX 6.5.16f and was compiled using MIPSpro cc 7.2.3.1 and linked against various precompiled open source libs from freeware.sgi.com. (without any problems BTW) -- bye, Micha
Re: no NDBM support is compiled in
"Werner Schalk" <[EMAIL PROTECTED]> writes: > "RewriteMap: cannot use NDBM mapfile, > because no NDBM support is compiled in" > > What must I do to enable ndbm files > in my apache 2.0.39? You can change modules/mappers/config9.m4 as follows: Index: config9.m4 === RCS file: /home/cvs/httpd-2.0/modules/mappers/config9.m4,v retrieving revision 1.11 diff -u -r1.11 config9.m4 --- config9.m4 20 May 2002 21:00:27 - 1.11 +++ config9.m4 13 Aug 2002 10:56:28 - @@ -13,9 +13,7 @@ APACHE_MODULE(userdir, mapping of user requests, , , yes) APACHE_MODULE(alias, translation of requests, , , yes) -APACHE_MODULE(rewrite, regex URL translation, , , most, [ - APR_ADDTO(CFLAGS,-DNO_DBM_REWRITEMAP) -]) +APACHE_MODULE(rewrite, regex URL translation, , , most) dnl mod_so should only be built as a static module if test "$enable_so" = "yes"; then At least this built for me on Linux. I think that the "real" fix is to change mod_rewrite to use apr-util's dbm support since apr-util properly handles the job of finding which dbm libraries are available and talking to any available ones. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: how to make 'nobody' account available?
Ping Liu <[EMAIL PROTECTED]> writes: > In the first computer, 'nobody' account works okay. But in the second > computer, I got an error message saying something like Find a support newsgroup or mailing list for your operating system. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
how to make 'nobody' account available?
Good evening, I'm trying to do some programming on a computer to simulate the application on another computer, simply speaking, try to make two computer run the same program. In the first computer, 'nobody' account works okay. But in the second computer, I got an error message saying something like nobody account is currently unavailable Does anybody have an idea for this? Could you lend me a hand? Thank you very much for your help. Ping
Re: Share data between servers
Graham Leggett wrote: GL> Sébastien Bonnegent wrote: GL> GL> > Not necessarily, because I can detect in the proxy module when the server GL> > responds with a 401 (need authentification) and in this case, I re-send GL> > a request with a authentification field if the user is already authentified GL> > on the proxy. And this, without any browser's cooperation. GL> GL> In that case I've lost you - can you explain again what you are trying GL> to achieve? I understood that you were trying to force a transparent GL> proxy to authenticate users through it, I don't see how the end server GL> should get involved in any of this...? The server doesn't see that there is a proxy, the schema is as follow: --- | User Proxy --- Server | --- Get an URL > do nothing > Need auth so <(401) If User is known then give user auth header (auth)---> else <(401) user provides authentification (auth)> catch the authentification header and store it somewhere (auth)> (401) means "need authentification", a 401 request (auth) means that the request contains an authentification header Is it more clear ? Best regards, seß - sinad -- GPG uid: 0xCB92591D ICQ: 60143970 LINUX - because life is too short to reboot ! -- Fortune: Someone is speaking well of you. How unusual! msg11448/pgp0.pgp Description: PGP signature
