From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830 Description of problem: Having set an errordocument for error 400, it returns the error document url for all cases except one which violates the RFC. For instance: TRACE HTTP/1.1 returns the error docuemnt, but: TRACE / HTTP/1.1 does not. It instead returns: HTTP/1.1 400 Bad Request Date: Tue, 06 May 2003 21:16:01 GMT Server: Stronghold/4.0c Apache/1.3.22 (Unix) mod_ssl/2.8.7 OpenSSL/0.9.6c Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 127 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>400 Bad Request</TITLE> </HEAD><BODY> <H1>Bad Request</H1> Your browser sent a request that this server could not understand.<P> client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /<P> </BODY></HTML> Setting the ErrorDocument directive to "some text" rather then a url works fine, but with a url it returns the wrong error Document. Version-Release number of selected component (if applicable): Stronghold 4.0f Cross-Platform Stronghold for Red Hat Enterprise Linux How reproducible: Always Steps to Reproduce: 1.Send a TRACE / HTTP/1.1 request. Actual Results: Returns default Error message Expected Results: Should reeturn custom error page. Additional info:
Is this a practical problem for some customer? I'm surprised if there are any clients out there which issue these broken requests.
It concerned a customer who was running various security tests, including a test for HTTP TRACE which did requests similar to above. The custom error messages not showing were of concern, as this may give away information about the software being run. While I concede the fact I know of no actual "client" that will produce such bad requests, I can see the customer's point regarding the error message.
Given that this isn't a practical issue, no intention to fix at this time.