W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: #327: Expect syntax

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Fri, 16 Dec 2011 16:48:26 -0700
Message-ID: <4EEBD8CA.1010208@measurement-factory.com>
To: Julian Reschke <julian.reschke@gmx.de>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 12/16/2011 03:22 PM, Julian Reschke wrote:
> 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

I am sure some servers that can grok "100-continue" will fail to
recognize "100-continue;" as equivalent and respond with 417. Granted,
many of those servers are not compliant in other Expect-related ways,
but I do not think "no harm" is a 100% valid assumption in this case.

> b) it's a very easy mistake to make

Agreed, on both counts: easy and mistake.

> c) it doesn't introduce ambiguity

It kind of does. Is "100-continue" equivalent to "100-continue;" and
"100-continue;;;;;"? On an intuitive level, they should be equivalent,
but I see no explicit rules that make them equivalent, especially since
we say that 100-continue does not have parameters.

> d) for other header fields, we have evidence that parsers already do this

but I am guessing there is no evidence that senders send bare semicolons
in Expect headers.

> For Expect:, I have no data, as it doesn't seem to be used for anything
> other than "100-continue".

And that is one of the reasons making this header more complex is more

>> 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?

Comparing with other [cached] headers (for Vary and such) or, in this
case, comparing with the list of supported extensions (which is usually
just 100-continue).

>> 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

Yes, some will handle the above (and worse) because we already test them
for those cases :-)

Again, I understand that this is a very minor issue that is unlikely to
cause serious problems. It feels strange to defend a "do not change
unless there is a problem" principle in an HTTPbis effort, but I am not
trying to insist on reversing this change.

Thank you,

Received on Friday, 16 December 2011 23:48:59 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:26 UTC