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

On Sun, Nov 7, 2010 at 8:24 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> OK, although everything that can be said about this *has* been said, I'll
> repeat my p.o.v. here because this is the only mailing list thread specific
> to issue 259.
>
> 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.

>> 2) Many existing user agents have some behavior for these invalid
>> messages.
>
> Yes.
>
>> 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.

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

>>>  b) security: what the security impact of having different notions of
>>> 'invalid' here may be, and
>>>  c) interoperability: likewise, the interop impact.
>>
>> The largest interoperability problems here are the different user
>> agents handle invalid messages differently.  For example, today, it's
>
> No, the largest interop problem is different handling of *valid* header
> fields, and lack of agreement how to handle I18N.
>
>> unpredictable how user agents will interpret a filename parameter with
>> a % character.  That part of the protocol is less useful to servers
>> because the results are not predictable.
>
> 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.

Adam

Received on Sunday, 7 November 2010 20:33:21 UTC