On IE when i try to browse the rest apis, i am getting a application/json response instead of api (text/html) response (Returns html response on firefox). I am using django restframework 2.2.5 for this purpose.
I read through the documnets and understood that in order to overcome the problem of broken headers for IE we need to use TemplateHTMLRenderer explicitly in the view, so i have added the following to the class definition of my view but still i am getting a json response. Am i not doing it correctly or i am missing something else?
class CustomReports(generics.GenericAPIView):
`renderer_classes = (renderers.TemplateHTMLRenderer)`
Can you please help in fix the problem so that i get html response in case of IE as well?
Which version of IE are you using? I believe newer versions of IE should send correct Accept headers.
I probably wouldn't bother trying to fix things up to work around IE's broken behavior, but instead just make sure that you're including format suffixes in your urls. Then you can simply use the .api suffix to see the browseable API, or the .json suffix to see the plain json.
Eg instead of http://127.0.0.1:8000/api-root/, use http://127.0.0.1:8000/api-root/.api.
Related
I'm creating a web application using parse and have found that in order for a user to authenticate I need to make all requests using HTTPS. I'm able to switch this over and get it to work correctly, but when I do I get all kinds of mixed content errors because I'm retrieving PFFile objects which only return a non-secure URL.
This wouldn't even be a huge concern with Chrome or Safari but of course IE needs to present a message to the user and block all this content. Are there any potential work arounds? Why can't parse just put a setting in the app to enable files to be served from a secure url? This seems completely ridiculous. How do people get around this? Are you completely avoiding the use of PFFile?
Replace http:// with https://s3.amazonaws.com/.
So if you start with this:
http://files.parsetfss.com/b05e3211-bf8b-.../tfss-fa825f28-e541-...-jpg
The final url will look something like this:
https://s3.amazonaws.com/files.parsetfss.com/b05e3211-bf8b-.../tfss-fa825f28-e541-...-jpg
I am currently experimenting with IBM JAX-RS capability through WAS 7 and Web 2.0 Feature Pack 1.1.0.0. The problem I am running into is the client Dojo ajax call poses CORS situation and I am basically trying to figure out how I could properly handle the OPTIONS request.
I followed the example in the referenced url (although it's for WAS 8, it should not affect the part I am playing with); however, it is reported that the system cannot find any method that supports OPTIONS.
Any help will be appreciated!
Reference URL: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-base-iseries&topic=twbs_jaxrs_wadl_serving
Although it's less than a day, since I did not see any response, I want to post out the temp solution I pieced so far.
First of all, check out below link from Mozilla for a better understanding of CORS and OPTIONS request (it did the trick for me).
Link: https://developer.mozilla.org/en-US/docs/HTTP_access_control
Next, one update on the problem of IBM JAX-RS handling OPTIONS. It appears OPTIONS request is handled no different than other GET/POST, it requires an exact match of #Path value. This is not really desired, and in my case, I tried wild card in #Path value, that did not do the trick of triggering the system to handle OPTIONS.
Now, for the solution. With no surprise, I end up using a filter to forward the OPTIONS request to a method inside the resource annotated with #OPTIONS and fixed #Path value, e.g. #Path("options").
In filter, I am handling Allow-Origin and Allow-Header, then I left the resource's #OPTION method to deal with Allow-Methods.
It is very simple and basic solution. Along with proper checking inside filter, the header does not need to be added excessively for every request.
One catch here, it works for Chrome (Version 23.0.1271.95 m) and Mozilla (9.0.1), but not IE. I am still trying to figure out how IE is responding to these CORS. Hope this helps.
I'm trying to load some external content using jQuery load function to div on my page. load method works ok, with local content, but if you want something out of your domain, it won't work.
$("#result").load("http://extrnal.com/page.htm #data);
(it actually works in IE with security warning, but refuses to work in Chrome at all). jQuery documentation says that it is right, because cross-domain content is restricted because of security reasons. Same warning I get if use .getJSON method.
OK, after a googling a bit I found very interesting approach of using YQL for loading content, I've tried some examples, like this:
var request = "http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20html%20where%20url%3D%22http%3A%2F%2Ffinance.yahoo.com%2Fq%3Fs%3Dyhoo%22&format=json&diagnostics=true&callback=?";
$.getJSON(request, function (json) {
alert(json);
}
);
And it really works!
What I dont understand now is that http://query.yahooapis.com is also cross-domain resouce but browser (both IE and Chrome) works OK with that?
Whats the difference? What am I missing?
Thank you
The results you are getting back from YQL are in JSON format which is permitted for cross site AJAX calls like this. Its the same mechanism that allows you to communicate with web services for external sites via JSON (Ie. the twitter API).
Details here - http://www.wait-till-i.com/2010/01/10/loading-external-content-with-ajax-using-jquery-and-yql/
you can make on external site JSON like this:
callback({key:value,etc:1})
and define
function callback(json) {
..here is processing..
}
Thanks for your answers, but unfortunately both of them do not answer my orginal question..
I've checked out related questions on stackoverflow (i know i need to do that first) and found the reason of such behavior.
First code snipset uses AJAX/JSON to retrive the data and it is permitted because of Same Origin Policy. But request to YQL uses JSONP instead, that is OK.
The JSONP was something that I don't know about, that's why I didn't undrestand the behaviour.
Introduction info on JSONP could be found here:
http://ajaxian.com/archives/jsonp-json-with-padding
I'm doing an AJAX download that is being redirected. I'd like to know the final target URL the request was redirected to. I'm using jQuery, but also have access to the underlying XMLHttpRequest. Does anyone know a way to get the final URL?
It seems like I'll need to have the final target insert its URL into a known location in the headers or response body, then have the script look for it there. I was hoping to have something that would work regardless of the target though.
Additional note: I'm asking how my code can get the full url from production code, which will run from the user's system. I'm not asking how I can get the full url when I'm debugging.
The easiest way to do this is to use Fiddler or Wireshark to examine the HTTP traffic. Use Fiddler at the client if your interface uses a browser, otherwise use Wireshark to capture the traffic on the wire.
One word - Firebug, it is a Firefox plugin. Never do any kind of AJAX development without it.
Activate Firebug and select Net, then perform your AJAX request. This will show the URL that is called, the entire request (header and body) and the entire response (once again, header and body). It also allows you to step through your JavaScript and debug it - breakpoints, watches, etc.
I'll second the Firebug suggestion. You'll see the url as the "Location" header in the http response.
It sounds like you also want to get this url in js? If so, you can get it off the xhr response object in the callback (which you can also inspect using FB!). :)
Can you use AJAX to download a generated csv file from a web application? If so does anyone have any kind of reference that I could be pointed towards?
EDIT: Sorry I should have mentioned I am using Prototype's Ajax.Request and I looked in firebug's response tool and the generated CSV is the response, I just need to get it to pop up with the save file option after has been generated by the Ajax.Request
This is a known limitation of Ajax requests, you will need to use JS like:
window.location='download-csv.rb';
Instead of using an Ajax request. Another way is to change the location of a hidden Iframe, but this has it's own pro's/con's.
You will never get an Ajax request to display the 'file save' dialog, no matter what HTTP headers you send.
In light of your latest edit, to make your CSV file trigger a file download (instead of rendering in the browser), there's no need for Ajax.
Instead, the solution is to have your back-end system add this HTTP header when the CSV file is requested:
Content-disposition: attachment; filename=<your_filename.csv>;
Your implementation here depends on the back-end system you're using. If you're using Rails (as your username suggests), here's a start:
filename = 'your_filename.csv'
headers['Content-Type'] = 'text/plain'
headers['Content-Disposition'] = "attachment; filename=\"#{filename}\""
render :layout => false
Downloading it isn't the problem; you can download any data you like via XmlHttpRequest. The hard part is parsing it. There are several ways to parse it, from regexs to string indexing.
You can use "AJAX" to download anything .. Some people would say you shouldn't call it AJAX in that case since that term is rigorously devoted to downloading XML. But really it's just a mechanism to get data into the client w/o reloading a page. If you were loading HTML it'd be called AHAH, for CSV i guess you'd call it AHAC or AJAC? ..