Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
draft-ietf-httpbis-content-disp-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Sean Turner |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Stewart Bryant |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the Yes position for Peter Saint-Andre |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for David Harrington |
2011-04-06
|
09 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Hilarie Orman. |
2011-04-05
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2011-04-05
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2011-04-05
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2011-03-28
|
09 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-03-28
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2011-03-28
|
09 | (System) | IANA Action state changed to In Progress |
2011-03-28
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2011-03-28
|
09 | Cindy Morgan | IESG has approved the document |
2011-03-28
|
09 | Cindy Morgan | Closed "Approve" ballot |
2011-03-28
|
09 | Cindy Morgan | Approval announcement text regenerated |
2011-03-28
|
09 | Alexey Melnikov | Ballot writeup text changed |
2011-03-28
|
09 | (System) | New version available: draft-ietf-httpbis-content-disp-09.txt |
2011-03-25
|
09 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2011-03-18
|
09 | David Harrington | [Ballot comment] I cleared |
2011-03-18
|
09 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss |
2011-03-17
|
09 | Cindy Morgan | Removed from agenda for telechat |
2011-03-17
|
09 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation. |
2011-03-17
|
09 | Alexey Melnikov | Ballot writeup text changed |
2011-03-17
|
09 | Alexey Melnikov | Ballot writeup text changed |
2011-03-17
|
09 | Sean Turner | [Ballot discuss] (updated based on RFC editor notes) #1) Sec 3.1 contains the following: Recipients MAY take steps to recover a usable field-value from … [Ballot discuss] (updated based on RFC editor notes) #1) Sec 3.1 contains the following: Recipients MAY take steps to recover a usable field-value from an invalid header field, but SHOULD NOT reject the message outright, unless this is explicitly desirable behaviour (e.g., the implementation is a validator). As such, the default handling of invalid fields is to ignore them. What's the default requirement? It needs to be reworded as follows: As such, implementations SHOULD ignore invalid field by default. |
2011-03-17
|
09 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to Discuss from No Objection |
2011-03-17
|
09 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2011-03-17
|
09 | Alexey Melnikov | Ballot writeup text changed |
2011-03-17
|
09 | Alexey Melnikov | Ballot writeup text changed |
2011-03-17
|
09 | Alexey Melnikov | Ballot writeup text changed |
2011-03-17
|
09 | Alexey Melnikov | Ballot writeup text changed |
2011-03-17
|
09 | Sean Turner | [Ballot discuss] (updated based on exchanges with author) #1) Sec 3.1 contains the following: Recipients MAY take steps to recover a usable field-value from … [Ballot discuss] (updated based on exchanges with author) #1) Sec 3.1 contains the following: Recipients MAY take steps to recover a usable field-value from an invalid header field, but SHOULD NOT reject the message outright, unless this is explicitly desirable behaviour (e.g., the implementation is a validator). As such, the default handling of invalid fields is to ignore them. What's the default requirement? It needs to be reworded as follows: As such, implementations SHOULD ignore invalid field by default. #2) Sec 4.3 contains the following: Thus, recipients SHOULD ensure that a file extension is used that is safe, optimally matching the media type of the received payload. Why isn't this MUST. An implementation that doesn't do this is then vulnerable to the attacks you just described. Under what circumstances is this a good idea? |
2011-03-17
|
09 | Stewart Bryant | [Ballot comment] "RFC 2616 defines the Content-Disposition response header field" I think that you need to say the Content-Disposition response header field of what. Same … [Ballot comment] "RFC 2616 defines the Content-Disposition response header field" I think that you need to say the Content-Disposition response header field of what. Same for Intro. ===== Changed from Discuss to Comment When the value contains path separator characters ("\" or "/"), recipients SHOULD ignore all but the last path segment. This prevents unintentional overwriting of well-known file system locations (such as "/etc/passwd"). ... or even intentionally over writing it - depending on your perspective. I spent a little time puzzling over the /etc/passwd case. Since /etc/ looked like the last path segment. However I think that you mean that the file will be stored in "some-default-directory-but-not-slash/etc/passwd". It would be useful to clarify this in the text with an example. Why is this a SHOULD and not a MUST given the security implications. ==== Surely the security section (or 4.3) needs to discuss file permissions as well as well known extension types. |
2011-03-17
|
09 | Stewart Bryant | [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss |
2011-03-17
|
09 | Sean Turner | [Ballot comment] #1) Sec 4.1 contains the following phrase: Furthermore note that the format used for ext-value allows specifying a natural language; It … [Ballot comment] #1) Sec 4.1 contains the following phrase: Furthermore note that the format used for ext-value allows specifying a natural language; It would greatly help to include an "natural language (e.g., );" #3) Sec 8.2: Should the registration template include: Related information: none #5) App D contains the following: [[fallbackbug: Firefox is known to pick the wrong parameter; a bug fix is scheduled for Firefox 5. --jre]] Is this supposed to be removed? |
2011-03-17
|
09 | Sean Turner | [Ballot discuss] (updated based on exchanges with author) #1) Sec 3.1 contains the following: Recipients MAY take steps to recover a usable field-value from … [Ballot discuss] (updated based on exchanges with author) #1) Sec 3.1 contains the following: Recipients MAY take steps to recover a usable field-value from an invalid header field, but SHOULD NOT reject the message outright, unless this is explicitly desirable behaviour (e.g., the implementation is a validator). As such, the default handling of invalid fields is to ignore them. What's the default requirement? It needs to be reworded as follows: As such, implementations SHOULD ignore invalid field by default. #2) Sec 4.3 contains the following: Thus, recipients SHOULD ensure that a file extension is used that is safe, optimally matching the media type of the received payload. Why isn't this MUST. An implementation that doesn't do this is then vulnerable to the attacks you just described. Under what circumstances is this a good idea? #3) Sec 4.1 contains the following: Header field values with multiple instances of the same parameter name are invalid. Is this a new requirement on HTTP headers or is this true of all HTTP headers? |
2011-03-17
|
09 | Sean Turner | [Ballot comment] #1) Sec 4.1 contains the following phrase: Furthermore note that the format used for ext-value allows specifying a natural language; It … [Ballot comment] #1) Sec 4.1 contains the following phrase: Furthermore note that the format used for ext-value allows specifying a natural language; It would greatly help to include an "natural language (e.g., );" #2) Sec 4.3 contains the following phrase: ... a natural language ... Could you provide and (e.g., ). I didn't parse what this was. #3) Sec 8.2: Should the registration template include: Related information: none #4) App C.4 contains a table listing browsers, without version #s this table isn't of much use it - or is it all version? #5) App D contains the following: [[fallbackbug: Firefox is known to pick the wrong parameter; a bug fix is scheduled for Firefox 5. --jre]] Is this supposed to be removed? |
2011-03-17
|
09 | Sean Turner | [Ballot discuss] #1) Sec 3.1 contains the following: Recipients MAY take steps to recover a usable field-value from an invalid header field, but … [Ballot discuss] #1) Sec 3.1 contains the following: Recipients MAY take steps to recover a usable field-value from an invalid header field, but SHOULD NOT reject the message outright, unless this is explicitly desirable behaviour (e.g., the implementation is a validator). As such, the default handling of invalid fields is to ignore them. What's the default requirement? It needs to be reworded as follows: As such, implementations SHOULD ignore invalid field by default. #2) Sec 4.3 contains the following: Thus, recipients SHOULD ensure that a file extension is used that is safe, optimally matching the media type of the received payload. Why isn't this MUST. An implementation that doesn't do this is then vulnerable to the attacks you just described. Under what circumstances is this a good idea? #3) Sec 4.1 contains the following: Header field values with multiple instances of the same parameter name are invalid. Is this a new requirement on HTTP headers or is this true of all HTTP headers? #4) Appendix D: Need normative reference for US-ASCII. |
2011-03-17
|
09 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded |
2011-03-17
|
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-16
|
09 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-16
|
09 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-16
|
09 | Alexey Melnikov | [Ballot comment] In answer to David's DISCUSS: 1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183 specifies Content-Disposition header … [Ballot comment] In answer to David's DISCUSS: 1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183 specifies Content-Disposition header field for email only. This draft is a standalone version for HTTP. 2) This document is not obsoleting/updating any other HTTPBIS WG I-D. 3) Yes, both filename and filename* are allowed. That is intentional (for backward compatibility) 4) The editor answered this, but there was a small edit in the document to add the cross reference. |
2011-03-16
|
09 | Alexey Melnikov | [Ballot comment] To answer to David's DISCUSS: 1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183 specifies Content-Disposition header … [Ballot comment] To answer to David's DISCUSS: 1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183 specifies Content-Disposition header field for email only. This draft is a standalone version for HTTP. 2) This document is not obsoleting/updating any other HTTPBIS WG I-D. 3) Yes, both filename and filename* are allowed. That is intentional (for backward compatibility) 4) The editor answered this, but there was a small edit in the document to add the cross reference. |
2011-03-16
|
09 | Peter Saint-Andre | [Ballot Position Update] Position for Peter Saint-Andre has been changed to Yes from Discuss |
2011-03-16
|
09 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-16
|
09 | Adrian Farrel | [Ballot comment] I have no objection to the publication of this document. There are a couple f small points that I think would benefit from … [Ballot comment] I have no objection to the publication of this document. There are a couple f small points that I think would benefit from attention first. --- Section 2 says that BNF from RFC 2616 is used. Section 3 metnions "ABNF". Is this the same (in which case please use consistent terminology) or different (in which case please supply a reference for ABNF). (See also Peter's Discuss --- Section 4.3 contains a number of bullets. The first one uses RFC 2119 language to specify behavior, but the remaining bullets use apple-pie language. Do you need to upgrade all bullets to RFC 2119? |
2011-03-16
|
09 | Peter Saint-Andre | [Ballot discuss] I have one question I'd like to discuss. The forthcoming documents from the HTTPBIS WG use ABNF as defined in RFC 5234. … |
2011-03-16
|
09 | Peter Saint-Andre | [Ballot Position Update] New position, Discuss, has been recorded |
2011-03-15
|
09 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-15
|
09 | Alexey Melnikov | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2011-03-14
|
08 | (System) | New version available: draft-ietf-httpbis-content-disp-08.txt |
2011-03-14
|
09 | David Harrington | [Ballot comment] 1) I agree with Stewart's DISCUSS. I found the discussion of the last segment of the filename to be confusing. 2) I agree … [Ballot comment] 1) I agree with Stewart's DISCUSS. I found the discussion of the last segment of the filename to be confusing. 2) I agree with Stewart's concern about some additional security considerations that are not documented. |
2011-03-14
|
09 | David Harrington | [Ballot discuss] 1) is this document meant to update or obsolete 2183 (or not)? Per appendix B, this document omits parameters specified in 2183. Is … [Ballot discuss] 1) is this document meant to update or obsolete 2183 (or not)? Per appendix B, this document omits parameters specified in 2183. Is this meant to obsolete those parameters? 2) "This specification is expected to replace the definition of Content- Disposition in the HTTP/1.1 specification, as currently revised by the IETF HTTPbis working group." Does this document obsolete/update the I-Ds being produced by httpbis? If so, which drafts? 3) Does the grammar in 4.1 allow both filename and filename* to be specified? 4) I think the statement " Senders MUST NOT generate Content-Disposition header fields that are invalid." should include a pointer to the specific rules about what is invalid. |
2011-03-14
|
09 | David Harrington | [Ballot Position Update] New position, Discuss, has been recorded |
2011-03-14
|
09 | Robert Sparks | [Ballot comment] Consider adding "At the time of publication of this document, " to the front of the sentence starting with the purl.org URL at … [Ballot comment] Consider adding "At the time of publication of this document, " to the front of the sentence starting with the purl.org URL at the end of Appendix D. Using a tool like purl.org helps make it easier to manage moving content around, but won't guarantee that that the content isn't a dangling reference or that it contains relative content in 20 years. |
2011-03-14
|
09 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-14
|
09 | Dan Romascanu | [Ballot comment] Why would Appendix C4 be removed at publication? I believe that it actually includes important information about the status of the implementations, and … [Ballot comment] Why would Appendix C4 be removed at publication? I believe that it actually includes important information about the status of the implementations, and clarifies the reasons of some of the choices made by editors and the WG. |
2011-03-14
|
09 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2011-03-14
|
09 | Stewart Bryant | [Ballot comment] "RFC 2616 defines the Content-Disposition response header field" I think that you need to say the Content-Disposition response header field of what. Same … [Ballot comment] "RFC 2616 defines the Content-Disposition response header field" I think that you need to say the Content-Disposition response header field of what. Same for Intro. |
2011-03-14
|
09 | Stewart Bryant | [Ballot discuss] When the value contains path separator characters ("\" or "/"), recipients SHOULD ignore all but the last path segment. This … [Ballot discuss] When the value contains path separator characters ("\" or "/"), recipients SHOULD ignore all but the last path segment. This prevents unintentional overwriting of well-known file system locations (such as "/etc/passwd"). ... or even intentionally over writing it - depending on your perspective. I spent a little time puzzling over the /etc/passwd case. Since /etc/ looked like the last path segment. However I think that you mean that the file will be stored in "some-default-directory-but-not-slash/etc/passwd". It would be useful to clarify this in the text with an example. Why is this a SHOULD and not a MUST given the security implications. ==== Surely the security section (or 4.3) needs to discuss file permissions as well as well known extension types. |
2011-03-14
|
09 | Stewart Bryant | [Ballot Position Update] New position, Discuss, has been recorded |
2011-03-14
|
07 | (System) | New version available: draft-ietf-httpbis-content-disp-07.txt |
2011-03-14
|
09 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-03-09
|
09 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2011-03-09
|
09 | Alexey Melnikov | Ballot has been issued |
2011-03-09
|
09 | Alexey Melnikov | Created "Approve" ballot |
2011-03-09
|
09 | Alexey Melnikov | [Note]: 'Mark Nottingham (HTTPBIS chair) is the document shepherd' added |
2011-03-09
|
09 | Alexey Melnikov | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Mark Nottingham (HTTPbis WG Chair). I believe this document is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? It has been reviewed by core WG members and browser implementers. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. Not all current implementations fully support the internationalisation features here (see the appendix). However, I believe this document represents the best we can do without more active vendor involvement, and it represents a significant improvement over the existing specification of this header. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Most of the work was done by Julian Reschke, but various implementers were involved in the discussion, as well as other WG members. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split. No dangling or downwards references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA Considerations section is present and in order. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? During Last Call, it was asserted that the draft should also specify error handling for browsers in detail. We improved some aspects of this in ways that were compatible with existing behaviour, but did not attempt to proactively specify additional error handling, as we didn't see broad engagement in the discussion from implementers. This resolution was not contentious. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are many existing implementations; see . Based on public statements and bug activity, we believe that implementations will continue to improve. |
2011-03-04
|
09 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2011-03-04
|
09 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2011-03-04
|
09 | Amanda Baber | IANA understands that, upon approval of this document, there is a single IANA Action that needs to be completed. In the Permanent Message Header Field … IANA understands that, upon approval of this document, there is a single IANA Action that needs to be completed. In the Permanent Message Header Field Names registry located at: http://www.iana.org/assignments/message-headers/perm-headers.html the Content-Disposition HTTP header field in the permanent HTTP header field registry will be updated as follows: Header field name: Content-Disposition Applicable protocol: http Status: standard Author/Change controller: IETF Specification document: [ RFC-to-be ] IANA understands that this is the only action that needs to be completed upon approval of this document. |
2011-02-28
|
09 | Amy Vezza | Last call sent |
2011-02-28
|
09 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)) to Proposed Standard The IESG has received a request from the Hypertext Transfer Protocol Bis WG (httpbis) to consider the following document: - 'Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-httpbis-content-disp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-httpbis-content-disp/ |
2011-02-28
|
09 | Alexey Melnikov | Placed on agenda for telechat - 2011-03-17 |
2011-02-28
|
09 | Alexey Melnikov | Last Call was requested |
2011-02-28
|
09 | Alexey Melnikov | State changed to Last Call Requested from AD Evaluation. |
2011-02-28
|
09 | (System) | Ballot writeup text was added |
2011-02-28
|
09 | (System) | Last call text was added |
2011-02-28
|
09 | (System) | Ballot approval text was added |
2011-02-28
|
09 | Alexey Melnikov | State changed to AD Evaluation from AD is watching::AD Followup. |
2011-02-26
|
06 | (System) | New version available: draft-ietf-httpbis-content-disp-06.txt |
2011-02-17
|
05 | (System) | New version available: draft-ietf-httpbis-content-disp-05.txt |
2010-11-23
|
09 | Alexey Melnikov | Draft Added by Alexey Melnikov in state AD is watching |
2010-11-12
|
04 | (System) | New version available: draft-ietf-httpbis-content-disp-04.txt |
2010-10-25
|
03 | (System) | New version available: draft-ietf-httpbis-content-disp-03.txt |
2010-09-22
|
02 | (System) | New version available: draft-ietf-httpbis-content-disp-02.txt |
2010-09-16
|
01 | (System) | New version available: draft-ietf-httpbis-content-disp-01.txt |
2010-09-03
|
00 | (System) | New version available: draft-ietf-httpbis-content-disp-00.txt |