Hi, It looks like you're doing a cross-origin call, but what you've quoted there doesn't look like a valid CORS[1] response to the OPTIONS request. There may also be an issue with the request.
In fact, it looks like you're issuing the call from a local file, but querying a remote server. If you really want to do that, read on. If not, put the file on the server and run it from there via HTTP to avoid running afoul of the Same Origin Policy[2]. But if you're doing it intentionally, using the new CORS stuff, read on. Your browser is sending a CORS request to the server via the OPTIONS verb (note that it's OPTIONS, not GET). Your server wants to include certain headers in the response that tell the browser that all of the requested features are allowed. The response you've posted looks like it's just responding as though to a GET, not to OPTIONS, and doesn't have the necessary headers (but does have an unnecessary body). In the OPTIONS request the browser did on your behalf, there are these CORS headers: Origin: null Access-Control-Request-Method: GET Access-Control-Request-Headers: x-prototype-version,x-requested-with It's that first header that tells me that you're doing this from a local file (probably). If you do this from a page served with HTTP or HTTPS, that header would contain the origin of the file. For instance, if the requesting page were http://www.example.com/page.html, it should be `Origin: http://www.example.com` (I don't know why only the path, not the full URL, is included, but that's what happens.) That null header isn't necessarily a problem, though, if the server's okay with it (which is up to you). The second two headers are telling the server that the page is asking permission to do a GET that (amongst other things) requests the headers x-prototype-version,x-requested-with. To allow this, you'd want your server to respond with these headers: Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET Access-Control-Allow-Headers: x-prototype-version,x-requested-with The first tells the browser that any origin can make the request (I wouldn't typically do that, but it's the only thing that's going to work with the null origin that was sent.) The second says that GET is okay (but POST is not, for instance). The third says requesting those headers is okay. You do not send a body with the OPTIONS response (although I expect doing so is harmless), it's all about headers. Once that "preflight" has been completed, if the headers work, the browser will do the actual GET for you. All of this CORS work on the client happens automatically for you on recent versions of Firefox, Chrome, and probably Safari. It's also supported by IE8, but only if you do it on purpose.[2] I would typically suggest that the server respond to the OPTIONS request with only the permissions that the request asked for, by echoing the input headers as output (provided, of course, the server wanted to allow the request). For instance, this code in a JSP or servlet: String corsOrigin, corsMethod, corsHeaders; corsOrigin = request.getHeader("Origin"); corsMethod = request.getHeader("Access-Control-Request-Method"); corsHeaders = request.getHeader("Access-Control-Request-Headers"); if (corsOrigin == null || corsOrigin.equals("null")) { // Only do this if you want to allow access from a file; * means "any origin" corsOrigin = "*"; } response.addHeader("Access-Control-Allow-Origin", corsOrigin); response.addHeader("Access-Control-Allow-Methods", corsMethod); response.addHeader("Access-Control-Allow-Headers", corsHeaders); But I've only played with CORS, I haven't used it in a real app yet. [1] http://www.w3.org/TR/access-control/ [2] http://en.wikipedia.org/wiki/Same_origin_policy [3] http://msdn.microsoft.com/en-us/library/dd573303(VS.85).aspx HTH, -- T.J. Crowder Independent Software Consultant tj / crowder software / com www.crowdersoftware.com On May 26, 2:17 am, msoulier <msoul...@digitaltorque.ca> wrote: > Hi, > > I've never had this problem with prototype before. I'm querying a > twisted python web service that I wrote with a simple GET request, > returning json, but for some reason the responseText always seems to > be ". > > function make_request() { > debug("in make_request with url " + url); > new Ajax.Request(url, { > method: "get", > onSuccess: function(transport) { > debug("query successful"); > debug("response was '" + > transport.responseText + "'"); > }, > onFailure: function(transport) { > debug("query failed"); > } > }); > } > > In the browser I end up seeing > > * in make_request with > urlhttp://localhost:8000/route/?start=sta-917&end=sta-10715&starttime=12... > * query successful > * response was '' > > And yet if I capture the traffic, the response looks fine. > > OPTIONS /route/?start=sta-917&end=sta-10715&starttime=1274469161 HTTP/ > 1.1 > > Host: localhost:8000 > > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4) Gecko/ > 20091206 Gentoo Firefox/3.5.4 > > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/ > *;q=0.8 > > Accept-Language: en-us,en;q=0.5 > > Accept-Encoding: gzip,deflate > > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > > Keep-Alive: 300 > > Connection: keep-alive > > Origin: null > > Access-Control-Request-Method: GET > > Access-Control-Request-Headers: x-prototype-version,x-requested-with > > HTTP/1.1 200 OK > > Content-Length: 65 > > Content-Type: application/json > > {"status": "defer", "reason": "No workers ready, try again soon"} > > So why am I not seeing it in transport.responseText ? > > Thanks, > Mike -- You received this message because you are subscribed to the Google Groups "Prototype & script.aculo.us" group. To post to this group, send email to prototype-scriptacul...@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
