RE: Factoring out Content-Disposition (i123), was: Content-Disposition (new issue?)

Julian Reschke wrote:
> Brian Smith wrote:
> > I'm thinking of writing a [patch] for Firefox that decodes the 
> > Content-Disposition filename parameter as escaped UTF-8 if 
> > it is not RFC2231-encoded. I am interested in your test cases
> > that demonstrate IE's
> 
> Well, that would make the parsing non-compliant with the 
> specs. Are you aware of any pages that actually use that format?

When building test cases based on some KB articles I found today, I did
finally find some bad behavior of IE in the following situations:

* When the filename parameter is longer than 150 bytes (as few as 17+
encoded characters), the filename gets truncated and otherwise mangled. (In
your upcoming Content-Disposition draft, you might want to provide some
advice on minimum/maximum file name lengths.)

* When the filename has a non-ASCII extension, IE doesn't decode the
filename. 

Because of these two issues, I'm not sure it is worthwhile to try to get
Firefox to handle Content-Disposition in a way that is consistent with
Internet Explorer. I will wait to see if IE8 beta 2 removes the above two
limitations and/or supports RFC 2231.

I didn't reproduce the locale-sensitivity part of the problem but I found
some KB articles about it:

   http://support.microsoft.com/kb/436616/ja (Japanese)
   http://support.microsoft.com/kb/943570/ja (Japanese)
   http://support.microsoft.com/kb/895084/ko (Korean)
   http://support.microsoft.com/kb/832930    (English)
   http://support.microsoft.com/kb/816868    (English)
   http://support.microsoft.com/kb/933133    (English)

KB436616 is a support article for ASP.NET. It says should use RFC2231
encoding for Japanese filenames, but acknowledges that no version of
Internet Explorer supports RFC2231. Instead, you can try to encode the
filename using percent-encoded UTF-8; however, sometimes Internet Explorer
will decode the filename using Shift-JIS instead of UTF-8. You can configure
ASP.NET 2.0 to encode the filename in a different encoding (Shift-JIS in
this case) to work around this problem, but there is no mechanism provided
to detect what encoding IE will use to decode.

KB943570 is a support article for Internet Explorer 6.0 and 7.0 on Windows
XP/Vista/2003. It also acknowledges the problem but doesn't discuss RFC2231
at all. The suggested workarounds are: Do not use non-ASCII characters in
filenames; configure your (ASP.NET 2.0) server to encode filenames using
Shift-JIS instead of UTF-8. No other workarounds are presented, and no
advise is offered for determining what encoding Internet Explorer will use
for decoding.

It looks like IE always uses the same encoding for Content-Disposition that
it uses for query strings; when "Send UTF-8 URLs" is checked, it will use
UTF-8 for Content-Disposition and will encode URLs in a RFC3987-compliant
manner; otherwise, it will use the user's selected default encoding for
query strings and Content-Disposition, and it will not be compliant with
RFC3987 unless the user's default encoding is UTF-8. 

It looks like Content-Disposition, like Content-Location, is something that
applications should avoid whenever possible.

(The issues with the Link header field are best described in another
thread.)

Regards,
Brian

Received on Monday, 18 August 2008 04:09:41 UTC