Bug #1937

Bad request

Added by unixro over 5 years ago. Updated about 5 years ago.

Status:FixedStart date:2009-03-16
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:-
Target version:1.4.24
Missing in 1.5.x:No

Description

I'm trying to do a provisioning on thomson phone, and seems that the request is rejected with bad request., with same settings it works fine on apache. Can't really spot the problem so any help would be great.

2009-03-16 20:15:12: (request.c.294) fd: 7 request-len: 230
GET http://192.168.14.135/thomson/ST2030S_00147FE1B51E.inf HTTP/1.1
Accept: */*
Accept-Language: en-gb, en;q=0.5
User-Agent: THOMSON ST2030 hw5 fw1.56 00-14-7F-E1-B5-1E
Host: 192.168.14.135/thomson
Connection: Keep-Alive

2009-03-16 20:15:12: (response.c.120) Response-Header:
HTTP/1.0 400 Bad Request
Content-Type: text/html
Content-Length: 349
Connection: close
Date: Mon, 16 Mar 2009 18:15:12 GMT
Server: voipnow


Related issues

Duplicates Bug #1980: conflict with RFC 2616 Section 5.2 New 2009-05-11

Associated revisions

Revision 2631
Added by stbuehler about 5 years ago

Read hostname from absolute uris in the request line (fixes #1937)

History

#1 Updated by unixro over 5 years ago

Version 1.4.22 with ascii 9 patch

#2 Updated by unixro over 5 years ago

  • Target version set to 1.4.22

#3 Updated by icy over 5 years ago

  • Target version changed from 1.4.22 to 1.4.23

#4 Updated by unixro over 5 years ago

  • Target version changed from 1.4.23 to 1.4.22

Seems that the problem is the host part it doesn't like /thomson part works ok with:
GET http://192.168.14.135/thomson/ST2030S_00147FE1B51E.inf HTTP/1.1
Accept: */*
Accept-Language: en-gb, en;q=0.5
User-Agent: THOMSON ST2030 hw5 fw1.56 00-14-7F-E1-B5-1E
Host: 192.168.14.135
Connection: Keep-Alive

#5 Updated by icy over 5 years ago

  • Target version changed from 1.4.22 to 1.4.23

Please stop setting target version to 1.4.22, it messes our roadmap up. Target version is not affected version. Thanks.

#6 Updated by unixro over 5 years ago

Sorry was set and didn't realize

#7 Updated by icy over 5 years ago

192.168.14.135/thomson doesn't seem like a valid value for the Host header
Plus the path of the GET request is kinda strange. Not forbidden per se but strange nonetheless.

#8 Updated by stbuehler over 5 years ago

  • Status changed from New to Invalid

Invalid host header -> 400 Bad Request.
Nothing wrong here.

#9 Updated by unixro over 5 years ago

Isn't this covered by rule 1 when full uri is given host must be ignored and thus not validated ?:

5.2 The Resource Identified by a Request

The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.

An origin server that does not allow resources to differ by the requested host MAY ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)

An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity host names) MUST use the following rules for determining the requested resource on an HTTP/1.1 request:

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.

3. If the host as determined by rule 1 or 2 is not a valid host on the server, the response MUST be a 400 (Bad Request) error message.

Recipients of an HTTP/1.0 request that lacks a Host header field MAY attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine what exact resource is being requested.

#10 Updated by unixro over 5 years ago

  • Status changed from Invalid to Reopened

Please comment on this

#11 Updated by stbuehler over 5 years ago

Looks like you are right... effing standard :(
Why allow sending a Host: header if you have to ignore it?...

#12 Updated by peto over 5 years ago

I don't know if there are annotated standards explaining the rationale of things like this (it always helps to know why), but if their alternative for handling this case was to say "the client must not do this and the server must return an error if it happens", then it'd just be that much more complicated for everyone.

I wonder if someone like Apache has a test suite that could be reused to check obscure cases like this. Feels like a lot of duplicated work for stuff that almost everyone developing an HTTP server is going to get bitten by independently...

#13 Updated by stbuehler over 5 years ago

  • Target version changed from 1.4.23 to 1.4.24

#14 Updated by stbuehler about 5 years ago

  • Status changed from Reopened to Fixed
  • % Done changed from 0 to 100

Applied in changeset r2631.

#15 Updated by stbuehler about 5 years ago

  • Missing in 1.5.x set to No

Also available in: Atom