W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: The robustness principle, as view by user agent implementors (Re: Working Group Last Call: draft-ietf-httpbis-content-disp-02)

From: Adam Barth <w3c@adambarth.com>
Date: Sun, 3 Oct 2010 14:03:05 -0700
Message-ID: <AANLkTi=F5Xq=WyxjRRDj9cFcKB8jJpjLXbAmqofL9cxt@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Sun, Oct 3, 2010 at 1:47 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 03.10.2010 22:30, Adam Barth wrote:
>> ...
>> Concretely, my proposal is that the specification should not forbid
>> user agents from %-decoding the value of the filename parameter.
>> Julian has agreed that neither Internet Explorer nor Chrome is going
>> to stop %-decoding the filename parameter anytime soon.  Forbidding
>> user agent from processing these messages in this way is fiction.
>> ...
>
> Implementing %-unescaping here is a bug.

That depends what you mean by "a bug."  One operative definition of a
bug is something the implementor wants to change.  You've gotten clear
feedback from one implementor that this bug is WONTFIX, which means
it's not a bug at all.

> I agree it's unlikely to disappear from IE and Chrome anytime soon, so a
> warning is probably a good idea.
>
> I do not believe we can do more than that, because
>
> (a) the 4 other UAs tested do the right thing, and
>
> (b) there's no other way to deliberately send filenames containing these
> character sequences.

The problem with that is your forbidding user agents from implementing
a behavior they're refusing to remove.  That means the spec does not
reflect reality.

>> Now, I'm fine with forbidding servers from generating %-encoded
>> values.  In fact, I believe that would be desirable.  However, just
>> because we forbid servers from generating the values does not mean
>> that we must also forbid user agents from consuming them.
>
> I'd be more than happy recommending something else, if there was a
> "something else" we can recommend.

You don't have to define what user agents do in this case.  That's
fine.  I object to your requiring them to do something they aren't
going to.

>> ...
>> The problem is your change proposal focuses on uncovering the set of
>> messages with the same meaning in all semantics.  While that is of
>> interest to servers (generators), that's not of particular interest to
>> user agent implementors, as explained before.  Instead, user agent
>> implementors are interested in the largest set of messages generated
>> by at least one server that can be interpreted with a single semantic
>> theory.
>> ...
>
> I'm sure they are interested in that. But I bet they are also interested in
>
> - unambiguous parsing,
> - consistency,
> - code reuse (between header fields),
> - and compatibility with other UAs.

Yes.  These are all desirable.

> C-D is a mess, we can all agree on this. RFC 5987 and this ID are an attempt
> to make things better. My main goal is to get to a situation where servers
> can emit C-D headers with filenames containing "arbitrary" characters from
> the Unicode character set (minus whitespace, control, path delims, whatnot)
> without having to do UA sniffing.

I fully support that.  I agree that this document is very useful to
server operators who wish to generate these headers.  However, the
document, as written, is over-broad in that it forbids user agents
from consuming some headers.

Please reduce the scope of the document to align it with your goals.

> To get there, we need IE/Chrome/Safari to implement RFC2231/5987, or invent
> something new everybody is willing to accept. So far I haven't seen a
> serious alternative proposal.
>
> Once everybody implements RFC 5987, broken support for "filename" just
> doesn't matter anymore, because you can always can use the new encoding
> ("filename*"). But unfortunately we aren't there yet.

That might be true for folks generating the Content-Disposition
header, but folks consuming the header will still need to consume the
"broken" filename header for a long time.

Please open your mind to considering the constraints faced by browsers.

Adam
Received on Sunday, 3 October 2010 21:10:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:28 GMT