Re: #327: Expect syntax

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

   ,100-continue

or

   100-continue,

? 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