- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 25 Jul 2008 13:21:23 +0200
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- CC: ietf-http-wg@w3.org
Henrik Nordstrom wrote: > On sön, 2008-07-20 at 18:36 +0200, Julian Reschke wrote: > >> In the meantime I noticed that Content-Disposition really is a second >> rate header in RFC2616: > > 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" 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." > and "documented" in an appendix outside the actual definiiton of > HTTP/1.1, relying heavily on references to other RFCs and plenty of > warnings... 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. >> - more importantly, it doesn't appear in RFC 2068 at all (so how did it >> 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... 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. >> 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. > > I.e. what 2616 did, only that it used an appendix instead of a separate > document.. I would argue that an appendix is still part of the specification. > 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... 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. > Regards > Henrik BR, Julian
Received on Friday, 25 July 2008 11:22:11 UTC