httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 51040] New: HTTP Status-Line omitted on 'GET /' with no HTTP-Version info
Date Fri, 08 Apr 2011 02:34:22 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=51040

           Summary: HTTP Status-Line omitted on 'GET /' with no
                    HTTP-Version info
           Product: Apache httpd-2
           Version: 2.3-HEAD
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Core
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: kevin.w.wall@gmail.com


Created an attachment (id=26866)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26866)
Capture using script and telnet to www.apache.org (text file)

I *think* this is a bug, but it may not be as it may have something
to do with backward compatibility of HTTP 1.0 or even 0.9. I didn't
go back and scruntinze those earlier RFCs.

At issue is what happens when Apache is sent an apparently malformed HTTP
request consisting of

    GET /

i.e., it is missing 'HTTP/ver#' portion; e.g.,   GET / HTTP/1.0

While I understand the philosophy of being "liberal in what one accepts"
(i.e., treat this as if it defaults to 'HTTP/1.0' or maybe HTTP/0.9),
I do not think it is proper to be liberal in what Apache sends as it's
response.

If you want to sent this, it should be something like:

    HTTP/1.0 200 OK

as the Status-Line, followed other optional status lines, then
a CRLF, and only THEN followed by the message body.

(Personally, I would prefer that instead of 200 status being returned,
that a 400 status be returned to the client, indicating that the
request was malformed and should not be repeated, but that's just
me. You may have valid reasons for returning a response in such
cases. I just want a Status-Line returned.)

Note that fact that this scenario described above (the missing Status-Line
response) causes an error in Imperva SecureSphere, a web application
firewall. (A similiar scenario has been know to cause Imperva SecureSphere
to think that the HTTP status response code is '}'. Yeah, it doesn't make
sense to me either. Obviously a parsing problem of some sort, but we
tracked its root cause down to the fact that Apache was omitting
the Status-Line on bad responses.)

An example captured from www.apache.org site is attached.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message