[whatwg] Fakepath revisited

On Mon, Sep 7, 2009 at 4:24 AM, Alex Henrie <alexhenrie24 at gmail.com> wrote:
> Expecting developers to hack out a substring at all will only lead to
> more bad designs. For example, Linux and Mac OS allow filenames to
> contain backslashes. So if the filename was "up\load.txt" then
> foo.value would be "C:\fakepath\up\load.txt" which could easily be
> mistaken for "load.txt".

Unix also allows filenames to contain newlines, unprintable
characters, trailing whitespace, and strings of bytes that don't
represent any characters at all in common encodings.  Not to mention
that file extensions are often omitted.  If web authors aren't
prepared to deal with all those, then getting confused by backslashes
isn't going to be a huge additional problem, I imagine.  At least in
your case the script will be left with a valid Windows filename, even
if it's not the same one as on the user's filesystem.

> Also, I suspect that if the manufacturers of
> the affected routers aren't interested in releasing updates to make
> them work in non-fakepath browsers like Firefox, they may not be
> interested in releasing updates for them at all.

IIRC, the problem is that you can't upload the new firmware to the
router at all, so the manufacturer can't release an update to fix it.
It can only make sure it's fixed in new models.

> Essentially, you are choosing to trade long-term good design for
> short-term compatibility.

Browser vendors cannot sacrifice compatibility for long-term goals,
because their users will rebel.  Any standard that demands
incompatibility with existing content will be ignored by implementors,
as XHTML was, and thus useless to authors.  That's the fact of the
matter, whether we like it or not.  New APIs can be introduced, but
old ones can't be changed in incompatible ways.

Received on Monday, 7 September 2009 08:56:55 UTC