ok - now everything fits into places - so to resume: 1) Do not use alternative port in rpc server URL to avoid brauser added OPTIONS method to request 2) Or implement OPTIONS request handling into RPC server and proceed processing POST that follows OPTIONS
---------------------------------------------- Andres Toomsalu, [email protected] Daniel Wagner wrote: > Hi, > > apparently the OPTIONS request is triggered by the browser. See this > thread for details: > > http://qooxdoo.678.n2.nabble.com/POST-and-GET-not-really-td5181761.html > > Regards, > Daniel > > Andres Toomsalu schrieb: > >> A bit more debugging on qooxdoo 1.1 RPC default transport (not with >> ScriptTransport) reveals that this HTTP OPTIONS request method comes >> from client (qooxdoo, browser?) - as it is already present in TCP >> packets - so its not RPC server (RpcPython) generated thingy... >> >> Here is a full wire HTTP protocol decode on RpcConsole request >> (cross-domain switched OFF): >> ----------------------------------------------------------------------------------- >> >> >> OPTIONS /?nocache=1277192367196 HTTP/1.1 >> Host: 192.168.1.55:8001 >> Access-Control-Request-Method: POST >> Origin: http://cboulanger.users.sourceforge.net >> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) >> AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16 >> Referer: >> http://cboulanger.users.sourceforge.net/qooxdoo-contrib/RpcConsole/0.2/ >> Access-Control-Request-Headers: Pragma, Content-Type, >> X-Qooxdoo-Response-Type, Cache-Control >> Accept: */* >> Accept-Language: en-us >> Accept-Encoding: gzip, deflate >> Content-Length: 0 >> Connection: keep-alive >> ----------------------------------------------------------------------------------- >> >> >> >> So it seems that with qooxdoo 1.1 the only RPC transport that works >> (after fixing the RPC server as Danel described before) is to enable >> cross-domain and ScriptTransport. >> But by default there is something else enabled in qooxdoo 1.1 - surely >> its not the pure GET method described in docs - as seen from the >> protocol decode (OPTIONS method followed by POST). >> So the big question is - what is it? Where this OPTIONS method comes >> from - we didn't notice it from qooxdoo source... >> And how one should use simple GET transport for RPC - described as >> default transport method in docs??? >> >> Attached dumpcap binary packet log for loading into wireshark (logged 2x >> rpccpnsole requests with cross-domain off). >> >> Regards, >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
