W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] "C:\fakepath\" in HTML5

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 24 Mar 2009 17:34:45 +0100
Message-ID: <op.ura1n7l564w2qv@annevk-t60.oslo.opera.com>
On Tue, 24 Mar 2009 17:23:20 +0100, Alex Henrie <alexhenrie24 at gmail.com>  
wrote:
> On Tue, Mar 24, 2009 at 8:15 AM, Anne van Kesteren <annevk at opera.com>  
> wrote:
>> Microsoft did. And nothing changed in well over a year. (They say so in  
>> a comment on the blog post.)
>
> Perhaps the buggy code was only sent to IE, and Firefox got more
> reasonable code. If the firmware had working code for both Firefox and
> the latest stable version of IE, that would explain the company's
> reluctance to see a problem.

Maybe, maybe not.


> Another reason might be that this firmware only runs on old routers
> and no firmware updates are being released for it, so few users would
> run into the problem with trying to update firmware. What firmware was
> this, exactly?

I have no idea. It just indicates issues are out there.


> Example: A site lets a user upload a file and write some comments
> associated with that file. On the browser side, a new input element is
> dynamically created with the name and id "Notes for
> C:\fakepath\upload.txt". On the server side, the server receives
> "upload.txt" and looks for "Notes for upload.txt" to match. It of
> course is not there because the programmer had no idea that the
> browser would be adding appending a fake path in JavaScript but not in
> HTTP.

I don't see how this example could work. Anyway, relying on .value to just  
return a filename is a bogus assumption anyway since lots of user agents  
out there are not doing that.


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Tuesday, 24 March 2009 09:34:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT