Re: #306: does etag value really use quoted-string

On 06/09/11 01:27, Julian Reschke wrote:
> On 2011-09-05 15:17, Yves Lafon wrote:
>> On Thu, 1 Sep 2011, Julian Reschke wrote:
>>
>>>
>>> 2.3. ETag
>>>
>>> The ETag header field provides the current entity-tag for the
>>> selected representation. An entity-tag is an opaque validator for
>>> differentiating between multiple representations of the same
>>> resource, regardless of whether those multiple representations are
>>> due to resource state changes over time, content negotiation
>>> resulting in multiple representations being valid at the same time,
>>> or both. An entity-tag consists of an opaque quoted string, possibly
>>> prefixed by a weakness indicator.
>>>
>>> ETag = entity-tag
>>>
>>> entity-tag = [ weak ] opaque-tag
>>> weak = %x57.2F ; "W/", case-sensitive
>>> opaque-tag = DQUOTE *etagc DQUOTE
>>> etagc = %x21 / %x23-7E / obs-text
>>> ; VCHAR except double quotes, plus obs-text
>>
>> How about removing %x5C as well '\' and note that implementations were
>> not handling \ as a quoted-string as it was defined before, leading to
>> non-interoperable parsing of such ETags.
>> ...
>
> The reason I didn't do it is that I really don't believe \ is
> non-interoperable in practice, as the clients really do not treat the
> (most?) etags as quoted strings but as opaque values; in which case
> there is no problem in practice...
>

I am also struggling to understand what the interoperability problem 
here is that can't be fixed with regular software compliance updates.

The broken pieces are already non-compliant with RFC 2616 quoted-string 
definitions. So no problem making anything existing suddenly 
non-compliant by keeping them. Quite the opposite, removing 
quoted-string makes all the existing un-escaping software non-compliant.
  I'm thinking Squid here where we have rolled out quoted-string escape 
handling into the recent stable releases of all popular distros to meet 
the RFC 2616 compliance checklist. This unescaping will be hitting the 
Enterprise sector in the next upgrade cycle.


There was an analysis posted of UA agents behaviour earlier, which is 
useful info but seems irrelevant to any visible problem. UA is handling 
only its own cache. Middleware which is opaque will be less efficient, 
but work. It is the servers alone which will have to handle a mix of 
correctly unescaped and opaque traffic inbound. Especially if escaping 
was originally done wrong by the itself or its mirrors (\Z \G etc).
  Worst case there seems to be inefficiency and excess server load on 
the broken machinery itself.

If I have missed something, perhapse one of you pushing for removal of 
quoted-string can explain for me?

AYJ

Received on Tuesday, 6 September 2011 05:34:51 UTC