Re: Content-Disposition next steps

On Wed, Dec 1, 2010 at 1:00 PM, Julian Reschke <> wrote:
> On 01.12.2010 20:50, Adam Barth wrote:
>> On Wed, Dec 1, 2010 at 3:12 AM, Mark Nottingham<>  wrote:
>>> Adam, do you have a proposal?
>> Yeah.  Please find my proposal below.  It's certainly not beautiful,
>> and it likely needs more polish, but it should be a starting point.
>> ...
> before I look at the details, I'd like to understand the intent.

Thanks for seeking to understand instead of jumping to conclusions.  :)

> You're saying this reflects roughly what Chrome is doing. Thanks for writing
> this down.
> But exactly *why* would we consider this for the spec (I assume as
> recommended error recovery?)?

Oh, I thought we discussed this before.  From my perspective, the
current spec is optimized for server operators.  In particular, it's
helpful if you'd like to generate the Content-Disposition header.  I
raised the issue that user agent implementors might like information
about how to consume the Content-Disposition header.  We then had a
long discussion about why the optimal generation instructions and
consumption instructions might not be identical.

I think, then, Mark suggested that we could include that information
in an appendix that user agents could optionally implement, if they
were so inclined.  One important constraint is that the consumption
requirements agree with the rest of the spec on well-formed headers
(i.e., on those that meet the generation requirements).

If it's helpful for you to think about this information as recommended
error recovery, that's fine with me.  When consuming the
Content-Disposition header, it's not especially important to know
whether the header is well-formed (i.e., generated in accordance to
the generation requirements).

> I note that you have handling of RFC2047-style encoding in there. That's
> something only Chrome and Firefox are doing, so I'd like to understand why
> you think it's needed, and whether you think Opera/Safari/Konqueror/IE
> should implement that (given the fact that changes the semantics of values
> that are valid).

Yeah, I wasn't sure whether to include the RFC2047 encoding.  I
certainly wouldn't recommend that servers generate Content-Disposition
headers using that encoding.  However, if I were writing a new user
agent today, I might well include RFC2047 support.  It boils down to a
cost/benefit analysis.  Some comments in the Chrome code indicate that
there are servers that do generate RFC2047-encoded Content-Disposition
headers, so there's at least some benefit.

One thing that might make sense is to demarcate those instructions as
again optional, that is an optional piece of the optional error
recovery, if you like.


Received on Wednesday, 1 December 2010 21:15:00 UTC