idnits 2.17.1 draft-faerber-http-content-disp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 367 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2119], [RFC2183], [RFC1806], [RFC2068]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1998-09-25) is 9338 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ABNF' is mentioned on line 97, but not defined ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) -- Duplicate reference: RFC2183, mentioned in 'RFC2183', was also mentioned in 'RFC1806'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Claus Andre Faerber 2 draft-faerber-http-content-disp-00 1998-09-25 3 Intends to Update: RFC 2068/draft-ietf-http-v11-rev Expires: 1999-04-25 5 Use of the Content-Disposition header with HTTP. 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 13 Internet-Drafts are draft documents valid for a maximum of six months 14 and may be updated, replaced, or made obsolete by other documents at 15 any time. It is inappropriate to use Internet-Drafts as reference 16 material or to cite them other than as "work in progress." 18 To learn the current status of any Internet-Draft, please check the 19 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 20 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 21 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 22 ftp.isi.edu (US West Coast). 24 This memo is an individual submission and not a product of an IETF 25 Working Group. 27 Copyright Notice 29 Copyright (C) The Internet Society (1998). All Rights Reserved. 31 Abstract 33 [RFC2183] introduces a Content-Disposition header field for Internet 34 Mail Messages to transmit presentation information as well as a 35 suggested file name for saving the content to disk and the file's 36 date information. 38 All of this information is missing from HTTP entities [RFC2068]. 39 However, there is nothing that would prevent the use of the Content- 40 Disposition header with this HTTP. 42 Without being standard, the Content-Disposition header has already 43 been introduced by some software products. [HTTP1.1-REV] documents 44 this practice, based on [RFC1806]. 46 This memo also extends the specification to cover [RFC2183] and 47 corrects the common abuse of the Content-Type header to cover 48 presentation information. 50 Table of Contents 52 Status of this Memo 53 Copyright Notice 54 Abstract 55 Table of Contents 56 Definitions 58 1 Format of the Content-Disposition Header 60 2 Interpretation of the Disposition Types and Parameters 61 2.1 The Inline Disposition type 62 2.2 The Attachment Disposition Type 63 2.3 The Filename Parameter 64 2.4 The Creation-Date, Modification-Date, Read-Date and Size 65 parameters 66 2.4.1 Relation of Modification-Date to Last-Modified 67 2.4.2 Relation of Size and Content-Length/Content-Range 69 3 Use within HTTP Messages 70 3.1 Use within HTTP multipart messages. 71 3.1.1 Use on individual parts of the multipart messages 72 3.1.2 Use on the top level multipart message 74 4 Security Considerations 76 Appendix 77 A Examples 78 B Acknowledgements 80 References 81 Author 82 Full Copyright Statement 84 Definitions 86 This memo uses the Augmented BNF defined in [RFC2234] as well as some 87 definitions from [RFC822]. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 The reader should be familiar with [RFC2068] and [RFC2183]. 94 1 Format of the Content-Disposition Header 96 [RFC2183] defines the Content-Disposition header as follows (modified 97 for HTTP and to align with [ABNF]): 99 disposition = "Content-Disposition" *WSP ":" LWSP 100 disposition-type LWSP 101 *( LWSP ";" LWSP disposition-parm LWSP ) 103 disposition-type = "inline" 104 / "attachment" 105 / extension-token 106 ; values are not case-sensitive 108 disposition-parm = filename-parm 109 / creation-date-parm 110 / modification-date-parm 111 / read-date-parm 112 / size-parm 113 / parameter 115 See [RFC2183] for more details on definitions of the parameters 116 defined. Please note that while in mail messages there MAY be CFWS 117 within the header field, this is not true for HTTP headers, which 118 only allows linear white space and line folding but no comments. 120 2 Interpretation of the Disposition Types and Parameters 122 As HTTP differs from email, there are also small semantic differences 123 for the meaning of the disposition-types. 125 Future documents defining other disposition-types may also define 126 whether and how they are to be interpreted within HTTP. Registration 127 of new disposition-types SHOULD use the procedures described in 128 [RFC2183, section 9]. HTTP disposition-types share the registry with 129 MIME. 131 Unknown types should be handled as "attachment". See [RFC2183, 132 section 2.8] for details. 134 2.1 The Inline Disposition type 136 An HTTP entity should be marked "inline" if it is intended to be 137 displayed automatically upon receipt of the HTTP message, e.g. in the 138 web browser's window. 140 This is the default. (However, the fall back mechanism described 141 below MAY be implemented in a way that it is only used if the entity 142 is not marked explicitly as "inline".) 144 User agents MAY fall back to "attachment" (see section 2.2) if they 145 feel unable to display the entity received (e.g. because they can't 146 handle the Content-Type). They MIGHT also use a generic viewer, such 147 as a hex viewer. 149 2.2 The Attachment Disposition Type 151 Entities can be designated "attachment" to indicate that their 152 display should not be automatic, but contingent upon some further 153 action of the user. The HTTP user agent might instead present the 154 user a request to save the entity as a file to disk ("download"). 156 2.3 The Filename Parameter 158 The sender of an entity-body may want to suggest a filename to be 159 used if the entity is stored in a separate file. If the receiving 160 HTTP User Agent writes the entity to a file, the suggested filename 161 should be used as a basis for the actual filename, where possible. 163 NOTE: This is particularly useful if an entity is transmitted by 164 something like a CGI programme, as the request URL might not contain 165 the actual or an appropriate filename in this case. 167 It is important that the receiving HTTP user agent not blindly use 168 the suggested filename. The suggested filename SHOULD be checked (and 169 possibly changed) to see that it conforms to local filesystem 170 conventions, does not overwrite an existing file, and does not 171 present a security problem (see Security Considerations below). 173 On systems that determine file types as part of the file name (e.g. 174 an "extension"), the filename SHOULD be modified according to the 175 Content-Type header, so that the system will correctly determine the 176 file type. 178 For a more complete discussion of the filename parameter, see 179 [RFC2183, section 2.3]. 181 2.4 The Creation-Date, Modification-Date, Read-Date and Size parameters 183 These headers have the same semantics as described in [RFC2182, 184 sections 2.4 to 2.7]. 186 For the relation to some "similar" HTTP headers, see the sections 187 2.4.1 and 2.4.2 in this memo. 189 2.4.1 Relation of Modification-Date to Last-Modified 191 The Modification-Date parameter has similar semantics to the Last- 192 Modified HTTP message header. 194 As a general rule, Last-Modified is a generic HTTP modification date, 195 possibly used for cache validation, while the Modification-date 196 parameter is exclusively used to specify the modification date for a 197 file created when the HTTP entity is saved to disk. 199 As a consequence, the date given in the Modification-Date parameter 200 MAY be different from that in the Last-Modified header, e.g. if a 201 file is presented for download, the Last-Modified header MAY contain 202 the date at which the file was made available under this URL 203 ("upload"), while the Modification-Date parameter MAY contain the 204 date at which the file was originally created. 206 2.4.2 Relation of Size and Content-Length/Content-Range 208 Unlike the Content-Length and Content-Range header, which refer to 209 the size of the encoded entity-body (or message-body), the Size 210 parameter specifies the length in octets of the unencoded/decoded 211 (if a Content-Encoding is used) entity transmitted, as a hint for the 212 User Agent when saving the entity to a file. 214 For the difference of message-body and entity-body, see [RFC2068, 215 section 4.3]. 217 As a result, the Size parameter MAY always be used, even if the 218 Content-Length header MUST NOT. 220 3 Use within HTTP Messages 222 The Content-Disposition header MAY be used with any HTTP response or 223 request that contains or references to entities as defined in 224 [RFC2068, section 7]. 226 The Content-Disposition header is an extension to the entity header 227 list defined in section [RFC2068, section 7.1]. 229 For POST and PUT requests, only the disposition-type "attachment" 230 SHOULD be used. 232 3.1 Use within HTTP multipart messages. 234 3.1.1 Use on individual parts of the multipart messages 236 If the Content-Disposition header is used on individual parts of a 237 HTTP multipart/* response, the semantics of [RFC2183] should be used 238 if the entity is displayed as a whole. 240 However, the semantics described in this memo apply if the definition 241 of the multipart type suggest individual display of the individual 242 parts as separate top-level entities (e.g. "server-push" [FIXME: 243 reference]). 245 The Content-Type header SHOULD NOT be used for multipart/byte-range 246 messages. 248 3.1.2 Use on the top level multipart message 250 The Content-Disposition header can also be used on top level 251 multipart entities. In this case, the header applies to the multipart 252 message as a whole. 254 4 Security Considerations 256 See [RFC2183, section 5] for a complete discussions for the security 257 impacts of the Content-Disposition header. 259 Appendix 261 A Examples 263 In this sections, lines starting with C: are sent by the client, 264 while those starting with S: are sent by the server. 265 Only relevant headers are shown. 267 A.1 Downloading a file through a CGI URL. 269 C: GET /cgi-bin/download.cgi?product=foo;ver=1.2;lang=de;pack=tgz HTT 270 P/1.1 271 C: Host: www.example.com 272 C: 273 S: 200 HTTP/1.1 OK 274 S: Content-Type: application/tar 275 S: Content-Encoding: gzip 276 S: Content-Length: 123456 277 S: Content-Disposition: attachment; filename="foo-1.2.tar"; 278 S: modification-date="Sat, 01 Aug 1998 00:00:00 +0000"; size=234567 279 S: Last-Modified: Mon, 03 Aug 1998 08:23:23 +0200 280 S: 281 S: ...data 283 B Acknowledgements 285 Many parts of these document are taken more or less literally from 286 [RFC2183] by R. Troost, S. Dorner, and K. Moore. 288 This document has also been inspired by the discussion in the IETF 289 HTTP-WG. 291 References 293 [HTTP1.1-REV] Fielding, R., Gettys, J., Mogul, J. C., Frystyk, H., 294 Masinter, L., Leach, P., Berners-Lee, T., "Hypertext Transfer 295 Protocol -- HTTP/1.1", September 1998 (Expires March 1999), Internet 296 Draft , WORK IN PROGRESS (Will 297 Update RFC 2068). 299 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 300 Messages", August 1982, STD 11, RFC 822. 302 [RFC1806] Troost, R., Dorner, S. "Communicating Presentation Information 303 in Internet Messages: The Content-Disposition Header", June 1995. RFC 304 1806 (Updated by RFC 2183). 306 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Berners-Lee, 307 T., "Hypertext Transfer Protocol -- HTTP/1.1", January 1997, 308 RFC 2068. 310 [RFC2183] Troost, R., Dorner, S., Moore, K., "Communicating Presentation 311 Information in Internet Messages: The Content-Disposition Header 312 Field", August 1997. RFC 2183. 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", March 1997, RFC 2119. 317 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 318 Specifications: ABNF", November 1997, RFC 2234. 320 Author 322 Claus Andre Faerber 323 Mitterfeldstrasse 20 324 83043 Bad Aibling 325 Germany 327 Fax: +49-8061-3361 329 E-Mail: cfaerber@muc.de 331 Note: Please write the author's name with the correct diacritic 332 marks where possible, i.e. Claus André Färber in HTML. 334 Full Copyright Statement 336 Copyright (C) The Internet Society (1998). All Rights Reserved. 338 This document and translations of it may be copied and furnished to 339 others, and derivative works that comment on or otherwise explain it 340 or assist in its implementation may be prepared, copied, published 341 and distributed, in whole or in part, without restriction of any 342 kind, provided that the above copyright notice and this paragraph are 343 included on all such copies and derivative works. However, this 344 document itself may not be modified in any way, such as by removing 345 the copyright notice or references to the Internet Society or other 346 Internet organisations, except as needed for the purpose of 347 developing Internet standards in which case the procedures for 348 copyrights defined in the Internet Standards process must be 349 followed, or as required to translate it into languages other than 350 English. 352 The limited permissions granted above are perpetual and will not be 353 revoked by the Internet Society or its successors or assigns. 355 This document and the information contained herein is provided on an 356 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 357 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 358 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 359 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 360 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 362 Internet Draft 363 Expires 1999-03-25 365 Claus