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

Re: #327: Expect syntax

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 17 Dec 2011 01:02:21 +0100
Message-ID: <4EEBDC0D.7010601@gmx.de>
To: Alex Rousskov <rousskov@measurement-factory.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2011-12-17 00:48, Alex Rousskov wrote:
> 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.

Will those servers process




? These were valid before already.

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

Yes, they should be equivalent.

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

Yes, so it doesn't make any difference in practice.

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

There's some truth to this, but then maybe we shouldn't have started to 
fix the grammar in the first place.

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

Well, the main issue is that other expectations never have been tried; 
in particular expectations using all these syntactic features.

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

I agree it's in the gray area. On the other hand, we want to clarify 
extension points etc. Expect: certainly is a header that never has been 
tested a lot.

Best regards, Julian
Received on Saturday, 17 December 2011 00:03:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:54 UTC