155949 - Not compliant to RFC 2231 in parsing http header Content-Disposition

Status: VERIFIED DUPLICATE of bug 162765

(Core :: Networking: HTTP, defect)

Description

[Jungshik Shin]

Reference:

http://lxr.mozilla.org/seamonkey/source/xpfe/components/xfer/src/nsStreamTransfer.cpp#108

My reading of this code indicates that Mozilla is not compliant to 
RFC 2231 when parsing Content-Disposition header of HTTP response. 
Without any regard for decoding RFC 2231 encoded value of
filename parameter, Mozilla is blindly  using the value of 
filename parameter (whether it's a plain US-ASCII, a valid RFC 2231-encoded
international - meaning non-ASCII- string, or an ILLEGAL 8bit -
non-ASCII - string).

On the other hand, Mozilla mailnews header parsing code IS compliant to RFC 2231 
(see mimemoz2.cpp file). Something similar to what's been done in
mimemoz2.cpp has to be done for http header parsing as well. 
 
However, fixing this bug would have absolutely NO effect until
bug 62760 is fixed. As of Mozilla 1.0, 'filename' parameter
is completely ignored when Mozilla suggests a filename to
use for saving.

Comment 1

[Jungshik Shin]

FYI, below is the quote from RFC 2231 (http://www.faqs.org/rfcs/rfc2231.html)
:


4.  Parameter Value Character Set and Language Information

   Some parameter values may need to be qualified with character set or
   language information.  It is clear that a distinguished parameter
   name is needed to identify when this information is present along
   with a specific syntax for the information in the value itself.  In
   addition, a lightweight encoding mechanism is needed to accommodate 8
   bit information in parameter values.

   Asterisks ("*") are reused to provide the indicator that language and
   character set information is present and encoding is being used. A
   single quote ("'") is used to delimit the character set and language
   information at the beginning of the parameter value. Percent signs
   ("%") are used as the encoding flag, which agrees with RFC 2047.

   Specifically, an asterisk at the end of a parameter name acts as an
   indicator that character set and language information may appear at
   the beginning of the parameter value. A single quote is used to
   separate the character set, language, and actual value information in
   the parameter value string, and an percent sign is used to flag
   octets encoded in hexadecimal.  For example:

        Content-Type: application/x-stuff;
         title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A

   Note that it is perfectly permissible to leave either the character
   set or language field blank.  Note also that the single quote
   delimiters MUST be present even when one of the field values is
   omitted.  This is done when either character set, language, or both
   are not relevant to the parameter value at hand.  This MUST NOT be
   done in order to indicate a default character set or language --
   parameter field definitions MUST NOT assign a default character set
   or language.

The relevant part in mimemoz2.cpp is at

http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimemoz2.cpp#369

Comment 2

[Jungshik Shin]

I was wrong to say that this bug depends on 62760. 
Mozilla does understand and take care of filename parameter
when Content-Disposition has US-ASCII only filename parameter
without '*'. That is, the following works well. 

Content-Disposition: attachment; filename=file1.jpg

However, this does not work:

Content-Disposition: attachment; filename*=us-ascii'file1.jpg' 

Comment 3

[Jungshik Shin]

RFC 2616(http 1.1) has the following to say about Content-Disposition header:
(http://www.faqs.org/rfcs/rfc2616.html)

------
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 [35].

        content-disposition = "Content-Disposition" ":"
                              disposition-type *( ";" disposition-parm )
        disposition-type = "attachment" | disp-extension-token
        disposition-parm = filename-parm | disp-extension-parm
        filename-parm = "filename" "=" quoted-string
        disp-extension-token = token
        disp-extension-parm = token "=" ( token | quoted-string )

   An example is

        Content-Disposition: attachment; filename="fname.ext"

   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.

   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.

   See section 15.5 for Content-Disposition security issues.
-------------

It does not refer to RFC 2231 but to RFC 1806/2183 where C-D was first defined.
However, it is obvious that
RFC 2231(which specified the way non-ASCII chars. are encoded in parameters
of MIME header) is applicable to C-D header in MIME in general
(because RFC 2231 explicitly updates RFC 2183), which in turn
implies that C-D header in http should follow RFC 2231 as well. 

Comment 4

[Jungshik Shin]

mailnews/mime/src/mime/mimehdrs.cpp has two functions 
MimeHeaders_get_parameter() and MIME_StripContinuations()
that I need to use in xpfe/components/xfer/src/nsStreamTransfer.cpp,
but it's not clear how to do that without making it dependent on
the entire mailnews or mime module.

Comment 5

[Jungshik Shin]

adding two in bug 162765 to CC list. 
IMHO, bug 162765 has to be made a duplicate of this. 

Comment 6

[Darin Fisher]

-> bz

Comment 7

[Boris Zbarsky [:bzbarsky]]

Dupping the other way, since this bug is littered with information that is
easily available in the RFC...

*** This bug has been marked as a duplicate of 162765 ***

Comment 8

[Boris Zbarsky [:bzbarsky]]

Needless to say, please do _not_ paste chunks of the RFC into bug 162765.

Comment 9

[John Unruh]

Verified dupe.