Help needed: Bug #8480 still present in 1.3.23
Hi, the bug I've found on Oct 06 2001 is still present in Apache 1.3.23. I've spent several hours debugging the code myself, but ended up nowhere :-( Below you can find the summary of my bug report. To me it seems like a problem in the request body parser of Apache, but I'm not an Apache guru, so I could be wrong... Buying a CD at CDNOW from a wishlist is the least I can do for the developer helping me fixing this nasty bug. Thanks in advance, Thomas. Bug #8480: Synopsis: Trailing CRLF on POSTs not handled correctly Description: I can reproduce a problem handling the trailing CRLF on POSTs with a tcpdump of a form submitted with Netscape 4.6 under Windows NT 4.0. If you send this request to Apache (I used netcat to reproduce the bug), Apache will return nothing to the sender. Netscape will present a document contains no data page to the user. If I change the Content-Length to +2 Bytes for the extra CRLF or I remove the trailing CRLF, everything works perfect. How-To-Repeat: Create a page where you can POST data (like an empty PHP file), adjust the URL in the POST XXX HTTP/1.0 line and do a netcat -v webserver 80 netscape_postbug.txt Here is my netscape_postbug.txt. (Filesize is 417 bytes, don't forget to save the extra CRLF): POST /test.php HTTP/1.0 Referer: http://intradev.local/arnie?form=hauptseite Connection: Keep-Alive User-Agent: Mozilla/4.6 [en-gb] (WinNT; I) Host: intradev.local Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en-GB,en,en-* Accept-Charset: iso-8859-1,*,utf-8 Content-type: application/x-www-form-urlencoded Content-length: 9 test=test
Re: 2.0 accept() error handling in Unix
Greg Ames wrote:
had another look at worker
As it turns out, worker ignores the error and
re-issues the accept().
bzzzt! wrong...
if (rv == APR_EGENERAL) {
signal_workers();
which gracefully cleans up the child and exits without affecting the parent.
hmmm, that's what 1.3 does too. Both are treating should-not-occur programming
errors the same as resource shortages, but maybe that's not so bad.
I'll commit a patch in a bit to make prefork behave like worker and 1.3.
Greg
Re: Random languages for httpd.apache.org/docs (fwd)
Justin Erenkrantz wrote: On Sat, Feb 09, 2002 at 08:11:45AM -0800, Brian Behlendorf wrote: Heh, anyone want to check this out? Yeah, I see it too. Add: ForceLanguagePriority Prefer Fallback to daedalus's httpd.conf. I added it via .htaccess to docs-2.0 in httpd.apache.org and it respected the LanguagePriority ...so are we saying the config file suddenly went bad? It's possible, but I doubt it. Greg
Re: cvs commit: httpd-2.0/server/mpm/prefork prefork.c
[EMAIL PROTECTED] writes: gregames02/02/10 06:21:44 Modified:.CHANGES server/mpm/prefork prefork.c Log: prefork shouldn't be killing its parent if a child runs out of resources. Since this is necessary for daedalus anyway, this should be in any proposed 2.0.32. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Random languages for httpd.apache.org/docs (fwd)
Brian Behlendorf wrote: Heh, anyone want to check this out? Brian -- Forwarded message -- Date: Sat, 9 Feb 2002 05:05:58 -0600 From: Adam Hupp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Random languages for httpd.apache.org/docs I get french for /docs, and german for /docs/mod/directives.html. I got English for both, then reconfigured Netscape (Edit preferences...Navigator...Languages) and removed English (the only language I had). Then I got Japanese for both. Cute! I'm guessing it's been doing this for ages, but most people have some language configured in their browser, which explains why we haven't heard of this before. I'll check with 2_0_28 after I finish testing the JRE_1 tarball + prefork patch. Greg
daedalus is running JRE_1
...since Thursday, 07-Feb-2002 19:35:24 PST . This is Justin's tag which we hope will become 2.0.32, plus the one line patch to allow prefork to survive resource shortages. I haven't checked yet to see if 2_0_28 has the same behavior when the client doesn't specify a language preference. That has been preempted by my washing machine. It's full of water so I have to go play mechanic. Greg
Re: Random languages for httpd.apache.org/docs (fwd)
On Sun, 10 Feb 2002, Greg Ames wrote: Justin Erenkrantz wrote: On Sat, Feb 09, 2002 at 08:11:45AM -0800, Brian Behlendorf wrote: Heh, anyone want to check this out? Yeah, I see it too. Add: ForceLanguagePriority Prefer Fallback to daedalus's httpd.conf. I added it via .htaccess to docs-2.0 in httpd.apache.org and it respected the LanguagePriority ...so are we saying the config file suddenly went bad? It's possible, but I doubt it. The config files are wrong; they should have ForceLanguagePriority. BUT... This does not explain the problem. In the absence of ForceLanguagePriority, apache should do the following: 1) If no Accept-Language: Use LanguagePriority. 2) If Accept-Language doesn't match with available language: Return No Acceptable Variant. It shouldn't be returning Japanese in any case unless Japaenese is preffered in the Accept-Language or by LanguagePriority. So we shouldn't just patch httpd.conf. We need to figure out what is going wrong. Joshua.
Re: Random languages for httpd.apache.org/docs (fwd)
Greg Ames wrote: Brian Behlendorf wrote: Heh, anyone want to check this out? Brian -- Forwarded message -- Date: Sat, 9 Feb 2002 05:05:58 -0600 From: Adam Hupp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Random languages for httpd.apache.org/docs I get french for /docs, and german for /docs/mod/directives.html. I got English for both, then reconfigured Netscape (Edit preferences...Navigator...Languages) and removed English (the only language I had). Then I got Japanese for both. Cute! I'm guessing it's been doing this for ages ummm, no. 2_0_28 returns English with no language configured in Netscape. It doesn't have ForceLanguagePriority in the config file either. Greg
Re: Random languages for httpd.apache.org/docs (fwd)
On Sun, Feb 10, 2002 at 12:02:18PM -0500, Joshua Slive wrote: The config files are wrong; they should have ForceLanguagePriority. rbb and I agree that ForceLanguagePriority Prefer Fallback should be the default. It defaults to None right now. OtherBill added this a few months ago (?) when he did some changes to mod_negotiation. He *did* add Prefer Fallback to the httpd-std.conf files, so it's obvious he intended this to be the default. No one updated daedalus to match. As I tried to show, just by adding ForceLanguagePriority Prefer Fallback to docs-2.0 fixes our problem. BUT... This does not explain the problem. In the absence of ForceLanguagePriority, apache should do the following: Well, taking a look at the code, I'm not entirely sure we're doing the wrong thing. I believe OtherBill was trying to ensure that we could never return the wrong thing unless the admin told us otherwise. Previously, we would return .html as the best language. That's a complete and total hack that we *must* get rid of. It was the wrong thing to do. This is how I see it: Prefer is used to avoid cases where we would send MULTIPLE_CHOICES or we do not have enough information to make a good determination about which language to use. So, we'll use LanguagePriority to determine what is best. (As we'll see in a second, otherwise, we'll use C-L to determine the best variant.) Fallback is used when we have no acceptable variants listed that match and would return NOT_ACCEPTABLE. We'll try to have a fallback choice to prevent that from occurring. Again, we'll use LanguagePriority to determine the best choice. 1) If no Accept-Language: Use LanguagePriority. In this case, this is only used when ForceLanguagePriority is set to Prefer. Look at mod_negotiation.c:set_language_quality(). On browsers that don't send Accept-Language headers, we can't use any heuristics, so we avoid making any determination as to the quality of the variant. However, we have a failsafe here: Prefer in ForceLanguagePriority. If ForceLanguagePriority is set to Prefer and we haven't computed its language priority (and in the case of no Accept-Language we definitely haven't set lang_index), we'll go through and compute lang_index based on LanguagePriority listed in httpd.conf. When we go through all variants in best_match() and call is_variant_better(), one of the factors is lang_index. However, if Prefer isn't set and we didn't receive Accept-Language, lang_index is -1 for *all* variants. So, they would all match. And, indeed, with our manuals, that is really the only distinction we have available when we don't have an Accept-Language. Therefore, the determining factor once again is content-length. And, french has the smallest size of all the docs: jerenkrantz@daedalus% ls -l /www/httpd.apache.org/docs/index.html.* -rw-rw-r-- 1 slive httpd 9266 Dec 2 11:46 index.html.en -rw-r--r-- 1 rbowen httpd 8603 Oct 7 18:41 index.html.fr -rw-r--r-- 1 rbowen httpd 156 Oct 7 18:41 index.html.html -rw-rw-r-- 1 slive httpd 9504 Dec 30 08:07 index.html.ja.jis (Notice our friend .html.html which has been relegated to outcast.) jerenkrantz@daedalus% ls -l /www/httpd.apache.org/docs-2.0/index.html* -rw-rw-r-- 1 slive httpd 9334 Dec 3 10:38 index.html.en -rw-rw-r-- 1 jwoolley httpd 8223 Sep 22 17:29 index.html.fr -rw-rw-r-- 1 slive httpd 5614 Dec 13 13:42 index.html.ja.jis (See why Japanese would be returned for Apache 2.0 docs, but I added FLP to the .htaccess file on daedalus, so we'll respect LangPriority.) 2) If Accept-Language doesn't match with available language: Return No Acceptable Variant. I believe this could occur if Accept-Language is sent. In the cases we're seeing, that's not the case as no Accept-Language is sent. And, indeed, this is what Fallback is for. Fallback should deal with the case that we don't want to return HTTP_NOT_ACCEPTABLE if their Accept-Language doesn't match. So we shouldn't just patch httpd.conf. We need to figure out what is going wrong. I believe nothing is wrong. I believe it is working as intended. Fix the config file, and move on. I will attempt to commit a change that makes PREFER and FALLBACK the default for ForceLangPriority in the code, but I'm not sure when I'll be able to commit that. OtherBill may beat me to that. (I believe he is taking a well-deserved vacation this weekend.) -- justin
RE: Random languages for httpd.apache.org/docs (fwd)
Justin Erenkrantz wrote: On Sat, Feb 09, 2002 at 08:11:45AM -0800, Brian Behlendorf wrote: Heh, anyone want to check this out? Yeah, I see it too. Add: ForceLanguagePriority Prefer Fallback to daedalus's httpd.conf. I added it via .htaccess to docs-2.0 in httpd.apache.org and it respected the LanguagePriority ...so are we saying the config file suddenly went bad? It's possible, but I doubt it. OtherBill committed code that changed how mod_negotiations works, so yes, the config file went bad when we bumped to this version of Apache. As it happens, this is also a bug in the code, because the default is wrong, but the simple fix right now is to fix the config file. Ryan
Re: Random languages for httpd.apache.org/docs (fwd)
On Sun, Feb 10, 2002 at 02:45:41PM -0500, Greg Ames wrote: ummm, no. 2_0_28 returns English with no language configured in Netscape. It doesn't have ForceLanguagePriority in the config file either. wrowe added FLP in revision 1.86 of mod_negotiation: revision 1.86 date: 2001/12/30 04:14:20; author: wrowe; state: Exp; lines: +77 -73 Introduce the ForceLanguagePriority options; Prefer will circumvent a Multiple Choices by electing the first matching language from the LanaguagePriority list. Fallback will circumvent a None Acceptable by electing the first language found from the LanaguagePriority list. This breaks [expectedly] the negotiation tests. They need review. My test results will be posted to dev. 2.0.28 has revision 1.84, so this is expected. And, I think that 2.0.28 might be serving .html.html. =) I believe this change makes our behavior better and makes us more configurable. -- justin
RE: Random languages for httpd.apache.org/docs (fwd)
So we shouldn't just patch httpd.conf. We need to figure out what is going wrong. I believe nothing is wrong. I believe it is working as intended. Fix the config file, and move on. I will attempt to commit a change that makes PREFER and FALLBACK the default for ForceLangPriority in the code, but I'm not sure when I'll be able to commit that. OtherBill may beat me to that. (I believe he is taking a well-deserved vacation this weekend.) -- justin I agree 100% with everything Justin said. The only bug in the code is that we have a default in the standard config file that doesn't match the default in the code. My boss keeps trying to convince me that it is a bug if the software doesn't just work with an empty config file. While I'm not sure I am at that point, I do believe that it is a bug if we have a default in the standard config that isn't a default in the code itself. Ryan
RE: Random languages for httpd.apache.org/docs (fwd)
On Sun, 10 Feb 2002, Ryan Bloom wrote: I agree 100% with everything Justin said. The only bug in the code is that we have a default in the standard config file that doesn't match the default in the code. My boss keeps trying to convince me that it is a bug if the software doesn't just work with an empty config file. While I'm not sure I am at that point, I do believe that it is a bug if we have a default in the standard config that isn't a default in the code itself. Ryan I meant to comment on this point too. The reason that the default for ForceLanguagePriority is none is that this gives the behavior closest to 1.3 and closest to the intentions of the HTTP/1.1 spec. (Although on the latter front, I'm not too sure.) I agree that it is confusing when the default config differs from the server default, but this is far from the only case for that. On the other hand, I won't object if you want to change the default. However, I still believe (strongly) that the behavior with ForceLanguagePriority none is wrong in the case of no Accept-Language and should be fixed. Joshua.
Re: cvs commit: httpd-2.0/server/mpm/prefork prefork.c
On Sun, Feb 10, 2002 at 02:21:44PM -, [EMAIL PROTECTED] wrote: gregames02/02/10 06:21:44 Modified:.CHANGES server/mpm/prefork prefork.c Log: prefork shouldn't be killing its parent if a child runs out of resources. Revision ChangesPath 1.572 +3 -0 httpd-2.0/CHANGES I've bumped the tag on JRE_1 to include this. Please let me know how it fares on daedalus. Once we are sure it's happy there for a few days, I can tag and roll it as .32. -- justin
Re: Random languages for httpd.apache.org/docs
[Third try sending this... Now that my DNS problems are fixed, I hope it will go through.] On Sun, 10 Feb 2002, Justin Erenkrantz wrote: On Sun, Feb 10, 2002 at 12:02:18PM -0500, Joshua Slive wrote: The config files are wrong; they should have ForceLanguagePriority. rbb and I agree that ForceLanguagePriority Prefer Fallback should be the default. It defaults to None right now. Everyone's agreed there. Whomever has the rights, please add this to httpd.conf on the server. BUT... This does not explain the problem. In the absence of ForceLanguagePriority, apache should do the following: Our disagreement is here: 1) If no Accept-Language: Use LanguagePriority. In this case, this is only used when ForceLanguagePriority is set to Prefer. Look at mod_negotiation.c:set_language_quality(). On browsers that don't send Accept-Language headers, we can't use any heuristics, so we avoid making any determination as to the quality of the variant. However, we have a failsafe here: Prefer in ForceLanguagePriority. I believe that this is wrong. OtherBill's changes were meant to affect only the case where Accept-Language is present. If Accept-Language is not present, then we should ALWAYS be using LanguagePriority, regardless of ForceLanguagePriority. This was the behavior in 1.3 and should continue to be the behavior in 2.0, IMHO. The alternative is completely non-sensical results, like returning the smallest file. The browser that sends no Accept-Language is saying I have no idea how to deal with language negotiation. In that case, we MUST use the server's best judgement of language. We should not just ignore language and negotiate based on other factors. And we shouldn't require the ForceLanguagePriority directive to make this happen. Joshua.
RE: cvs commit: httpd-2.0/server/mpm/worker pod.c pod.h Makefile.in mpm.h worker.c
Modified:.CHANGES server/mpm/worker Makefile.in mpm.h worker.c Added: server/mpm/worker pod.c pod.h Log: Remove all signal handling from the worker MPM's child processes. Instead, we use the pipe of death for all communication between parent and child. I added the new pod.[ch] files so that other MPMs could continue to use the current functions. Long-term, we probably want to combine the functions. Also, this was tested on Linux, so graceful seems to work. Unfortunately, graceless doesn't work any better than it used to, because Linux doesn't kill threads if the main thread in the process dies. I know how to fix it, but it will require using pthread_cancel, which we have always avoided in the past. I want to stress that this is the same behavior we were getting before this change. Tomorrow I will code the pthread_cancel stuff and post a patch for review. I am assuming that using pthread_cancel will generate some discussion. :-) Ryan
Re: Random languages for httpd.apache.org/docs (fwd)
From: Joshua Slive [EMAIL PROTECTED] Sent: Sunday, February 10, 2002 11:02 AM On Sun, 10 Feb 2002, Greg Ames wrote: ...so are we saying the config file suddenly went bad? It's possible, but I doubt it. The config files are wrong; they should have ForceLanguagePriority. BUT... This does not explain the problem. In the absence of ForceLanguagePriority, apache should do the following: 1) If no Accept-Language: Use LanguagePriority. Bingo. It's been so long since I hadn't looked at this; I've had brain freeze. [20 hour days with 4 hours rest haven't helped either - revisiting some priorities over this weekend I expect will help - at least help me.] That is not, in fact, what ForceLanguagePriority NONE should accomplish. I got stuck figuring out the implementation - the others worked so I had proceeded up to this issue. If the express no language preference, and we have ten available languages, and the administrator configures ForceLanguagePriority None - the available variants aught to be displayed. [It would be _really_ cool to have a HTTP_MULTIPLE_CHOICES.html that provides a single comment on how to toggle the language list for some common browsers :) 2) If Accept-Language doesn't match with available language: Return No Acceptable Variant. With None you are correct. Let me point out we can assign any reasonable default for the ForceLanguagePriority options until the admin overrides them. ForceLanguagePriority Default would be one good start.
Patch for PR# 4634
Hi, I've attached a patch against 1.3.23 that modifies ./configure to take a --force-suffix option as a solution to PR# 4634. http://bugs.apache.org/index.cgi/full/4634 This keeps the default behavior as is, but allows people who want to have the additional httpd tacked on the directories to do so, even if it is already in an apache subdirectory. BTW, for those wondering why this would be useful, I use epkg to install Apache as an encap package. http://www.encap.org/epkg/ The extra httpd subdirectories become useful when epkg makes symlinks to the encap directory, such as: /usr/local/etc/httpd/httpd.conf - ../../encap/apache-1.3.23/etc/httpd/httpd.conf I'd rather keep the files in /usr/local/etc/httpd rather than /usr/local/etc. -Dave diff -uNr apache_1.3.23/configure apache_1.3.23.1/configure --- apache_1.3.23/configure Thu Sep 27 13:12:03 2001 +++ apache_1.3.23.1/configure Tue Feb 5 09:38:37 2002 @@ -237,6 +237,7 @@ # layout configuration with_layout=0 show_layout=0 +force_suffix=0 # suexec defaults suexec=0 @@ -434,6 +435,7 @@ echo --runtimedir=DIR install runtime data in DIR echo --logfiledir=DIR install logfile data in DIR echo --proxycachedir=DIRinstall proxy cache data in DIR +echo --force-suffix always use TARGET as a suffix echo echo Configuration options: echo --enable-rule=NAME enable a particular Rule named 'NAME' @@ -703,6 +705,9 @@ proxycachedir=$apc_optarg autosuffix_proxycachedir=no ;; +--force-suffix) +force_suffix=1 +;; --add-module=*) file=$apc_optarg if [ x`echo $file | egrep '/?mod_[a-zA-Z0-9][a-zA-Z0-9_]*\.c$'` = x ]; then @@ -1124,10 +1129,14 @@ # still not part of path) eval autosuffix=\$autosuffix_$var if [ x$autosuffix = xyes ]; then -addtarget=no -if [ x`echo $val | grep apache` = x ]; then -if [ x`echo $val | grep $thetarget` = x ]; then -addtarget=yes +if [ x$force_suffix = x1 ]; then +addtarget=yes +else +addtarget=no +if [ x`echo $val | grep apache` = x ]; then +if [ x`echo $val | grep $thetarget` = x ]; then +addtarget=yes +fi fi fi if [ x$addtarget = xyes ]; then
