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

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

    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

T.J. Crowder
Independent Software Consultant
tj / crowder software / 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: 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 
For more options, visit this group at 

Reply via email to