"file://" determines content type using suffix of symlink target, not of symlink itself




5 years ago
a year ago


(Reporter: greg-mozilla-bugzilla, Unassigned)


29 Branch

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [necko-would-take])



5 years ago
Type into URL bar

foo.html is a symlink to foo.php (both in the same directory)

Prior to my most recent Firefox update, this would render the file as HTML.

Now (v29.0.1), a dialog appears asking what application should be used to open foo.php; i.e. Firefox has resolved the symlink (to a presumably unknown type).

Comment 1

5 years ago
Confirmed that a hard link (as opposed to a symlink) still works as before.

Not clear why you would want hard links and symlinks to behave differently in this respect. Specifically, a URL is "a way of fetching" a resource, and it seems appropriate to be able to deliver the same object (URI?) via different URLs, possibly with different semantics.

Comment 2

5 years ago
In other words, whilst it may be necessary to resolve the symlink for other purposes (internally to the file-scheme handler), this should not (effectively) "change the URL" (to the front end). Exactly as if the http scheme were being used: a web server might resolve a local symlink (for example to check the file's real location with respect to the document tree), but the client would not be able to tell this from the response.
What is the last version of Firefox that works as expected on your system ?

Comment 4

5 years ago
I'm not sure. It was certainly no earlier than v3.6.2 (the last actual installer I can find, but this may not be very helpful). Preferences>Advanced>Update>Show Update History is blank. Is there a log I can look at somewhere? (This is on Mac OS X 10.6.8.)
ok, this is no recent change then ?
Component: File Handling → Networking: File

Comment 6

4 years ago
I can't tell based on the above, only that it isn't ancient.

Comment 7

3 years ago
Any argument against comment #1 and comment #2?
Whiteboard: [necko-would-take]
You need to log in before you can comment on or make changes to this bug.