This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 90546 - Error Document 400 does not return properly for requests which violate the RFC.
Error Document 400 does not return properly for requests which violate the RFC.
Product: Stronghold for Red Hat Linux
Classification: Retired
Component: stronghold-apache (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
Stronghold Engineering List
Depends On:
  Show dependency treegraph
Reported: 2003-05-09 11:38 EDT by Jp Robinson
Modified: 2007-05-25 09:08 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-25 09:08:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jp Robinson 2003-05-09 11:38:32 EDT
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:


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

<TITLE>400 Bad Request</TITLE>
<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):

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:

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:
Comment 1 Joe Orton 2003-05-14 05:07:01 EDT
Is this a practical problem for some customer?  I'm surprised if there are any
clients out there which issue these broken requests.
Comment 2 Jp Robinson 2003-05-14 08:30:15 EDT
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. 
Comment 3 Joe Orton 2007-05-25 09:08:34 EDT
Given that this isn't a practical issue, no intention to fix at this time.

Note You need to log in before you can comment on or make changes to this bug.