Ext.Direct call sending an HTTP OPTIONS cmd

[ykoehler]

I am trying to use Ext.Direct with a remote site. I defined my API like this:

 
Ext.ns('MSMWeb');
MSMWeb.API = {
  "url":"http://192.168.1.2/ext/direct/router",
  "type":"remoting",
  "actions":{
    "Interfaces":[
      {"name":"load","len":0},
      {"name":"setIPv4","len":1,"formHandler":true}
    ]
  },
  "namespace":"MSMWeb"
};

If I attempt to call my method setIPv4 I see inside Firebug an

OPTIONS http://192.168.1.2/ext/direct/router

But if I replace the url with a local value such as

"url":"router.php",

and I call it, I then see an HTTP POST

POST router.php

Can someone explain this behavior and how I can actually get a POST with a remote URL using Ext.Direct?

--
Yannick Koehler

[ckr]

 "url":"http://192.168.1.2/ext/direct/router",

I believe should be

 "url":"http://192.168.1.2/ext/direct/router/router.php",

If that is where your router is located. It doesn't know to use router.php as the router. You router process could be named anything.

[evant]

You can't: http://en.wikipedia.org/wiki/Same_origin_policy

[ykoehler]

You can't: http://en.wikipedia.org/wiki/Same_origin_policy

Actually, I can...

Using that document about same origin policy, I've altered my server to answered positively to the HTTP OPTIONS and the browser did follow with an HTTP POST.

So I did found how to solve this case, my next problem thought is that my server reply and the browser do not see the "data" portion of the reply but do see the header.

Even wireshark see the data and things seems to be valid yet the browser firebug and extjs do not seems to like it.

POST /ext/direct/router HTTP/1.1 
Host: 192.168.1.2 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2) Gecko/20100304 Gentoo Firefox/3.6 FirePHP/0.4 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Language: fr-ca,fr;q=0.8,en-us;q=0.5,en;q=0.3 
Accept-Encoding: gzip,deflate 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 
Keep-Alive: 115 
Connection: keep-alive 
X-Requested-With: XMLHttpRequest 
Content-Type: application/x-www-form-urlencoded; charset=UTF-8 
Referer: http://127.0.0.1/ 
Content-Length: 113 
Origin: http://127.0.0.1 
Pragma: no-cache 
Cache-Control: no-cache 
 
extTID=6&extAction=Interfaces&extMethod=setIPv4&extType=rpc&extUpload=false&ipaddress=&ipnetmask=&gatewayaddress=

HTTP/1.1 200 OK 
Server: Myserver 
Date: Mon, 08 Mar 2010 15:41:41 GMT 
Connection: close 
Pragma: no-cache 
Cache-Control: no-cache 
Content-Type: text/html 
Content-Length: 91 
 
{"type":"rpc","tid":"6","action":"Interfaces","method":"setIPv4","result":{"success":true}}

I fail to see what firefox or extjs do not like, the header is properly separated by a \r\n the data content of the reply is valid JSON, yet when I look inside Firebug it says that it received 91 B of size in the body response yet in the "Response" tab there is nothing, it's empty.

Any idea or suggestion?

--
Yannick Koehler

[meercat]

Very late to a thread again, but in case it help someone else in the future:

I was doing precisely this - cross domain requests to am ExtDirect server.
What I found I had to do was that the browser first sends an OPTIONS call, which I reply to in order to say that I'm happy to be called from a different origin, so the following headers but no body

  Access-Control-Allow-Origin: *
  Access-Control-Allow-Methods: POST, GET , OPTIONS
  Access-Control-Allow-Headers: X-Requested-With, Content-Type

and then for each subsequent request (GET, POST etc) I have to again say that I'm happy to allow a different origin by adding the following HTTP header to the response

  Access-Control-Allow-Origin: *

and then the browser will happily pass the result thru to the javascript code.

In this case I'm allowing absolutely any different origin ("*") but YMMV