1568707 - File name (and extension) of file to download is parsed too strictly from Content-Disposition: attachment; filename=... header value, meaning file extension goes missing

Status: RESOLVED DUPLICATE of bug 1440677

(Core :: Networking, defect)

Description

[Duncan]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Visit: https://portal.infinitylegal.net/help/help.aspx

And many/most files download with no extension being picked up (saves as .txt file mainly).

In other browsers (tested: G. Chrome, Edge, Vivaldi), extensions correctly picked up and saved OK.

Actual results:

Have to guess the extension (or open it in say Notepad or Notepad++) and "see" the top of file to see if it's a document, spreadsheet or PDF (or text) file.

Expected results:

Extension should be correctly picked up.

(Could be poor html on site!) However, it works correctly in Chrome, Edge and Vivaldi.
Therefore very much looks like a Firefox bug.

Comment 1

[Peter Magyari (Desktop QA)]

Hi Duncan,

I was able to reproduce the issue on Firefox 68.0.1 and Firefox Nightly 70.0a1.
I'm assigning a component in order to involve the development team in reviewing it.

Thank you for reporting!

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[:Gijs (he/him)]

Slightly more explicit steps:

1. open https://portal.infinitylegal.net/help/help.aspx
2. click "Parameters" heading on bottom left
3. click "Release & ILUpdate notifications" on the main part of the page

ER:
file gets saved with an extension

AR:
file doesn't get saved with an extension

This server behaves... very badly. It sends text/plain as mimetype for everything, even the above PDF file.

It sends the following content-disposition header:

Content-Disposition: attachment; filename=KB Release and ILUpdate notifications.pdf

I don't know if the RFC is the best we have here (Anne?), but if so the RFC specifies that this is bogus, per https://tools.ietf.org/html/rfc6266#section-4.1 defining the filename as a "token | quoted-string". This clearly isn't a quoted string. Looking for the definition of token, at https://tools.ietf.org/html/rfc2616#section-2.2 this is defined as a set of ascii without any separators, with separators defined as:

       separators     = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

"SP" is code for "space" and as is obvious above, there are spaces in the filename. So our parser drops everything after "KB". Combined with the bogus mimetype, we end up with sad behaviour.

Anyway, fat lot of good that does us when Blink/Webkit do something else here. I dunno if there's something more recent than the RFC that specifies some other parsing algorithm, or if Chrome/Edge have documented exactly what they're doing here, but I guess it's possible to be more lenient here depending on what other tokens (if any) are supposed to be supported here. Kershaw, do you have ideas?

It'd probably be useful to have a web platform test for this, though I'm not sure how easy it'd be to write one...

The parsing code seems to live in https://searchfox.org/mozilla-central/source/netwerk/protocol/http/HttpBaseChannel.cpp#688 and https://searchfox.org/mozilla-central/rev/c7e8bc4996f979e5876b33afae3de3b1ab4f3ae1/netwerk/base/nsNetUtil.cpp#2624 so going to move this over to networking-land.

Comment 4

[Anne (:annevk)]

Duplicate of bug 1440677, right? (Might want to move that into Networking too I suppose.)

Comment 5

[:Gijs (he/him)]

Sure.