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

Re: Issue 261: Check for requirements backing test cases, was: Comments on draft-ietf-httpbis-content-disp

From: Adam Barth <ietf@adambarth.com>
Date: Tue, 2 Nov 2010 12:19:26 -0700
Message-ID: <AANLkTin6YQStSyLkw7DYfuLPR41VmDuTpDkp0ZtCD3=d@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, httpbis <ietf-http-wg@w3.org>
On Tue, Nov 2, 2010 at 12:05 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 02.11.2010 19:36, Adam Barth wrote:
>>> That may be true for Chrome, but certainly *was* not true for IE when I
>>> first encountered the problem (trust me, I *was* sending UTF-8).
>> Indeed.  We don't need to slavishly copy IE.  We just need to stay
>> within some compatibility bound.  Usually we aim for somewhere between
>> 99.99 and 99.999% compatibility.  That usually isn't the same as the
>> unanimous intersection of all browser behavior.
> I like numbers. Can we *please* get numbers about actual use, and names of
> sites that use it?

Feel free to gather that data.  I probably won't have time to gather
it anytime soon because I'm busy fixing color profile support for

>>>> Now, of course, that would still leave us with UA-sniffing code on
>>>> servers until everyone implements the spec, but that at least sounds
>>>> implementable, unlike the current document, and puts us on a path to a
>>>> better future.
>>> Why do you keep saying the current document is not implementable? That's
>>> not
>>> helpful; the RFC 2231 encoding has three independant implementations
>>> (four
>>> if I'm allowed to count iCab).
>> The document has two pieces:
>> 1) filename
>> 2) filename*
>> What the document says about (1) isn't implementable by some number of
>> user agents.  What the document says about (2) is suboptimal, but
>> might be implementable if we can get jungshik on board (and whoever
>> the relevant decision makers are on the ie-team).
> Ah.
> So you say that the spec currently does not allow percent-unescaping (btw:
> the applicable specs never did, for the late comers to this discussion).
> Björn already pointed out that the filename is advisory only, and that a UA
> can already do what it wants to derive a final filename (mostly due to
> security considerations and local FS conventions). But I would agree that
> this is not optimal.
> Another way to address this is to recognize the problem, and suggest that
> servers that actually *want* a verbatim %-sequence in the filename will
> *have* to use the 2231/5987 encoding. If that's what's needed to get the
> missing UAs to implement filename*, I'll be more than happy to make that
> change.

I think it would be fine for this document to define a profile of the
filename parameter (and really the whole Content-Disposition header
field) for use by servers.  We'd say something like "if you want your
Content-Disposition header field to be understood by most user agents,
you'll probably want to generate it according to this grammar."  We
can also say "look, user agents do some nutty things outside of this
grammar, but that's not described by this document."

Maybe we've been miscommunicating this whole time, but that's what I
meant by option (2) at the beginning of this thread.

>>> From this discussion, it seems you care much more about (2) than about
>> (1).  One alternative is to remove the parts of the document that
>> discuss (1) since those appear to be more controversial than the parts
>> that discuss (2).
> That's an interesting thought. But I think one of the reasons for the
> missing interoperability was the confusion in the specs (is the token form
> allowed?, is RFC 2047 encoding allowed/required?, is 2231 allowed/required?)
> Etc. So I really believe that a single document that defines C-D for HTTP is
> needed, and this WG has decided long ago (issue 123) that we want to do just
> that.

The problem is that's not the document you've written.  You've written
a document that contains useful information for generating a
Content-Disposition header field.  However, the document doesn't
contain enough information about how to consume the header field.  If
I were to write a new user agent tomorrow, I'd need more information
than what's contained in this document.  Because no one's written that
down for me, I'll have to go reverse engineer some existing
implementations and make some guesses, which is the status quo that's
gotten us into the interoperability mess that we're in now.

Received on Tuesday, 2 November 2010 19:20:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC