http-options-method

I have CORS working with the following: [System.Web.Http.HttpPut] [System.Web.Http.AcceptVerbs("OPTIONS")] [System.Web.Http.Route("api/exercise")] public HttpResponseMessage UpdateExercise(Exercise exercise) { try { _adminService.UpdateExercise(exercise); return Request.CreateResponse(HttpStatusCode.OK, "Success"); } catch (Exception e) { return Request.CreateResponse(HttpStatusCode.InternalServerError, e); } } In my global.asax : protected void Application_BeginRequest() { if (Request.Headers.AllKeys.Contains("Origin") && Request.HttpMethod == "OPTIONS") { Response.Flush(); } } But something

According to http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2 the only response ever mentioned regarding an HTTP OPTIONS request is a 200. However, there seem to be cases such as when the content-length is 0 that a 204 would be more appropriate. Is it appropriate for an HTTP OPTIONS request to return a 204? Julian Reschke Yes, it can return 204. Or 400. Or 404. There is no general restriction as to what status codes a method can return. Also note that it's time to stop looking at RFC 2616. See http://trac.tools.ietf.org/wg/httpbis/trac/wiki . RFC 2616 says: A 200 response SHOULD...

My front-end code: <form action="" onSubmit={this.search}> <input type="search" ref={(input) => { this.searchInput = input; }}/> <button type="submit">搜索</button> </form> // search method: const baseUrl = 'http://localhost:8000/'; // where the Express server runs search(e) { e.preventDefault(); let keyword = this.searchInput.value; if (keyword !== this.state.lastKeyword) { this.setState({ lastKeyword: keyword }); fetch(`${baseUrl}search`, { method: 'POST', // mode: 'no-cors', headers: new Headers({ 'Content-Type': 'application/json' }), // credentials: 'include', body: JSON.stringify({keyword}

I am attempting to provide a response to the HTTP OPTIONS method with an Access-Control-Allow-Origin header copying the contents of the Origin header in the request. This is apparently not working, for reasons I can't figure out. tl;dr: response from OPTIONS says: Access-Control-Allow-Origin: http://10.0.0.105:9294 subsequent GET has: Origin:http://10.0.0.105:9294 Chrome says: Origin http://10.0.0.105:9294 is not allowed by Access-Control-Allow-Origin WTF not? More detail... By looking in Chrome's developer tools window, the request headers are: OPTIONS /user/kris HTTP/1.1 Host: 10.0.0.104

I'm building a REST webservice using ServiceStack. I want to allow cross-domain request, so I registered the CorsFeature plugin. My AppHost looks as follows: public class HomeAppHost : AppHostHttpListenerBase { public Context Context { get; set; } public HomeAppHost(Context context) : base("HomeAutomation", typeof(HomeInterfaceService).Assembly) { Context = context; } public override void Configure(Funq.Container container) { Plugins.Add(new CorsFeature()); Routes .Add<HomeInterface>("/HomeInterface") .Add<HomeInterface>("/HomeInterface/{Id}") .Add<ViewModel>("/ViewModel") .Add<FunctionInput>(

My Sencha Touch app is posting a form to my asp.net-mvc-3 WebService, but instead of sending POST it's sending OPTIONS . I'm reading a similar thread here , but I just don't know how to handle the OPTIONS method in my code. I did try adding the [AllowAjax] attribute to my Action, however it doesn't seem to exist in MVC3. OPTIONS /GetInTouch/CommunicateCard HTTP/1.1 Host: webservice.example.com Referer: http://192.168.5.206/ Access-Control-Request-Method: POST Origin: http://192.168.5.206 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_0) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11