When trying to download mp3s via the Hijack web interface or via Mark's new XML thing, the filenames are truncated after an underscore and are saved with no file extension. IE works like normal.

Is this a Mozilla bug?

MMm... does the same thing here with Linux Mozilla-1.7.3-5 (Sarge).

It didn't used to screw up. Mozilla bug.

Cheers

I'm not so sure it's actually a bug, there is no official RFC for Content-Disposition in HTTP - it is defined in an RFC for MIME messages (RFC 1806). Most browsers generally support it though. Here is a header khttpd returns for a download request:

HTTP/1.1 200 OK
Connection: close
Accept-Ranges: bytes
Content-Length: 301449
Content-Type: audio/mpeg
Content-Disposition: attachment; filename=They Might Be Giants - Doris Cunningham.mp3

I have a suspicion that if all spaces in the filename were converted to underscores (like we do in the web interfaces) it would work fine in Mozilla.

I'll give that a try and we'll see.

Cheers

Yup, Mozilla seems to be too stupid to keep parsing the filename after the first space. But.. it does understand double-quotes for the filename, so I'm changing Hijack to enclose the filename inside double-quotes only for Mozilla. Other agents will continue to receive the raw filename as before. (I seem to recall double quotes being bad in some instances when this was originally implemented))

Fixed in Hijack v417, available shortly.

Cheers

Heh heh.. Now I know why the default has always been to NOT double-quote the filename here.. IE6 screws up when it is double-quoted!

No problem, though -- Hijack v417 does the correct thing for each of them.

Cheers

Way to go!

Does anyone know if Mozilla responds well to bug reports?

Thanks, Mark! I noticed this defect in Mozilla earlier when writing my web interface but didn't have the time to investigate fully.

Quote:
Does anyone know if Mozilla responds well to bug reports?

The reason I said it might not be a bug is because the Content-Disposition header that is used to suggest the filename to the browser is not a standard header in HTTP 1.0 or 1.1 - it is from the MIME standard, and browser writers can even ignore it completely if they like. Certainly Mozilla should have kept parsing to the end of the line, and IE should recognize double quotes, but both of them are supporting a de facto standard in their own way, like so so many other little quirks. Sucks donuts.

Ha.. this gets even funnier:

With Konqueror, a left click gives me the correct filename from the content-disposition header, sans underscores.

But a middle-click uses the URL path filename, *with* underscores.

What a riot!

Cheers