Re: Using Content-Encoding and Content-Disposition together

Klaus Weide <kweide@tezcat.com> wrote:
>On Wed, 6 Aug 1997, Foteos Macrides wrote:
>> Foteos Macrides <MACRIDES@SCI.WFBR.EDU> wrote:
>> >koen@win.tue.nl (Koen Holtman) wrote:
>> >>[...]
>> >>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.
>> >
>> >	That section references only RFC 1806, which describes the
>> >"attachment" and "inline" disposition types.  My recollection of
>> >a long-ago message from Lou is that Netscape based its implementation
>> >on the file upload RFC's "file" disposition type.  What is the
>> >appropriate disposition type to use in HTTP Content-Disposition
>> >headers and META elements, and can information about that be included
>> >in 19.6.1?
>> 
>> 	I tracked down Lou's message (appended) and was remembering
>> it correctly.  So, how about some current practice guidance/hints
>> about that?
>>[...]
>> From: Lou Montulli <montulli@netscape.com>
>> Subject: Re: HTTP header suggestion/request
>> 
>[ ... ] 
>> The following use should work when returned from a CGI script:
>> 
>> Content-disposition: file; filename=foo.exe
>> 
>> The Navigator only uses the filename parameter, everything
>> else in the header is currently ignored.
>[ ... ]
>
>RFC 1808 and also draft-moore-mime-cdisp-01.txt say this:
>
>   Disposition parameters are valid for all dispositions.  (In contrast
>   to [RFC 1521] content-type parameters, which are defined on a per-
>   content-type basis.) Thus, for example, the `filename' parameter
>   still means the name of the file to which the part should be written,
>   even if the disposition itself is unrecognized.
>
>So it seems that Netscape's client follows the RFC in that regard (or did
>so, at the time of writing).
>
>Use of Content-Disposition in file uploads is a different topic, I think.
>If a file upload uses this header, it is probably within a 
>multipart/form-data structure, and thereby out of scope for the HTTP
>protocol.(?)

	The point was that current RFC-defined disposition types are
"attachment", "inline", and "form-data" (RFCs 1806 and 1867), and new,
as yet undefined disposition types were anticipated in RFC 1806.  I
had (probably mis-)interpreted Lou's message to be suggesting "file"
for the then new use of Content-Disposition as an HTTP server reply
header to indicate a "suggested output file name" in cases of save to
disk or download operations being performed by the UA for the reply
body.  "attachment" is fine for that case, and a disposition type is
included purely for integrity of the header's syntax.


>By the way, is Content-Disposition really a response-header?
>It seems to make more sense to say it is an entity-header.

	The Netscape innovation of using a Content-Disposition HTTP
reply header is very useful in the cases for which the last symbolic
element of the RequestURI is not a good basis upon which a UA can
concoct (sp?) a suggested output file name, e.g., because that element
is a script name, or the last element of PATH_INFO for a script.

	I see no reason to restrict that functionality to replies
with a binary Content-Type, and it isn't restricted to that case
in Lynx.

	I can't think of a reason for the UA to pay attention to
anything more than the filename=value parameter in a Content-Disposition
HTTP reply header.  Based on the Content-Type reply header, the
Content-Encoding reply header if present, and the context in which
the UA sent the request, the UA has everything it needs to use or
"doctor" the value appropriately and securely for the platform on
which the UA is running, as it does otherwise for the last symbolic
element of the RequestURI.  That includes stripping or adding any
compression "suffix tokens" from the suggested output file name
based on whether or not the context of the request lead to an
uncompression of a gzipped or Unix compressed reply.  The released
versions of Lynx aren't doing such stripping or adding, but I added
that yesterday in a field test code set.

	Details of an HTTP Content-Disposition reply header beyond
a filename=value parameter might become important someday, but not
for just setting a suggested (default) output file name which a user
can edit before actually using it.

	draft-moore-mime-cdisp-01.txt is an update of RFC 1806 and
does not appear be taking RFC 1867 (file upload) into account (does
not reference it, nor discuss the "form-data" disposition type), nor
the use discussed in Section 19.6.1 for HTTP/1.1.  The last-modified
parameter in the cdisp draft might be relevant, but HTTP has its
own explicit header for that.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Thursday, 7 August 1997 08:55:51 UTC