HTTP RFC vs real world

After quite some work, exaproxy is now serving our producting traffic nicely, however it does not mean that once in a while we do not get some surprises !

I found the following request in our logs recently:

GET /a-page.php?many=argument&passed=here\r\n
HTTP/1.0\r\n
Host: changed.to.protect.the.innocent.com\r\n
Connection: close\r\n
\r\n

Yes, you read properly, there is a new line between the URI and the procotol version, here HTTP/1.0, when RFC2616 (the document which explains how a web server and your browser should speak) clearly does not allow it.

So what was my surprise to find out that apache is replying correctly to this request if no virtual hosts are configured (without HTTP headers) !

»› telnet 127.0.0.1 80
Trying 127.0.0.1...
Won't send login name and/or authentication information.
Connected to localhost.
Escape character is '^]'.
GET /
HTTP/1.0
Host: changed.to.protect.the.innocent.com
Connection: close

<html>
some more html
</html>

Connection closed by foreign host.

compared to ..

»› telnet 127.0.0.1 80
Trying 127.0.0.1...
Won't send login name and/or authentication information.
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0
Host: changed.to.protect.the.innocent.com
Connection: close

HTTP/1.1 200 OK
Date: Tue, 07 May 2013 21:59:15 GMT
Server: Apache/2.2.22 (Unix) DAV/2 PHP/5.3.15 with Suhosin-Patch mod_ssl/2.2.22 OpenSSL/0.9.8r
X-Powered-By: PHP/5.3.15
Connection: close
Content-Type: text/html


<html>
some more html
</html>

Connection closed by foreign host.

The internet is full of surprises :)

Now time to fix our request parsing code to allow this broken client to call back home !

Avatar
Thomas Mangin
Technology Enthusiast