Bug#600211: closed by Mike Hommey <mh at glandium.org> (Re: Bug#600211: iceweasel: should ignore "Content-Disposition: attachment" HTTP response header)

[Vincent Lefevre]

reopen 600211
retitle 600211 iceweasel should ignore "Content-Disposition: attachment" HTTP response header when the user requests that such a URL be opened
thanks

On 2010-10-14 20:10:45 +0200, Mike Hommey wrote:
> On Thu, Oct 14, 2010 at 07:20:48PM +0200, Vincent Lefevre wrote:
> > No, you didn't read the bug report. RFC 2183 is
> > 
> >   Communicating Presentation Information in Internet Messages:
> >                                             ^^^^^^^^^^^^^^^^^
> >   The Content-Disposition Header Field
> > 
> > thus for mail only (see also the contents of the RFC: it's about
> > *mail* user agents). Therefore this RFC is *not* relevant.
> 
> And there is *no* other RFC relevant to Content-Disposition.

Actually the HTTP/1.1 RFC (RFC 2616) talks about it:

  19.5.1 Content-Disposition

  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.

So, the main goal is to provide a default filename if the user
*requests* that the content be saved to a file. But assume that
the user explicitly opens such a URL...

The RFC also says:

  The receiving user agent SHOULD NOT respect any directory path
  information present in the filename-parm parameter, which is the
  only parameter believed to apply to HTTP implementations at this
  time. The filename SHOULD be treated as a terminal component only.

This doesn't apply here.

  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.

This paragraph intends to mean that if the content-type is not
application/octet-stream, the normal behavior would be to display
the response (if the type is supported by the browser, of course).
If the normal behavior were to display a "Save as" dialog with the
Content-Disposition header, the RFC wouldn't have said anything
about application/octet-stream in particular.

> The current behaviour of Iceweasel has been implemented explicitely
> with this RFC in mind, BTW.

Even though RFC 1806 could be transposed to HTTP, differences
between mail and web should be taken into account:

First, while in mail, one can have either "inline" or "attachment"
type, in HTTP only "attachment" is allowed (RFC 2616). Behind that,
the goal in HTTP is to provide a default filename when the user
*requests* to save the file (there's also the application/octet-stream
thing...).

Then RFC 1806 says: "Bodyparts can be designated `attachment' to
indicate that they are separate from the main body of the mail
message, and that their display should not be automatic, but
contingent upon some further action of the user."

By "should not be automatic", it means that:
  1. if the user opens a mail, then the attachment should not be
     displayed automatically;
  2. but if the user opens the attachment itself, then the attachment
     should be displayed.

With HTTP this could be:
  1. if a web page contains a reference to a URL with the
     Content-Disposition header, the corresponding URL contents
     should not be displayed automatically (otherwise automatical
     display normally occurs with img, object, iframe, etc.);
  2. but if the user opens such a URL directly (e.g. by typing the
     URL in the address bar), the contents should be displayed.

I would say that even in case 1, the file should be displayed
automatically (if not served as application/octet-stream), according
to RFC 2616. But Iceweasel is wrong in case 2 anyway.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)