- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 17 Dec 2011 22:12:05 +0100
- To: Willy Tarreau <w@1wt.eu>
- CC: Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 2011-12-17 08:40, Willy Tarreau wrote: > Hi Julian, > > On Sat, Dec 17, 2011 at 01:02:21AM +0100, Julian Reschke wrote: >> Will those servers process >> >> ,100-continue >> >> or >> >> 100-continue, >> >> ? These were valid before already. > > Speaking for haproxy, the second one will work, because it splits header > values on the commas and trims the spaces. So the first above will be > considered as an empty expectation followed by a 100-continue (but haproxy > only considers the first Expect value) and the second one is OK. > > Haproxy's processing of Expect is incomplete and almost unused, so it > should not be seen as a reference implementation at all (!). However > the semi-colon after 100-continue was not supposed to happen in 2616, > which is why I think other implementations might get trapped. That is true, but it *is* an edge case. The alternative is to make the grammar different from Prefer:; or to change Prefer: as well. In practice, most parsers that understand ";" separated parameters allow "empty" parameters (see, for instance, my Content-Disposition test cases). We can pretend this is wrong, or we can try to bring a bit more sanity to this. In any case, the fact that existing implementations might trip over something that (for Expect!) will only happen in test cases doesn't seem to be a big problem to me. Best regards, Julian
Received on Saturday, 17 December 2011 21:13:21 UTC