I have a normal file upload code in HTML page through which I will upload a file. The problem is I am using the complete file URL later in my Servlet. In Firefox there is a textbox in which complete URL is coming, so my application works fine there, but in Chrome only the file name with extension is coming, so the file is not uploading the file.
If I am not clear in language, then open this link in both Chrome and Firefox and observe.
Is there any solution so I can use the URL(imagepath) in chrome also??
You cannot get the path of a file from your local system from any modern browser except IE because of security reasons. Only the file name is returned.
It's the business of none of the websites to track from which local location the file is coming from. You have many ways to upload a file onto the server, regardless of where it is in the local file system.
Related
I use Hostinger for hosting. Although I uploaded my files successfully, Chrome won't show the changes, while windows Explore does. It seems that the browser remembers the old version of the page and doesn't download the new files. It's the same on my friend's computer and phone, whom I showed the page before the update.
The page is pure HTML, CSS, and a bit of JavaScript. How can tell my browser it's a new version of a page? Without manually clearing the browser history etc.
www.michalrucinski.com
https://github.com/michalrutz/porto
You could rename index.html to index.htm so the old file would longer exist and the browser would be forced to search for an alternative file.
Or you can set up cache control in the HTTP headers, e. g. using .htaccess if your hosting plan supports it.
I'm doing file upload which checks file mime type in browser. It's uses jQuery File Upload Plugin and works good everywhere except one user.
For some reason file.type (html5 file api) returns "invalid/octet-stream" for pdf file (usually it's "application/pdf"). Pdf file is simple and can be opened at this pc without any problems.
Environment: Windows 7 and Firefox 40. Not reproduced in chrome or explorer.
Try deleting (or renaming/moving, for testing purposes) the file MimeTypes.rdf in the affected Firefox's profile folder.
(Under Windows this can usually be found under a path similar to c:\Users\[name]\AppData\Roaming\Mozilla\Firefox\Profiles\[some id].default - or just search for "MimeTypes.rdf".)
If the PDF upload works afterwards, you encountered a Firefox bug that was first reported in 2007 (basically the same here, reported in 2006). In a nutshell, any web site from which the user ever downloads a file has the potential to corrupt the MimeTypes.rdf file in regards to the extension of the downloaded file - maliciously or accidentally/unknowingly.
Things you can do:
Vote for the Firefox bug!
Quick fix to get it working for the one user right now: Have the user delete their MimeTypes.rdf file. Firefox will create a new, "fresh" one at the next start, but this will clear all MIME type / application associations that the user has created over time. Also, this will only help until the user downloads the next PDF file from some other web site that corrupts the MimeTypes.rdf file again.
Use the "user agent" header to determine if the file is uploaded from Firefox. If so and the MIME type doesn't match anything you wish to accept, double-check the file name's extension and accept the file anyway if the extension matches your accepted file type(s) (".pdf" in your case).
I have an application that creates html files that containes a lot of data to draw. This files are alwayes browsed from local file system (no http protocol at all).
I have an idea to compress the data and than place it in a raw format in a separate .dat file that will be put in the same place as .html one.
It is not a problem to read and uncompress this .dat file when it is on a web server. But I don't now how to read it when both files .html and .dat are local.
Of course one can use browser file objects for it but in this case user will be alwayes asked to do a stupid action like to chose the the only file from an control.
But I don't now how to read it when both files .html and .dat are local.
I take it you mean from JavaScript within that HTML file. Depending on the browser, you can't except via the File API (which, as you've observed, requires that you have the user select the file in an input[type=file] element).
The way you'd want to do this would be via ajax (XMLHttpRequest), and that would work in some browsers, but not in others. Chrome, for instance, denies all attempts to use ajax with file:// URLs (e.g., in pages served from the file system), even from local pages, even when you're using a relative URL like thefile.dat. IE allows it (or at least, older versions of IE did; I haven't tried it lately).
So unfortunately, I think the only way you can do this is via the File API, with the attendant input[type=file].
I have developed a script for myself to read and process local text and csv files on my computer using recent Chrome or Firefox browsers with the filereader api. The script will work on the computer, even though it is not connected to the internet or a local webserver.
The reasoning behind this is to have a standalone text file interrogator, which will work on almost any computer, requiring only a browser to execute and display reasonably formatted output. similar to an awk type application.
I use the filereader api and it works well.
I do not properly understand the workings of the browser, so my question may be very stupid.
Is it possible that my script can somehow pass the filename to the script filereader api, without having to choose a file from input type=file field.
eg I have a file called addresses.csv and it resides in the same directory as my html/js file with the filereader api code.
I want to simulate the choosing of a file, without accessing my local directory and without using a webserver, but a dropdown box of predefined filenames would be even better.
No, for security reasons its not possible, because otherwise people could open arbitrary files on the computers of their visitors which is definitely not intended.
This specification also assumes that the primary user interaction is with the element of HTML forms [HTML], and that all files that are being read by FileReader objects have first been selected by the user.
See http://www.w3.org/TR/FileAPI/#security-discussion
No you cannot. Javascript cannot read your local filesystem without the use of a file input or drag and drop files (html5) as it would be vulnerable to malicious use.
There was a start of a filesystem api which Chrome has included. But you cannot read/write to just any place you want on the filesystem, you can only do so to a sandboxed area on the filesystem. Wither or not they will continue to have this in future versions of Chrome though I do not know.
It also appears the W3C itself has discontinued the file system api
I was wondering if there was any method to implement browser's download file prompt using JavaScript.
My reason - well users will be uploading files to a local fileserver which cannot be accessed from the webserver. In other words, both will be on different domains!
For example, let’s say websites hosted on www.xyz.com, but files would reside on local file server with address like \\10.10.10.01\Files\file.txt. How am I uploading/transferring file to local fileserver... using ActiveX and VBscript! (don’t ask :-)
So I am storing local file path in my database and binding that data to a grid. When the user clicks on that link, the file opens in a window (using JavaScript).
Problem is certain file types like text, jpg, pdf, etc. open inside browser window. How would I be able to implement content-type or content-disposition using client side scripting? Is that even possible?
EDIT:
the local file server has a window's shared folder on which the files are saved.
"content-disposition: attachment" is pretty much the only way to force that, and this MUST be set in the response header.
If the file is hosted on a web server like in your example, you can do:
window.location.replace(fileUrl);
.. and the browser will figure out what to do with the file. This works great for most files, such as .xls, .csv, etc, but keep in mind that this isn't full-proof because the user's MIME handler settings will determine what to do with the file... i.e. if it is a .txt file it will most likely just be displayed in the browser and will not be given a "file download" dialogue box.
As of August 2015, adding the "download" attribute to your tag enables the behavior you're looking for, at least in Chrome.
You could try using a plain hyperlink with type="application/octet-stream". Seems to work in FF, but IE and Opera ignore the attribute.