https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412009-03-16T18:15:54Zlighty labsLighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=57002009-03-16T18:15:54Zunixro
<ul></ul><p>Version 1.4.22 with ascii 9 patch</p> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=57012009-03-16T18:16:04Zunixro
<ul><li><strong>Target version</strong> set to <i>1.4.22</i></li></ul> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=57032009-03-16T18:23:00Zicy
<ul><li><strong>Target version</strong> changed from <i>1.4.22</i> to <i>1.4.23</i></li></ul> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=57042009-03-16T18:23:25Zunixro
<ul><li><strong>Target version</strong> changed from <i>1.4.23</i> to <i>1.4.22</i></li></ul><p>Seems that the problem is the host part it doesn't like /thomson part works ok with: <br />GET <a class="external" href="http://192.168.14.135/thomson/ST2030S_00147FE1B51E.inf">http://192.168.14.135/thomson/ST2030S_00147FE1B51E.inf</a> HTTP/1.1<br />Accept: */*<br />Accept-Language: en-gb, en;q=0.5<br />User-Agent: THOMSON ST2030 hw5 fw1.56 00-14-7F-E1-B5-1E<br />Host: 192.168.14.135<br />Connection: Keep-Alive</p> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=57052009-03-16T18:25:58Zicy
<ul><li><strong>Target version</strong> changed from <i>1.4.22</i> to <i>1.4.23</i></li></ul><p>Please stop setting target version to 1.4.22, it messes our roadmap up. Target version is not affected version. Thanks.</p> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=57062009-03-16T18:28:42Zunixro
<ul></ul><p>Sorry was set and didn't realize</p> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=57072009-03-16T18:32:33Zicy
<ul></ul><p>192.168.14.135/thomson doesn't seem like a valid value for the Host header<br />Plus the path of the GET request is kinda strange. Not forbidden per se but strange nonetheless.</p> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=57092009-03-16T18:34:24Zstbuehler
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Invalid</i></li></ul><p>Invalid host header -> 400 Bad Request.<br />Nothing wrong here.</p> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=57102009-03-16T19:16:09Zunixro
<ul></ul><p>Isn't this covered by rule 1 when full uri is given host must be ignored and thus not validated ?:</p>
<p>5.2 The Resource Identified by a Request</p>
<p>The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.</p>
<p>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.)</p>
<p>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:</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=57112009-03-16T22:06:38Zunixro
<ul><li><strong>Status</strong> changed from <i>Invalid</i> to <i>Reopened</i></li></ul><p>Please comment on this</p> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=57492009-03-26T22:31:06Zstbuehler
<ul></ul><p>Looks like you are right... effing standard :(<br />Why allow sending a Host: header if you have to ignore it?...</p> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=57552009-03-26T23:07:19Zpeto
<ul></ul><p>I don't know if there are annotated standards explaining the rationale of things like this (it always helps to know <strong>why</strong>), 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.</p>
<p>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...</p> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=60412009-06-10T17:27:23Zstbuehler
<ul><li><strong>Target version</strong> changed from <i>1.4.23</i> to <i>1.4.24</i></li></ul> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=64112009-10-11T18:35:04Zstbuehler
<ul><li><strong>Status</strong> changed from <i>Reopened</i> to <i>Fixed</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>Applied in changeset r2631.</p> Lighttpd - Bug #1937: Bad requesthttps://redmine.lighttpd.net/issues/1937?journal_id=64602009-10-14T14:37:12Zstbuehler
<ul><li><strong>Missing in 1.5.x</strong> set to <i>No</i></li></ul>