Content-Disposition suggested text changes

On Tue, 5 Aug 1997, Koen Holtman wrote:

> David W. Morris:
> >
> >On Mon, 4 Aug 1997, Yaron Goland wrote:
> >
> >> I also agree that the second one is correct. We should not confuse
> >> content-encoding with the actual file. After all I could easily be
> >> dealing with a server where I, a server side app, send the server a
> >> plain text file with a content-disposition of .txt and the smart server
> >> knowing it is talking to a UA that supports compression decides to
> >> compress on the fly.
> >
> >Me too ... because as an application which created a compressed file
> >wanted it to stay compressed when the UA received it.  
> 
> Well, this is not really a case where we have to agree on what the most
> correct way is.  19.6.1 documents current practice, it is not
> normative, so if anything, it should give hints about what to do with
> current browsers.
> 
> >I recently 
> >received a file of xx.txt.gz ... had the UA ungzip it to show it and
> >then save it as xx.txt.gz but uncompressed.
> 
> I just sent gzipped content with
> 
>  Content-Type: text/html
>  Content-Encoding: gzip
>  Content-Disposition: attachment; filename="fname.html.gz"
> 
> to a Netscape 3.0.1 on Unix.  On saving, the save as filename box
> suggested "fname.html", and the unencoded content got saved (the URL
> was something without fname.html in it).
> 
> Now for the fun part: I then sent the same gzipped html with
> 
>  Content-Type: text/html
>  Content-Disposition: attachment; filename="fname.html.gz"
> 
> and now Netscape displayed and saved the unzipped version, as
                                           ^^^^^^^^
(I think you mean "un-gunzipped" here )
> expected, but it _also_ suggested a filename of "fname.html".
> Apparently there is something in there which chops the .gz from a
> filename no matter what.
> 
> Based on this, I am very reluctant to add informational text to the
> spec about how you should use content-disposition and content-encoding
> together.
> 
> Koen.

I propose the following changes.  Maybe they can accomodate your
reservations?

Replace (last paragraph before 19.6.1):
            A number of other headers, such as Content-Disposition and
            Title, from SMTP and MIME are also often implemented (see
            RFC 2076 [37]).

with:
            A number of other headers, such as Message-Id and 
            Content-Disposition, from Mail and MIME are also often 
            implemented (see RFC 2076 [37]).

[Title is not a header from Mail or MIME; also, SMTP does not define 
headers.]

Replace (first paragraph of 19.6.1):
            The Content-Disposition response-header field has been
            proposed as a means for the origin server to suggest a
            default filename if the user requests that the content is
            saved to a file.  This usage is derived from the definition
            of Content-Disposition in RFC 1806 [35].

with:
            The Content-Disposition entity-header field in a response is
            understood by some user agents as a means for the 
            origin server to suggest a default filename if the user 
            requests that the content is saved to a file.  This usage is 
            derived from the definition of Content-Disposition in 
            RFC 1806 [35].

[ This leaves it open how C-D would be used in a request ]

Near the end of 19.6.1, replace:
            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.
 
with:
            If this header is used in a response with the
            application/octet-stream content-type, the implied
            suggestion is that the user agent should enter a 
            `save response as..' dialog, offering the suggested filename
            (after possible modification) as default.

[ The previous formulation gives the impression that it is normal
behavior to "display" application/octet-stream content, and also that
in absense of the C-D header a dialog is entered more "indirectly"
(whatever that means).]

Finally, add the following at the end:

            According to RFC 1806, "the suggested filename should be used
            as a basis for the actual filename, where possible", but it
            may need modification for reasons of security, filesystem
            restrictions, and local conventions.

	    If a response message also has a Content-Encoding
            entity-header, the filename parameter should suggest an
            appropriate name for the data obtained after removing the
            encoding(s) from the entity-body.
	    On systems with a convention for naming files in a given
	    encoding, for example a ".gz" filename suffix for the
	    gzip content-coding, user agents should add such a suffix 
            (if not already present) if the content is saved in
            encoded form;  some user agents also remove such a suffix 
            from the suggested filename if it is present, if they choose
            to save the content in decoded form.


   Klaus

Received on Thursday, 7 August 1997 11:21:38 UTC