They (third party) connect directly to us and they've been using HTTP/1.1 even when everything was fine. I am almost definite that their app stopped sending the host header that caused the 400 errors.
We're using name-based virtual hosting and everything was working fine. We didn't change anything in our configuration. I also simulated the requests with and without the Host field with telnet on various web servers that were working fine. This turned to a case of admitting who's the one doing the wrong thing. Gerald Timothy Quimpo wrote: > 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 _________________________________________________ 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
