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

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.

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

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

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

Best regards, Julian

Received on Sunday, 7 November 2010 16:25:10 UTC