Re: Help needed: Bug #8480 still present in 1.3.23
I tried it with your testfile and it failed.
Then I tried it again on another machine using exactly the
same binaries and there it worked.
I found out that this problem only occurs when I load a special custom module.
The module itself is doing authentication and some content serving.
It installs a "handler" via the "set handler" directive.
The interesting thing is that if I comment out all the references to the
module and just load it via the "LoadModule" directive,
the strange behavior starts to occur.
> d) if actually *nothing* is returned, there *MUST* be a line in the
>error_log. What does it say? If none is there, try to increase
>the LogLevel.
It was your hint that there -must- be a line in the error_log.
I've identified the problem: The custom module uses a flag to indicate
if an error has occurred ("errorOccured"). The module checks the flag
in the "[#9] log a transaction" phase of the module and exits
Apache via exit() if it's true.
And now the funny thing: The "errorOccured" boolean
was always initialized with "true". DOH!
Right now I'm wondering why the module ever worked :-)
I apologize for wasting your time and a big THANK YOU!
Tell me which CD you want :-) hehe
cheers,
Thomas
Re: Help needed: Bug #8480 still present in 1.3.23
On Sun, Feb 10, 2002 at 10:54:38AM +0100, Thomas Jarosch wrote: > 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... I tried to reproduce your problem, but to no avail. Some questions (in oder to nail down the problem): a) does your Apache-1.3.23 run on a unix platform, or on some CRLF-platform (e.g., windoze)? On unix, I had no problem whatsoever to do a "netcat localhost 80 | Fujitsu Siemens Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany POST /~martin/php/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: deejai.mch.fsc.net 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 GET / HTTP/1.0
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 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
