- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 16 Dec 2011 23:22:59 +0100
- To: Alex Rousskov <rousskov@measurement-factory.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2011-12-16 22:56, Alex Rousskov wrote: > On 12/16/2011 02:14 PM, Julian Reschke wrote: > >> OK, I did two more changes: >> >> - in the grammar, allow trailing semicolons; so that "100-continue;" >> isn't invalid (we have the same in Prefer) > > Any specific reason to allow that trailing semicolon? Seems like it > should not be allowed unless Expect is already commonly used that way. a) there's no harm b) it's a very easy mistake to make c) it doesn't introduce ambiguity d) for other header fields, we have evidence that parsers already do this For Expect:, I have no data, as it doesn't seem to be used for anything other than "100-continue". > I cannot find it right now, but I think there was some text in HTTPbis > that talked about "cleansing" of header fields before > comparing/interpreting them (folding, removing BWS, and such). If that > text is indeed there somewhere, does it allow an implementation to > remove bare semicolon before comparing? Before comparing what? > Finally, I expect some currently compliant implementations to fail > updated tests if a bare semicolon is allowed and must be ignored. Will those accept things like foo, 100-continue or foo; bar="q\ux,", 100-continue ? Best regards, Julian
Received on Friday, 16 December 2011 22:23:59 UTC