On Mon, 2007-12-24 at 12:55 +0800, John Peter Loh wrote:
> We have an app that communicates with a third party. Lately, they've
> been getting HTTP 400 errors from us.
>
> We tried everything. Contacted the netads in our datacenter. Turned off
> our firewall. Restarted Apache. Restarted the server. We tried
> replicating the requests with telnet on different web servers. The other
> side doesn't want to admit that something went wrong with their app. We
> enabled mod_dumpio and found out that the third party's requests are
> missing the Host field in the headers.
some quick googling points to:
"Some ancient clients are not compatible with name-based virtual
hosting. For name-based virtual hosting to work, the client must send
the HTTP Host header. This is required by HTTP/1.1, and is implemented
by all modern HTTP/1.0 browsers as an extension. If you need to support
obsolete clients and still use name-based virtual hosting, a possible
technique is discussed at the end of this document.
* Name-based virtual hosting cannot be used with SSL secure
servers because of the nature of the SSL protocol.
* Some operating systems and network equipment implement bandwidth
management techniques that cannot differentiate between hosts
unless they are on separate IP addresses."
http://httpd.apache.org/docs/1.3/vhosts/name-based.html
do they connect to you using SSL? are they behind a transparent
proxy or something else (maybe just a regular, non-transparent
proxy) that is breaking HOST? what version of HTTP do they say
they'll use (the HTTP/x.y part of the headers). Did they switch
from 1.0 to 1.1? See below, if they switched to 1.1, the 400
errors are CORRECT. they should switch back to 1.0. maybe they're
using a library that switched to 1.1 but that has a bug regarding
HOST?
> The third party claims that the Host field wasn't present even before
> and the apps still worked. Now they want us to ignore the Host field.
> Anybody with an idea to do this?
did you switch to name based virtual hosts? when did the problem crop
up? when did you switch to name based virtual hosts? are you using
some, more exotic system like dynamic virtual hosts? (exotic only to
me since I've seen others [i.e., QSR] do it, but i've not done it
myself, never needing to).
If you're using HTTP/1.0, then Apache should not require the
Host header if you're not using virtual hosts or if you go
to the default site, e.g., this telnet session demonstrates
that I'm NOT sending the HOST header, but it still works.
[EMAIL PROTECTED]:~/public_html$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /~tiger/x.php HTTP/1.0
HTTP/1.1 200 OK
Date: Mon, 24 Dec 2007 06:41:49 GMT
Server: Apache/2.2.4 (Ubuntu) DAV/2 SVN/1.4.4 PHP/5.2.3-1ubuntu6
X-Powered-By: PHP/5.2.3-1ubuntu6
Content-Length: 10
Connection: close
Content-Type: text/html
HeLLo<BR>
Connection closed by foreign host.
on the other hand, specifying HTTP/1.1 gives:
[EMAIL PROTECTED]:~/public_html$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /~tiger/x.php HTTP/1.1
HTTP/1.1 400 Bad Request
Date: Mon, 24 Dec 2007 06:42:35 GMT
Server: Apache/2.2.4 (Ubuntu) DAV/2 SVN/1.4.4 PHP/5.2.3-1ubuntu6
Content-Length: 335
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not
understand.<br />
</p>
<hr>
<address>Apache/2.2.4 (Ubuntu) DAV/2 SVN/1.4.4 PHP/5.2.3-1ubuntu6 Server
at localhost Port 80</address>
</body></html>
Connection closed by foreign host.
which is correct behavior per:
"A client MUST include a Host header field in all HTTP/1.1 request
messages . If the requested URI does not include an Internet host name
for the service being requested, then the Host header field MUST be
given with an empty value. An HTTP/1.1 proxy MUST ensure that any
request message it forwards does contain an appropriate Host header
field that identifies the service being requested by the proxy. All
Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
status code to any HTTP/1.1 request message which lacks a Host header
field."
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23
tiger
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
[email protected] (#PLUG @ irc.free.net.ph)
Read the Guidelines: http://linux.org.ph/lists
Searchable Archives: http://archives.free.net.ph
