Subject: Re: Content-Disposition (new issue?)

From: Julian Reschke <[email-masked]>
Date: Sun, 20 Jul 2008 18:36:34 +0200

Hi,

So far, I didn't see any feedback on this.

In the meantime I noticed that Content-Disposition really is a second 
rate header in RFC2616:

- it isn't mentioned in "7.1 Entity Header Fields" 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.7.1>), and

- more importantly, it doesn't appear in RFC 2068 at all (so how did it 
get into the Draft Standard?)

Considering that, it's seems best to remove all mentions of C-D from 
Part 3, and to create a separate spec that describes the use of 
Content-Disposition within HTTP.

Feedback appreciated,

Julian

Julian Reschke wrote:
> 
> Julian Reschke wrote:
>> So I think we need to
>>
>> 1) s/1806/2183/g (this is editorial, methinks)
> 
> Done in <http://www3.tools.ietf.org/wg/httpbis/trac/changeset/269>.
> 
>> 2) Clarify that I18N is defined in by RFC2231
>>
>> 3) Specify a profile of RFC2231 that makes sense for 
>> Content-Disposition as used over HTTP (as opposed to mail), such as:
>>
>> 3a) No Continuations 
>> (<http://greenbytes.de/tech/webdav/rfc2231.html#rfc.section.3>)
>>
>> 3b) Support 
>> <http://greenbytes.de/tech/webdav/rfc2231.html#rfc.section.3>, but 
>> only use UTF-8 encoding in producers.
>> ...
> 
> and 4)
> 
> Copy over more of RFC2183, for instance "disposition=inline" (which I 
> think the major browsers understand).
> 
> An alternative to all this would be to throw out Content-Disposition, 
> and move it ("C-D as used as HTTP header") into a separate spec. If we 
> did that, would we want to make at a WG work item?
> 
> BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 20 Jul 2008 19:23:54 +0200

Julian Reschke wrote:

> Considering that, it's seems best to remove all mentions of C-D
> from Part 3, and to create a separate spec that describes the 
> use of Content-Disposition within HTTP.
 
> Feedback appreciated,

If that separate draft ends up with *deprecating* Content-Dispo
you could as well deprecate it in 2616bis, and be done with it.

Similar, if the separate draft would say "experimental" with a
pointer to the old RFCs, no new insights, you could also do it
in 2616bis.  Nothing forces you to say "standard" and fix it in
2616bis, just because you mention it for the IANA registration.

But if separate draft is no much work and clearer from your POV
go for it.

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Sun, 20 Jul 2008 19:41:46 +0200

> you could as well deprecate it in 2616bis, and be done with it.

No, that separate draft would *clarify* it, mainly describing which 
subset of RFC 2183 and RFC 2231 makes sense over HTTP.

> 2616bis, just because you mention it for the IANA registration.

I would want to have it on the standards track (so feedback from our ADs 
is needed).

> But if separate draft is no much work and clearer from your POV

It is some work, but somehow I've got the impression that the majority 
of the WG just doesn't care enough to enhance what RCF2616 currently 
says, so therefore I'm thinking about alternatives.

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 22 Jul 2008 01:30:11 +0200

> In the meantime I noticed that Content-Disposition really is a second 

Indeed. I assumed you alread knew this. It's very obvious from the way
2616 is written.. Content-Disposition is not officially part of
HTTP/1.1, only mentioned in RFC2616 as it is in widespread use so
implementers are aware what it is and how to best deal with it..

Quote from 2616:

  "Content-Disposition is not part of
   the HTTP standard, but since it is widely implemented, we are
   documenting its use and risks for implementors"

and "documented" in an appendix outside the actual definiiton of
HTTP/1.1, relying heavily on references to other RFCs and plenty of
warnings...

> get into the Draft Standard?)

I wasn't around, but a guess is due to security flaws in multiple
browser implementations at the time making it a hot topic...

> Content-Disposition within HTTP.

I.e. what 2616 did, only that it used an appendix instead of a separate
document..

I am perfectly fine with that, and also keeping that header outside
standards track. But I'll also bet that a number of people will argue
that since it's in widespread use it should be within the standard...

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jul 2008 13:21:23 +0200

>    documenting its use and risks for implementors"

Yep. However, it really does *not* document any risks: it just states 
that there are some, and the points to the Security Considerations of 
the RFC2183. See 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.15.5>:

"15.5 Content-Disposition Issues

RFC 1806 [35], from which the often implemented Content-Disposition (see 
Appendix 19.5.1) header in HTTP is derived, has a number of very serious 
security considerations. Content-Disposition is not part of the HTTP 
standard, but since it is widely implemented, we are documenting its use 
and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) 
for details."

> HTTP/1.1, relying heavily on references to other RFCs and plenty of

I think it's ok to refer to the MIME definition of Content-Disposition. 
What's relevant is to document what parts are useful and how they are 
used, and to state which profile of RFC2231 needs to be supported by 
clients.

> browser implementations at the time making it a hot topic...

Probably. It's still strange that we have it in RFC 2616, but not in RFC 
2068. Seems that a violation of the standards process to me.

> I.e. what 2616 did, only that it used an appendix instead of a separate

I would argue that an appendix is still part of the specification.

> that since it's in widespread use it should be within the standard...

Oh, it absolutely should be on the standards track; it's an essential 
feature. However, the current state of the specs (2616/2183/2231) makes 
it needlessly complicated to find out what needs to be implemented.

BR, Julian