Re: TICKET 259: 'treat as invalid' not defined

On 07.11.2010 21:32, Adam Barth wrote:
>> On 02.11.2010 03:56, Adam Barth wrote:
>>> ...
>>> The browser use case proceeds from the following premises.
>>>
>>> 1) Many servers send invalid messages to user agents.
>>
>> No data was provided that this is indeed the case for C-D.
>
> No data was provided that this isn't the case.  Given that we see
> invalid message everywhere else, common sense tells us that we will
> see invalid messages here too.

In the absence of data telling me something else, I'll assume that 
servers do sane things. I may be wrong. I just don't see why a server 
would *ever* send two disposition types, given it's a waste of bytes and 
that it doesn't cause the same thing to happen in different UAs.

> ...
>>> 3) If a new user agent wishes to compete in the market, that user
>>> agent needs to handle the invalid messages in the same way as the
>>> existing user agents.
>>
>> As my tests show, there is no "same" behavior right now. It's totally not
>> clear that this is a problem in practice.
>
> It is a problem in practice.

Why?

>>> Use case: Users benefit when there is competition among browser
>>> vendors.  Without specifying how to handle invalid messages, new user
>>> agents need to reverse engineer the behavior of existing user agents,
>>> making it more difficult to compete in the marketplace.
>>
>> My tests show that no, they do not need to compete.
>
> Of course user agents need to compete with each other for market
> share.  Your statement doesn't make any sense.

So you claim that user agents need to process invalid headers for market 
share. But they do not do the same thing. In the absence of a better 
explanation, my conclusion is that it may not matter.

>> Now that's a different issue as filename parameters containing "%" *are*
>> valid.
>>
>> Two UAs currently do not treat them per spec, and also do it in a currently
>> not well-documented way, and may even differ on the details.
>>
>> This is a problem tracked in
>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/245>; I added a warning
>> notice to the spec:
>>
>> "Note: Many user agents do not properly handle escape characters when using
>> the quoted-string form. Furthermore, some user agents erroneously try to
>> perform unescaping of "percent" escapes (see Appendix C.2), and thus might
>> misinterpret filenames containing the percent character followed by two hex
>> digits."
>>
>> We have heard from you that those UAs that currently percent-unescape are
>> unlikely to stop doing that, so all we can do is point out that there's a
>> problem. When I wrote the note mentioned above there was also no workaround
>> to recommend because those UAs did not implement the RFC 5987 which would
>> provide a workaround.
>>
>> Maybe we should expand the note though to say that RFC 5987 may be used as
>> workaround, as long as it's used in addition to "filename=".
>
> In that case, perhaps we should make including the % character invalid
> as the results are not predictable from the point of view of servers.

We currently have a warning. I would *love* to tell server implementors 
about a way to workaround this problem, but there isn't (for released 
versions of Chrome and IE). So what do you propose to tell senders? 
"%xx" is not allowed in filenames?

 From a spec writing point of view, I very much prefer to state that 
it's valid, but risky due to UA bugs.

Best regards, Julian

Received on Sunday, 7 November 2010 20:51:01 UTC