Bug 44979 - Host header field integer inconsistency
Summary: Host header field integer inconsistency
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.2.11
Hardware: All All
: P5 minor (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: FixedInTrunk
Depends on:
Blocks:
 
Reported: 2008-05-12 16:34 UTC by David Bresson
Modified: 2011-03-26 11:22 UTC (History)
1 user (show)


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Bresson 2008-05-12 16:34:45 UTC 
An all numeric Host header field is treated as an integer.  If the value is greater than 65535, an error 400 is returned.  If the optional port is specified (adding a colon), the field is treated as a string and returns status 200.

This results in inconsistent behavior in the handling of decimal IPs (as opposed to dotted decimal).

http://2130706433/ (127.0.0.1) will return status 400.  http://2130706433:80/ will return status 200.
Comment 1 Josh Lee 2009-05-03 08:37:14 UTC 
A couple more observations:

* The host doesn't necessarily have to be greater than 65535; http://0/ triggers the behavior.
* IIS and lighttpd both show this behavior. Cherokee, gws, and apache1.3 do not.
* Here's the same bug in lighttpd: http://redmine.lighttpd.net/issues/1952
Comment 2 David Bresson 2009-05-14 01:11:10 UTC 
However, unlike IIS and presumably lighttpd, a status 200 is returned for requests with a Host header of 1 through 65535.
Comment 3 Nick Kew 2009-11-02 15:34:24 UTC 
I've just fixed this in trunk in r832172 .
A bare integer is now treated as hostname, not as port, so it will be accepted if configured.
Comment 4 Nick Kew 2011-03-26 11:22:31 UTC 
Fix seems to have been backported in r984172