Content-Disposition

I suggest the following change for Content-Disposition:

| 19.5.1 Content-Disposition

|     The receiving user agent SHOULD NOT respect any directory path
!     information present in the filename-parm parameter. The
|     filename SHOULD be treated as a terminal component only.
+     The filename MAY be modified in a way that the system will
+     correctly recognize the media type given in the Content-Type
+     header, i.e. by adding an appropraite file extension.

!            disposition-type = "attachment" | "inline" | disp-extension-token
+            disposition-parm = filename-parm | disp-extension-parm
+                      | creation-date-parm
+                      | modification-date-parm
+                      | read-date-parm
+                      | size-parm
                       | disp-extension-parameter

The new date fields of RFC 2183 could also be used in HTTP and are  
currently missing from HTTP.

I consider the fact that modification-data-parm is independent from Last- 
Modified a feature: Last-Modified can be used to indicate when the  
resource under this URL changed (i.e. date of upload to server), while  
the modification-date parameter explicitly refers to the modification  
date of the file offered for download (i.e. the file when the archive  
was compiled).

-    If this header is used in a response with the application/octet-
-    stream content-type, the implied suggestion is that the user agent
-    should not display the response, but directly enter a `save response
-    as...' dialog.

+    The disposition "inline" suggests that the user agent should try to
+    display the response directly. It may fallback to "attachment" if
+    it is unable to display the response or display it using a generic
+    viewing method (such as a hex viewer).
+
+    The disposition "attachment" suggests that the user agent should not
+    display the response, but directly enter a `save response as...'
+    dialog.
+
+    If no Content-Disposition is given, UAs usually makes a guess based
+    on the Content-type.

Rationale: It is not a good idea to use the file type to determine  
whether to display it inline. A UA could still start a hex viewer for  
application/octet-stream to display it inline in it's browser window.

On the other hand, if is bad if I get type "application/octet-stream"  
and filename "foo.gif" and don't know how to handle it, just because my  
system does not determine file types by extension.

I believe this is what the "disposition" information is actually for.
The assignments
  inline = display directly and
  attachment = save to disk
mostly agree with the definitions in RFC 2183.

Then, why not make it part of the official HTTP spec? If implemented  
correctly, it can be safe and useful.

And what about Content-Description?

--
Claus Andre Faerber <http://www.muc.de/~cfaerber/> Fax: +49_8061_3361
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E  25 56 69 A5 C6 A0 C9 DC

Received on Friday, 18 September 1998 06:30:08 UTC