Content-Disposition

I suggest the following change for Content-Disposition, which obviously  
is still based on the now obsolete RFC 1806:

| 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.

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:48:20 UTC