When I am using a form containing <input id="myFile" type="file" runat="server" /> to upload a file, my server-side code only sees the filename without the full path when using Firefox, while it works just fine in IE.
Is it possible to retrieve the full file path server-side in this case?
You cannot. Actually, only IE gives this information which isn't important for the server in most cases. Neither FF nor Opera, at least, provide this info.
[UPDATE] Also tried with Safari, still no path... Somebody reported that Chrome might provide the info, although being a beta, that might change...
Perhaps you might need them in some intranet cases. In such case, you might ask the user to paste the path in a secondary input field... Not very friendly, but at least they will know they provide the info.
Actually, I know some people needed this info for some reasons, so they used JavaScript to pick up the path from the file input field and put it in an hidden field. FF developers found it was insecure (you can learn a lot from a simple path... like the login name of the user!) so prohibited such usage in FF3, making some people angry against this release...
References: Firefox 3's file upload box mentioned in Firefox 3 annoyance: Keying-in disabled in file upload control ...; also File input box disabled leads to great usability problem, among many other ones.
You can never be sure of getting a full filepath or even a reliable filename or content-type submitted in a file upload file. Even if you get a full filepath you don't know what the path separator character is on the client's operating system, or whether a file extension (if present) denotes anything at all.
If your application requires the filepath/filename/content-type of a submitted file for anything more than giving the user a default title for the item uploaded, it's doing something wrong and will need fixing.
I already stated this in a comment, but I think it bears repeating.
Microsoft opted to make the file control give the entire path to the file for use in intranet applications.
The HTML specification only makes mention of what the value should contain in one spot:
User agents may use the value of the
value attribute as the initial file
name.
However, they also have examples of what the multipart/form-data encoding should look like, and it doesn't contain the file path.
In other words, IE is breaking the standard and you can't rely on other browsers, even later versions of IE, to support it.
Related
I'm specifically curious about Windows, but answers about different OS are interesting too.
Afaik in URLs a specific PDF page can be indicated by adding a #page=<page number> field. According to the URI specification, fields (using the #<field> syntax) and queries (using the ?<key>=<value> syntax) should be possible. However, URIs of the form file:///path_to_document.pdf#page=20 or file:///path_to_document.pdf?page=20 didn't work for me, Windows is interpreting the whole string as a path, which it then can't find.
Is there any way to accomplish this? I couldn't find anything online.
When calling files from the Operating System there are rules that are system based. So calling a file from OS needs a certain syntax, that needs quoting for some characters, so these work, whatever the default PDF handler may be:-
That default handler may include a different page switch syntax such as exe -page ## filename.
When using a URL you need a URL handler, so this will work in Windows
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" "file:///C:/Apps/PDF/poppler/%2333.pdf#page=20"
The URL can be on a LAN server and windows will often fiddle with the usage of \ and / but not aways accept both. So the rule is "use quotes" AND replace system punctuation with safe characters AND ensure "Remember last page" is not active.
The use of # fragments for PDF navigation was introduced by Adobe for their Acrobat plug-in and has in parts been adopted by some browser plug-ins . So some work one way in Chrome but some can be different name or behaviour in FireFox, so beware which browser you use as default.
One example is #search= works well in FireFox but is totally different in Chromium. #:~:text=Chromium but does not work with PDF nor this page !
The benefits of hiding a file extension that I know of are user-friendly URLs, and a thin layer of security (I say thin because if someone really wanted to find out the extension of a file whose type has been hidden, it probably wouldn't be difficult. Am I wrong?).
But why should you do this (hide the extension), rather than use a file of type "file", with no extension? For example, if I have an extension-less file named "404", Error page works without error (pretend I have absolutely no IE visitors).
Is there any added benefit of actively hiding the extension of a file that has one, over using files that don't have extensions? See any linked pages from schema.org for an example.
You hide the file extensions because it is Good Design.
The idea is that URIs and URLs are independent of implementation and the user should not bother about what type of file he is looking at, whether .php or .html. If I want to look at a page on the latest Fender Strats, I should just go to something like www.fender.com/strats/latest and get all that I need.
The added benefit is that the URL remains "Uniform" and you don't have to change it (especially when the user bookmarks your site), if one day you decide to shift from php to Django or Rails.
Shorter urls are one benefit of leaving out the extension?
I am currently writing an application working with specially prepared image data. Another tool prepares the images (basically PNGs with additional data stored in the meta-data section). Now my tool works with these files, but not with all PNGs, so "we" decided to use a different file extension. So far, so good.
Now, because I am a lazy sack I implemented some file type registration to allow double-clicking on the file and opening it in my application (no problem at all).
And here is my Question:
It would be cool if the windows explorer could still show me the thumbnail previews for my files. Since they basically are still PNG files, it should be possible without writing my own shell extension (at least I believe so).
I quickly tried to copy all registry keys and values from HKCR.png to HKCR.mInDat (my file name ext) and it worked. However, I would prefere knowning what I am doing ;-)
Which of the registry settings are responsible for the thumbnail preview control and which can I use to get the preview for my file types?
I tried to google it, but I failed, since it seems I am unable to come up with the right buzz-words to find the info I need. Please, help me.
Thank you!
Yours,
3of4
Simple:
[HKEY_CLASSES_ROOT\.apng]
#="apng"
"Content Type"="image/png"
"PerceivedType"="image"
[HKEY_CLASSES_ROOT\apng\shellex\{BB2E617C-0920-11d1-9A0B-00C04FC2D6C1}]
#="{3F30C968-480A-4C6C-862D-EFC0897BB84B}"
Back in the earlier days of the internet I remember that in certain browsers, every time you downloaded an image or a file, the URL of where that file was downloaded from would be written into that file's properties (I guess the summary tab?). I think Netscape v2 did this if I remember correctly.
I really miss that kind of functionality as every once in a while I'll run into a neat little program stored somewhere in the depths of my hard drive and wonder where I got it from originally.
I googled around but I'm not quite sure what terms to use to describe what I'm looking for. So I'm wondering if anyone knows of a Firefox plug-in or something similar that would do this?
If you use the DownThemAll! extension for Firefox, you can tell it to prepend the URL of the site to the downloaded file name...
thus you end up with files like:
download.com_utils_compression_ABCD32.exe
It also works really well when you want to download/queue a bunch of files.
You download http://example.com/foo to ~/Desktop/foo, and you want to see the originating URL in the properties of the local file foo?
Back when I used OS X, I remember Safari used to record the original URL in the resource fork of the downloaded file. Can't remember what the named fork is, well, named, but it'll show up in the properties panel from Finder. Since it's there, Spotlight will probably index it, too, but I haven't used OS X since 10.3.
If you use Opera, and haven't cleared the file out from your download manager, select the download and it'll show the original URL that the file is from in the properties pane.
Is this what you want? If so... well, I don't know of a similar Firefox extension, but it'll clarify the question.
For the IE Browser I use the hell out of Fidler to look at all traffic going across the wire.
For FireFox, you can use the FireBug plugin. There is a "Net" tab that will show you request information that is going across the wire.
Most of the time you can use one of these tools to see what URL was requested in order to start a download. You can also view all the get and post information that might need to be sent in order to have your request succeed.
Fidler is here: http://www.fiddlertool.com/fiddler/
FireBug is here: https://addons.mozilla.org/en-US/firefox/addon/1843
Best of Luck!
I'm trying to load an image from the Firefox cache as the title suggests. I'm running Ubuntu, so the location of my cache is /home/me/.mozilla/firefox/xxxxxx.default/Cache
However, in the Cache (and this is on Mac, too) the filenames are just ridiculous combinations of letters and numbers. Is there a way to pinpoint a certain file?
You should take a look at the source code of the CacheViewer Add-on.
Download the file instead of installing it (right click and save as) and then extract it (it's just a Zip file, even though it has a .xpi extension), then extract the cacheviewer.jar file inside the resulting chrome folder. Finally go into content and then cacheviewer to find the javascript and XUL files.
From my brief investigation, the useful routines are in the cacheviewer.js file, though if you were hoping there would be a simple javascript one liner for accessing cached items you're probably going to be disappointed. The XUL files (which are just XML) are helpful in working out which JS functions are called to perform particular tasks. I'm not too sure how all this maps into Greasemonkey, rather than the extension environment, but hopefully there's enough code to get you started.
Ummm, that really is an internal implementation detail. But I suggest looking at how about:cache?device=disk and about:cache-entry?client=HTTP&sb=1&key=https://stackoverflow.com/Content/img/wmd/blockquote.png are implemented.
Also, http://www.securityfocus.com/infocus/1832 gives details, too. Note that Firefox doesn't use a separate file for everything...
And of course, Firefox may change the format at any time.
Just give your img src= attribute the full URL. If the image happens to be cacheable (the server sends an appropriate Expires: or Cache-control: header, for example) and it's already in the cache, Firefox will not hit the network.
HTTP caching is supposed to be invisible. When you're generating content, you generally shouldn't worry about it.
You can point REDbot at a URL to see all sorts of delicious information about its cacheability.