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:
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
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<TITLE>400 Bad Request</TITLE>
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):
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
Steps to Reproduce:
1.Send a TRACE / HTTP/1.1 request.
Actual Results: Returns default Error message
Expected Results: Should reeturn custom error page.
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.