- From: Adrien de Croy <adrien@qbik.com>
- Date: Wed, 17 Jun 2009 13:16:51 +1200
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Actually, apologies, I should have revised the last email before sending. Sections 9, 14.2.3, and 19.6.1.1 are all in agreement that ALL http 1.1 request messages MUST contain a Host header. Section 5.2 implies in some cases there may not be one but that this seems to be OK. So the problem section appears to be 5.2. However, the sentence in 14.2.3 last para "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" is plain wrong. It is implying if there's no host in the request line, the host tag must be empty. this for obvious reasons cannot work, and should read something like "If the requested URI includes an Internet host name for the service being requested, then the Host header field MUST be given with an empty value" I'd actually also be keen to know what a proxy or O-S should do if there is a Host header and a host in the request URI which don't match. 5.2 states the Host header must be ignored, however isn't it an indication of something nasty, which should be bounced? If the Host header is passed through unchanged by a proxy after taking the host out of the Request-URI (converting an AbsoluteURI to a abs_path), then the O-S will get a different host tag to the host specified in the request URI. This is surely highly problematic. I see 3 options for how a proxy should deal with this case. 1. Do nothing 2. Bounce the request 3. re-write the host tag. Set it to the host part that was parsed out of AbsoluteURI. I'd be leaning towards 2, since it's an indication of malicious intent surely? Regards Adrien Adrien de Croy wrote: > > Hi > > > Roy T. Fielding wrote: >> On Jun 16, 2009, at 3:26 PM, Adrien de Croy wrote: >> >>> I recently updated our proxy to reject all HTTP/1.1 messages from >>> clients that lack a Host header. >>> >>> This has been found to break a number of clients which use the >>> CONNECT method. >> >> What clients? > I only have a couple of reports since this wasn't in general release - > a mail.ru client and FTP commander using CONNECT. > > However, on further reading of RFC2616, it appears David Morris is > correct, that a Host header is only a MUST requirement if the > Request-URI is not an AbsoluteURI, and MUST be ignored if it is. This > doesn't cover the case where Request-URI is authority (as per > CONNECT)... so a strict interpretation is that CONNECT requires host, > although I imagine this wasn't the intent, since authority contains > the required information. > >> >>> So it's going to be a necessity to relax this particular requirement >>> (in our proxy) at least for CONNECT. >> >> Unlikely. Apache always responds to such a request with 400. >> AFAIK, all the other origin servers do as well, so even if the >> request is passed by your proxy it is going to fail on the origin. >> > we don't have this problem in normal circumstances, since we don't > pass the CONNECT method through to the O-S, only an upstream proxy, > and we insert a Host header if there is none. > > I think probably the intention was that in RFC2616 S 5.2 where it reads > > 1. If Request-URI is an absoluteURI, the host is part of the > Request-URI. Any Host header field value in the request MUST be ignored. > > 2. If the Request-URI is not an absoluteURI, and the request includes > a Host header field, the host is determined by the Host header field > value. > > should read > > 1. If Request-URI is an absoluteURI or authority, the host is part of > the Request-URI. Any Host header field value in the request MUST be > ignored. > > 2. If the Request-URI is neither an absoluteURI nor an authority, and > the request includes a Host header field, the host is determined by > the Host header field value. > > This leaves the question of the final of the 4 cases for Request-URI, > being "*". Is a host header required or not for this? My assumption > would be not. > > although it looks like S5.2 is intended for Origin Servers, rather > than proxies. > > S 9 states clearly "The Host request-header field (section 14.23) MUST > accompany all HTTP/1.1 requests" which conflicts with 5.2 (otherwise > must be present but must be ignored in case of Request-URI = > AbsoluteURI...?) 5.2. implies (by saying "Any host header... ") that > the Host header is optional, otherwise it should read "The host header > MUST be ignored". > > S 14.2.3 States "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. " > > I've never seen an empty Host header, so I presume the up-take of that > requirement is rare if any. > > Regards > > Adrien > >> ....Roy >> > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Wednesday, 17 June 2009 01:14:03 UTC