Re: Using Content-Encoding and Content-Disposition together

On Aug 7, 12:27am, Klaus Weide wrote:
> 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.(?)
>
> By the way, is Content-Disposition really a response-header?
> It seems to make more sense to say it is an entity-header.
>
>         Klaus
>
>
>-- End of excerpt from Klaus Weide

In past mail conversations with Netscape developers, Netscape (up to 3.01, I
haven't tried 4.0) only recognizes the Content-Disposition header if and only
if the Content-Type is Octet-stream.  Otherwise the browser tries to make-up a
filename based on the basename of the current URL.

As for C-D in a multipart, I do not see where it is out of scope.  The headers
are in an alternate delivery mechanism that is supported by by the community.



							Kevin
--
=============================================================================
Kevin J. Dyer					Draper Laboratory  MS 23.
Email: <kdyer@draper.com>		        555 Tech. Sq.
Phone: 617-258-4962				Cambridge, MA 02139
FAX: 617-258-2121
-----------------------------------------------------------------------------
      "If the women don't find you handsome, they should       Red
       at least find you handy."                               Green
=============================================================================

Received on Thursday, 7 August 1997 06:12:25 UTC