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

On 2011-09-06 07:33, Amos Jeffries wrote:
> ...
>> 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 problem is that regular software compliance updates do not happen 
everywhere.

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

It would, but for an edge case we thought it's used.

Do you have different data? Is anybody *producing* Etags with backslashes?

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

That's interesting.

> 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

I think it'll break for If-Match -- clients might not be able to PUT to 
resource when guarding against lost updates.

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

I'm not pushing for it, but there's clearly a problem right now in that 
what the spec says isn't implemented by most servers.

One way to address this would be to leave the definition alone, but to 
warn producers that if they use escapes they may be in trouble. (Another 
thing we need to consider is whitespace handling in quoted strings...)

Best regards, Julian

Received on Tuesday, 6 September 2011 07:36:45 UTC