I'm having intermittent problems, trying to to upload files, using ajaxfileupload.js. Most times, the request has teh correct payload, as in A). But sometimes, the request gets sent off without the filename (and contents) as seen in this pastebin (B).
It seems to be similar to this problem. This post also talks about the problem. But I'm pretty sure I have the correctr element ID.
And this post suggests using the jquery.form plugin (here and here). But before I change components (having to re-engineer), I want to be sure there isn't an easy way to fix my current problem.
A)
…
Request Payload
------WebKitFormBoundaryXOoAbr8cm53B1pGS
Content-Disposition: form-data; name="convert"; filename="some-file.jpg"
Content-Type: application/octet-stream
…
B)
http://pastebin.com/ubEbb9dV
Has someone had this problem before? Is there a way to avoid it?
Thanks
----> EDIT
So this is how I'm calling the function. i) The inputId passed in definitely exists. And ii) the file selected definitely exists on the file system. And this works most of the time. But now that I think about it, I'm using this plugin in conjunction with the "jquery.jeditable.js" plugin. Could that or any other plugin be turfing some functions in "ajaxfileupload"?
$.ajaxFileUpload (
{
url: '/api/upload/image',
secureuri: false,
fileElementId: inputId,
success: successFn,
error: errorFn
}
);
By default jQuery use GET as request Method. In the case of the question you reference here, Steven is not setting correctly the method property of for the ajax request. What I want to see i how you are sending the form (Your javascript/Jquery code).
Related
I have a .csv file that I wish to load that contains information that the .HTML page will format itself with. I'm not sure how to do this however,
Here's a simple image of the files: http://i.imgur.com/GHfrgff.png
I have looked into HTML5's FileReader and it seems like it will get the job done but it seems to require usage of input forms. I just want to load the file and be able to access the text inside and manipulate it as I see fit.
This post mentions AJAX, however the thing is that this webpage will only ever be deployed locally, so it's a bit iffy.
How is this usually done?
Since your web page and data file are in the same directory you can use AJAX to read the data file. However I note from the icons in your image that you are using Chrome. By default Chrome prevents just that feature and reports an access violation. To allow the data file to be read you must have invoked Chrome with a command line option --allow-file-access-from-files.
An alternative, which may work for you, is to use drag the file and drop into onto your web page. Refer to your preferred DOM reference for "drag and drop files".
You can totally make an ajax request to a local file, and get its content back.
If you are using jQuery, take a look at the $.get() function that will return the content of your file in a variable. You just to pass the path of your file in parameter, as you would do for querying a "normal" URL.
You cannot make cross domain ajax requests for security purposes. That's the whole point of having apis. However you can make an api out of the $.get request URL.
The solution is to use YQL (Yahoo Query Language) which is a pretty nifty tool for making api calls out of virtually any website. So then you can easily read the contents of the file and use it.
You might want to look at the official documentation and the YQL Console
I also wrote a blog post specifially for using YQL for cross domain ajax requests. Hope it helps
You can try AJAX (if you do not need asynchronous processing set "async" to false. This version below ran in any browser I tried when employed via a local web server (the address contains "localhost") and the text file was indeed in the UTF-8-format. If you want to start the page via the file system (the address starts with "file"), then Chrome (and likely Safari, too, but not Firefox) generates the "Origin null is not allowed by Access-Control-Allow-Origin."-error mentioned above. See the discussion here.
$.ajax({
async: false,
type: "GET",
url: "./testcsv.csv",
dataType: "text",
contentType: "application/x-www-form-urlencoded;charset=UTF-8",
success: function (data) {
//parse the file content here
}
});
The idea to use script-files which contain the settings as variables mentioned by Phrogz might be a viable option in your scenario, though. I was using files in the "Ini"-format to be changed by users.
I have an ExtJs form with an upload field. When I sumbit the form, the Accept-header is wrong. The response is JSON yet the sent Accept-header is:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
My educated guess is that it's the browsers default value.
In Chrome this results in a warning: Resource interpreted as Document but transferred with MIME type application/json.
In FireFox this results in a file download.
Conclusion: I have to change/set the Accept-header to application/json
Sencha's documentation sais it has a headers parameter, but I've tested and for fileupload it does not work. A comment said it's not supported. (found same result in another thread)
Any suggestions to get rid of the file download/ set the right Accept-header... It doesn't have to be a ExtJs sollution. If you can give me a plain javaScript solution for setting the accept header on a file upload form, I can probably mold it into the sencha framework.
UPDATE:
The ExtJS form submit:
form.submit({
url: API_URLS.addDocument,
waitMsg: 'Uploading your document...',
headers: {
"Accept": 'application/json' //doesn't work
},
success: function() {
...
},
failure: function(){
...
}
});
Behind the scenes it creates an ordinary form similar to this:
<form action="API_URLS.addDocument" enctype="multipart/form-data" method="post">
<input type="file"/>
</form>
which can be submitted through javaScript (submit())
The Accept header is just asking the server to respond with data of a given type. The * in the default header means "or anything else" (although the q value puts a lower priority then that).
If the response is JSON and you want JSON, then you don't need to touch the Accept header at all.
The problem is that, if I'm reading between the lines correctly, you are trying to perform an Ajax file upload using an iframe, and Firefox doesn't try to render JSON files as documents.
There are two ways around this.
Present the response as HTML instead of JSON and then extract the data from it using DOM
Use XMLHttpRequest 2 and the File API to upload the files instead of an iframe. (Note: This uses new APIs that have limited browser support).
I have the following XML as a string:
<battery_content>
<last_update>2012-15-09-22-40</last_update>
<total_downloads>234</total_downloads>
......
</battery_content>
I get the XML from an Ajax request and I store it in sXMLData. I do a quick window.alert(sXMLData) and everything's fine.
When I run the next code in IE8, it won't seem to work. Chrome and Firefox work.
window.alert("last_update" + $(sXMLData).find("last_update").text());
I can't seem to figure out why. Does this method not work with IE8? If so, how can I solve the problem?
The proper way to handle "XML as a dumb string" is to pass it through $.parseXML first:
window.alert(
"last_update" + $($.parseXML(sXMLData)).find("last_update").text());
However, you wouldn't need to do this manually if
either the server returns an XML Content-Type,
or the AJAX request you fetch the XML with uses the dataType AJAX option to specify that the response should be treated as XML
If the server is under your control, fix it to return the proper content type. If not, use the alternative solution. I recommend parsing the XML manually only if you are getting the string from third-party code that you have good reason to not want to touch.
I have a standard file upload script using this script. When the upload is completed, I send back a JSON telling the client that the upload went OK, something like this:
{done: true, error: "No error"}
When I do the upload on Firefox, everything works out smoothly, but on IE9 / Chrome it breaks. IE tells me that I need to download the file, something like this image:
I thought that the issue was the headers submitted to the client and I tried setting the content type to:
application/javascript
text/javascript
The files are stored properly and the answer is coming back without any corruption, nor in the encoding, or gzipped or anything like it.
Any ideas?
EDIT: Forgot to add the link on the "this" and also, it's an older version of the plugin, not the current one.
I'll reply the question myself because I've found a solution, at least it works...
Thing is that when sending a request using an iframe, seems that the content type of the response shouldn't be either application/json or application/javascript or any other like it. My solution was to send the response as text/html, and do a JSON.parse on the client, and it works like a charm.
Since I all of my Ajax calls specify that I expect a JSON, it works ok when I make ajax calls as well, because jQuery handles the whole conversion, only thing that worries me is any problem related to performance on the client, but I see no signs of problem just yet...
Hope that anybody that runs with the problem may find my answer helpful!
I had this problem with the same upload widget and IE 8 in the past.
header('Content-Type: application/json') fixed it for me. Did you try this as well?
This is the first time ever I'm using AJAX, and I want to do the following on an otherwise static page www.xyz.org/some_site.html:
Send a GET request to another url "www.xyz.org/testscript"
if response has either status code != 200 or content != 'ok': do nothing
else: include sth on the website (i.e. set style="display:block" on an element that previously had "display:none")
I've implemented that successfully using basic AJAX. But:
There is an Apache redirect installed pointing from www.xyz.org/testscript to subdomain.xyz.org/testscript, the URL where the actual testscript lives (as AJAX doesn't support cross-domain calls even to subdomains afaik).
When I call www.xyz.org/testscript I get a 302 status code, and the content says "The document has moved here: subdomain.xyz.org/testscript".
How can I grab the 'final' return value?
I guess/hope any AJAX expert can give me a one-liner to solve that ...
AJAX (or XMLHttpRequest to be acurate) won't be tricked by a redirect. To be able to get content from another domain you need to use a proxy on the server. The following is a simple PHP proxy:
if(strpos($_GET['q'], "http://") === 0){
echo file_get_contents($_GET['q']);
}
use it like this:
xhr.open(GET, "www.xyz.org/proxy.php?q=subdomain.xyz.org/testscript", true);
The answer is, according to the comments above:
It's not possible to achieve what I want to do, as AJAX can't be tricked into following a redirect.
EDIT: I tried to solve it by adding another javascript file at subdomain.xyz.org/another.js and throwing all AJAX code from my static html site into it.
Then, on the static html site, I included this script with an ordinary
<script src="subdomain.xyz.org/another.js">
tag. But that wouldn't work either ... cheated myself: Including the javascript on my static page results in the original problem again (cross-domain calls forbidden).