Bug 90546

Summary: Error Document 400 does not return properly for requests which violate the RFC.
Product: [Retired] Stronghold for Red Hat Linux Reporter: Jp Robinson <robinson>
Component: stronghold-apacheAssignee: Joe Orton <jorton>
Status: CLOSED WONTFIX QA Contact: Stronghold Engineering List <stronghold-eng-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: stronghold-eng-list, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-05-25 13:08:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jp Robinson 2003-05-09 15:38:32 UTC
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:

Comment 1 Joe Orton 2003-05-14 09:07:01 UTC
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 12:30:15 UTC
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 13:08:34 UTC
Given that this isn't a practical issue, no intention to fix at this time.