388305 - Content type not recognized from corrupted content-disposition

Status: RESOLVED INCOMPLETE

(Firefox :: File Handling, defect)

Description

[Honza Bambas (:mayhemer)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4pre) Gecko/20070524 BonEcho/2.0.0.4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4pre) Gecko/20070524 BonEcho/2.0.0.4pre

Installed AllPeers extension, nightly build version 0.70dev.200707160230 with support for external torrents.

We overlay the Open dialog for the "application/x-bittorrent" file type to let the user download torrent files using the extension. We add new XPCOM category "ext-to-type-mapping": "torrent" to "x-bittorrent" that helps identifying files by extension when opening with file:/// URL.

When clicking the provided URL you can see a link DOWNLOAD (http://www.torrentreactor.to/torrents/download_449214) that leads to a torrent file. The response of the request is:

Status=OK - 200
X-Powered-By=PHP/5.2.1
Last-Modified=Tue, 10 Jul 2007 13:28:11 GMT
Cache-Control=post-check=0, pre-check=0, no-store, no-cache, must-revalidate,
post-check=0, pre-check=0
Expires=Thu, 19 Nov 1981 08:52:00 GMT
Pragma=no-cache
Content-Type=application/x-bittorrent
content-disposition=attachment; filename="[TorrentReactor.to] - Led Zeppelin -
Discography - 320K.torrent "
Content-Length=27692
Connection=close
Date=Tue, 10 Jul 2007 13:28:11 GMT
Server=lighttpd/1.5.0

Please note the trailing space (char 0x20) in the content-disposition header, filename part. This is IMO the only reason why recognition of the content type fails. On line 627 in nsExternalHelperAppService.cpp call to GetFilenameAndExtensionFromChannel returns the fileName and fileExtenson with trailing space (char 0x20). Our extension overlay callbacks are not called when clicking the DOWNLOAD link.

I don't exactly understand why Content-type header is not used to recognize the content type and instead the file extension is used.


Reproducible: Always

Comment 1

[Boris Zbarsky [:bzbarsky]]

Honza, is this still an issue?  The link in comment 0 seems to be 404...

As far as I know, we would use the type _and_ the extension to get MIME info, if that's what the bug is about...

Comment 2

[Honza Bambas (:mayhemer)]

Attachment: Screenshot

I can reproduce it, I setup a file on my testing server whom path is w/o an extension (https://secure.mayhemer64/testBadDisposition/somefile) and has set following headers:

content-disposition: attachment; filename="a file name.html "
content-type: text/html

When I click the link "somefile" it opens a save as dialog and claims it is a "HTML " file.

Content of the file is not a valid HTML, just some plain text.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Yes, but the question is what sort of helper we offer.  The Firefox dialog is pretty moronic and just uses the extension in its user-facing text to talk about what "kind" of file it is, but under the hood we do lookups by MIME type.

So the question is, can you reproduce the original issue where something is handling the MIME type but not getting the data?  Or did I misunderstand comment 0?

Comment 4

[Honza Bambas (:mayhemer)]

I am not sure if there is really some issue at all, but to describe it the problem is that mime type bound to an extension from file name in a content-disposition header is preferred to mime type from a content-type header. So, when you register a content type handler for a mime type it won't get a chance to handle it when the file extension in a disposition header is squired somehow. But perhaps this might be wanted preference I am not aware of.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> the problem is that mime type bound to an extension from file name in a
> content-disposition header is preferred to mime type from a content-type
> header.

Preferred where, exactly?  I'm not aware of any code like that we have, and if we have some it's a pretty big deal.

If you don't send a filename param in the testcase in comment 2, do you get a dialog that suggests your browser as the app to handle with?  I'd check myself, but you put that file on a server I can't access...

Comment 6

[Honza Bambas (:mayhemer)]

It is locally running IIS server.

After more testing I found out that stupid IIS overrides Content-type header to application/octet stream for a file w/o an extension even when I explicitly define it. So I added a mime type mapping and then it sends correct text/html type. With this fix the mime type selected is correct (not taken from the extension) and the save as dialog shows "Firefox document" from now.

However, it looks like what I'm doing with my server is not reproducing the original problem. Problem might be hidden somewhere in nsExternalHelperAppService::GetFromTypeAndExtension.

When there is time left, I will try again with some testing extension (or allpeers directly) exactly as described in comment 0 and let you know.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Sounds like a plan.

Comment 8

[Honza Bambas (:mayhemer)]

Releasing this bug for now.  It doesn't seem this would be a wide issue.

However, simplest would be to create an xpc-shell test that creates a content handler and a server handler that adds a space after the content-disposition's name value.

Good first or second bug.