Re: HTTP header suggestion/request

On Nov 9,  3:21pm, Larry Masinter wrote:
> Subject: Re: HTTP header suggestion/request
> # IMHO Larry's right.  More documents are being downloaded indirectly via
> # scripts or server modules every week.  There needs to be a method by
> # which the server or an agent can instruct a UA to save a certain filename
> # with the correct filetype and ask the user if he/she wants to view it.
> # RFC 1806 has such a structure and is one I believe belongs in HTTP/1.x.
>
> Wait!
>
> While I support using 'content-disposition' to suggest a file name,
> the ultimate choice of the file type & extension should be determined
> by using the Content-Type, not the suggested name.

But do you agree that at least the base part of the suggested file name should
at least be presented to the end user?

>
> Larry
>-- End of excerpt from Larry Masinter

Content-Type only provides a container for the attached data-stream.  The
mapping of extensions to applications and applications to Content-Type is
performed at the UA level.  Is this correct or did I miss something over the
last three years?

I think we are talking about the same thing, but I did not convey my thoughts
well enough.


Let's take a general case:

	Server A has a script which downloads a file after answering a
	few questions.

	Option 1 allows the user to view the file in a helper or plugin

	Option 2 allows the user to download the file and save it locally
	         for further processing

Option 1: Content-Disposition: inline

  - Most UAs today try and create some unintelligible file name based on the
    URL that can be contrary to the local OS naming convention.  This
    results in the helper apps or plugins aborting the download.

  - If the UA generates a valid temporary filename, the end user is left
    to make-up a reasonable file name so he/she can find it later.  If the
    user is part of a collaborative environment, it would be easier if the
    suggested name was used.  The file-type is created by the helper when
    the file is saved.

Option 2: Content-Disposition: attachment or file

  - The UA recognizes the Content-Type and looks up the appropriate file-type
    and creator, when required.  It then validates the suggested file name
    for the local OS convention and prompts the user where he/she would like
    to store this file.  Before prompting the user the UA makes any
    corrections, like changing the extension, to the suggested file name.

    Note: only the file name should be sent and not the entire path.

    Once the user acknowledges the file name and location, the UA creates the
    correct file-type and local file requirements on the users behalf.

  + The UAs I have tried will ignore Content-Disposition if the Content-Type
    is anything other than application/octet-stream.

Most of my work has been option 1, especially for files which are used in
a collaborative environment.  Although we are moving into option 2 for
larger files and tarred packages.


--
=============================================================================
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
-----------------------------------------------------------------------------
	Lesson learned by a user: "Beware geeks bearing GIFs"
=============================================================================

Received on Saturday, 9 November 1996 16:27:01 UTC