If I understand correctly the OPTIONS request is forced by the fact that your POST's content-type is application/json -- Any request that's not a Simple Request gets a preflight because the W3C says so. Simple requests are defined as (emphasis mine):
> - Only uses GET or POST. If POST is used to send data to the server, > the *Content-Type of the data sent to the server with the HTTP POST > request is one of application/x-www-form-urlencoded, multipart/form-data, > or text/plain.* > > > - Does not set custom headers with the HTTP Request (such as > X-Modified, etc.) > > according to https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS?redirectlocale=en-US&redirectslug=HTTP_access_control So I think "the resource" -- fossil in this case -- is going to have to respond properly to a CORS preflight OPTIONS request. I started reading through this http://www.w3.org/TR/cors/#resource-preflight-requests and then my eyes began to bleed and I had to stop :) On Thu, Feb 7, 2013 at 10:20 AM, Stephan Beal <sgb...@googlemail.com> wrote: > Hi, all, > > i am trying, as a proof-of-concept, to host a fossil repo using the new > Google Drive feature of being able to host HTML/JS/CSS (as a basis i'm using > an existing custom fossil UI built on the JSON API). It's _almost_ working > but falls flat due to CORS (cross-origin calls) limitations and i'm not sure > what else i can do/should be doing to help this along. i'm looking for > assistance from anyone with CORS experience, specifically with making jQuery > work properly with CORS AJAX calls in an HTML5 page. > > The page is here: > > https://googledrive.com/host/0B-LwmfRxDIPvTFhJQl9FTVNvWTQ/index.html > > (warning: it currently throws a lot of alert() dialogs due to failed ajax > connections.) > > If you enable your debuggering tools while loading it you can see that the > requests to the remote fossil JSON back-end are OPTIONS requests instead of > GET/POST. This is where it is falling flat. i am (due to inexperience) > unsure whether or not i need to hack fossil to do something specific on such > an OPTIONS request. Even better would be to get jQuery to _stop_ sending an > OPTIONS request and just send GET/POST as i tell it to in the first place. > (i.e. it's trying to be too clever and i need it to stop doing so.) > > So far i have not found the magic combination of options to make this work. > i switched from a jQuery-based AJAX back-end to a plain old XHR-based one > but the results are similar (but not quite the same). With plain XHR, _some_ > requests are being sent as OPTIONS and _some_ are being sent as GET/POST, > and all of them (regardless of method) are failing and i'm not sure why. > > i have configured my Apache to set these headers: > > Access-Control-Allow-Headers: > x-requested-with > Access-Control-Allow-Methods: > POST, GET, OPTIONS > Access-Control-Allow-Origin: > * > > > Do any of you have a hint about what i might try next to get this running? > > :-? > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
