Basically I am using a POST method but it automatically gets converted to OPTIONS method. I know browser does this but also read that it is fine and should get response as 201, but in my case it is not behaving as expected, I have also tried Access-Control-Allow-Methods in request headers but didn't get anything.
This is what my Request looks like:
OPTIONS http://xyz/abc
Accept: application/json
Content-Type: application/json
Response:
405, Method Not Allowed
Access-Control-Allow-Origin: *
Date: Tue, 05 May 2015 06:15:19 GMT
Connection: close
Accept-Ranges: bytes
Access-Control-Allow-Headers: authorization, content-type
Content-Length: 0
Access-Control-Allow-Methods: GET, PUT, POST, DELETE, HEAD
Can anyone tell me the cause of this issue and what could be the exact reason for the same after having enough research everything looks fine at my end.
Thanks in advance.
You are probably seeing pre-flight check during a POST-request in cross-origin resource sharing. I don't know how your webserver needs to be setup to support this, but this Wikipedia article might be a first help: http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
The easiest solution is to do the POST request on the same origin as the where you are loading the web-page from. A reverse proxy might be a reasonable solution.
Related
I'm having a problem where by the cross origin requests from my Angular JS application work fine in Chrome but not in Firefox.
The error received in firefox is:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at https://api.domain.eu/join/joinstatus. (Reason:
CORS header 'Access-Control-Allow-Origin' does not match
'https://www.domain.eu, https://www.domain.eu').
I can make requests successfully until I add an Authorization header to the request.
My server (ASP.Net Web API running on IIS) has the following headers set up:
Access-Control-Allow-Origin: https://www.domain.eu
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Firefox successfully pre-flights the request with an OPTIONS request. Looking through this I can see the sent Origin header is contained in the returned Access-Control-Allow-Origin header.
In fact, for some reason the returned Access-Control-Allow-Origin header has my domain name twice (despite specifying it once in config) e.g.
Access-Control-Allow-Origin: https://www.domain.eu, https://www.domain.eu
That aside what is the difference between Firefox and Chrome in this regard?
What else do I need to do so that this will work in Firefox?
UPDATE
I have noticed that if I set my headers as follows...
`Access-Control-Allow-Origin: https://www.domain.eu'
... then the pre-flight OPTIONS request works fine. The Access-Control-Allow-Origin header is the same in both the request and the response. However the actual GET request then fails with the error above.
If I modify my headers as follows:
Access-Control-Allow-Origin: https://www.domain.eu, https://www.domain.eu
... (which is what Firefox alluded to in the error), then the actual pre-flight OPTIONS request fails as this time Firefox just expects a single value of https://www.domain.eu in the header.
Try:
Access-Control-Allow-Origin: https://www.domain.eu, https://domain.eu
Access-Control-Allow-Origin: https://*.domain.eu, http://*.domain.eu
Access-Control-Allow-Origin: domain.eu
Access-Control-Allow-Origin: *.domain.eu
EDIT:
Try:
Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, DELETE
Access-Control-Request-Method: GET, POST, OPTIONS, PUT, DELETE
Docs:
Access-Control-Allow-Origin
A returned resource may have one Access-Control-Allow-Origin header, with the following syntax:
Access-Control-Allow-Origin: <origin> | *
The origin parameter specifies a URI that may access the resource. The browser must enforce this. For requests without credentials, the server may specify * as a wildcard, thereby allowing any origin to access the resource.
For example, to allow http://mozilla.com to access the resource, you can specify:
Access-Control-Allow-Origin: http://mozilla.com
You must only specify a single URI or *
This problem was caused by essentially having the wrong combination of NuGet packages in my solution. Owin and Web API CORS had both been used causing the headers to get mixed up.
I resolved this by going back to basics and working out what packages I needed and the problem went away.
you need to enable CORS in your web API project.
Check this out!
basically my problems is use set-cookie header with angular (looks like he is ignored even with the withCredentials set to true) but here is the problem if i make the same request the cookies go, but if i change the path does't work.
Example;
POST http://localhost/app/api/oauth/ HTTP/1.1
[other headers and payload]
then i get the answer:
HTTP/1.1 200 OK
Set-Cookie: ; expires=Wed, 31-Mar-2015 01:34:53 GMT
and send a request to access a resource:
GET http://localhost/app/api/oauth/test HTTP/1.1
Cookie:blah=something;
until now evething is ok, but when i try to access other resources on my server:
GET http://localhost/app/api/othercontroller/test HTTP/1.1
the cookie is not send anymore, only if i access some path after the path that create the cookie.
that is what network monitor show me. But i can't see that blah coockie on the resource tab (on cookie area).
Note: i already try use secure cookie or not and use http only cookie or not and all combinations between both of then. And i try don't use CORS or enable CORS, but anyone work too.
Anyone know what can be ?
Thanks for you time and patience.
I'm pasting my suggestion from my comment.
Your initial cookie is set in a response of a HTTP endpoint path that is deeper than your second request.
Set-Cookie: ; Domain=foo.com; Path=/; expires=Wed, 31-Mar-2015 01:34:53 GMT
You may specify where to put your cookie by specifying a Path parameter in your response header like given above.
We're having an issue with restangular and handling errors from the API. If the API responds with a 200, then everything works perfectly. However, when the API returns a 409 we receive a lovely:
XMLHttpRequest cannot load https://**token=*. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://127.0.0.1:9000' is therefore not allowed access.
Response headers from a valid post operation:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:Origin, X-Requested-With, Content-Type, Authorization, Accept, X-Authorization, User-Agent, DNT, Cache-Control, X-Mx-ReqToken, Keep-Alive, If-Modified-Since
Access-Control-Allow-Methods:GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin:http://127.0.0.1:9000
Access-Control-Max-Age:1728000
Cache-Control:private, must-revalidate
Connection:keep-alive
Content-Type:text/html; charset=utf-8
Date:Fri, 29 Aug 2014 21:55:51 GMT
ETag:"*****"
Server:nginx/1.6.0
X-Frame-Options:SAMEORIGIN
X-Powered-By:HHVM/3.3.0-dev+2014.08.22
Response headers from a post operation with a 409 response captured from postman:
Cache-Control →no-cache
Connection →keep-alive
Content-Encoding →gzip
Content-Type →text/html; charset=utf-8
Date →Fri, 29 Aug 2014 21:56:59 GMT
Server →nginx/1.6.0
Transfer-Encoding →chunked
X-Frame-Options →SAMEORIGIN
X-Powered-By →HHVM/3.3.0-dev+2014.08.22
Any attempt to catch the response.status or error handling as outlined in the
restangular docs results in this:
config: Object
data: ""
headers: function (name) {
status: 0
statusText: ""
I always have a status of 0.
Let me know if you need to see any additional information.
This really has nothing to do with restangular but with your webserver config.
What is happening is that your webserver isn't set up to return the CORS headers in case an error occurs.
Because of this you can not access any of the returned data from the ajax request, even tough data was actually returned. You won't even be able to see it in chrome's network inspector ( except for the status code and headers ). Additionally, because this is a security violation, you can't even access the status code, headers or anything from javascript everything is being blocked.
You will however be able to see it in a proxy like fiddler or charles, or when you make the request directly to the api server ( in case of a GET request ), because a request was actually made and data will have been returned, the browsers security policies just denies access to it trough AJAX because of the missing CORS headers.
This doesn't mean you can just fire off ajax requests to any other domain and possibly interact with it. The only reason your requests are going trough in the first place is because the preflight OPTION request is set up to allow CORS
Solution:
Set up your WebServer to include CORS headers in case an error response is generated, the headers you are looking for are all available in the valid response you supplied ( Access-Control-* ).
I got some images to download using HTTP. I got these images' URL, how to build the TCP-based HTTP buffer to download the image?
I got no library in my current platform, the only supported language in this platform is C, so I have to build the HTTP buffer for these resources.
Currently I have build the normal API request, they are all HTTP request, every request have 0 or more parameters. But the image request got only a URL, such as http://some-image.jpg, it seems just a download job, no API parameters, no authorization, it's simple, but how to construct the TCP request?
You would have to implement HTTP protocol or a subset of it. There are open source implementations. For example:
https://github.com/bagder/curl/tree/master/lib
https://github.com/joshthecoder/libhttp
how to build the TCP-based HTTP buffer to download the image?
Stop thinking TCP. It has it's own buffers which have nothing to do with what's happenning at the HTTP level.
You really don't want to implement your own HTTP stack - it's not trivial. There are several well-written ones already available - I'd recommend using libcurl.
According to the http://www.jmarshall.com/easy/http/#sample, I build my TCP request like that:
sprintf(tcp_send_buf, "GET %s HTTP/1.1\r\nHost: %s\r\n\r\n", img_path, img_host);
/* I wrapped TCP APIs for convenient, hope you understand it... */
set_host_and_port(img_host, 80);
tcp_send(tcp_send_buf, strlen(tcp_send_buf), recv_callback);
On my recv_callback, I got the server response like that:
HTTP/1.1 200 OK
Content-Length: 42299
Content-Type: image/jpeg
Last-Modified: Mon, 02 Jul 2007 07:58:47 GMT
Accept-Ranges: bytes
ETag: "e2c8b5d17ebcc71:15d5"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Fri, 25 May 2012 01:33:57 GMT
<binary image data>
I downloaded the image from Chrome, and it's size is the same as Content-Length: 42299, I think I got the image buffer.
A web-server is returning a status code and description in response to a request by an XmlHttp component. The actual status response from the server begins with:
HTTP/1.1 400 Not a valid http POST request
which i can see in though a Fiddler trace:
But when i ask the xmlHttp request for the status and statusText, it shows me the "standard" description for the status text, rather than the actual status text:
xmlHttp.status: 200
xmlHttp.statusText: "Bad Request"
which i can see in in the development IDE:
i've poked around all the other properties of IXMLHttpRequest, and i can't find any that contain the response's actual status text. It's not even in any of the response headers:
Server: ASP.NET Development Server/8.0.0.0
Date: Thu, 28 Jan 2010 21:03:16 GMT
X-AspNet-Version: 2.0.50727
X-LSI-Proxy-Identificaton: {65B76AB2-8A28-4A2B-B282-7E1FDC9DBCA1}
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/xml; charset=utf-8
Content-Length: 4652
Connection: Close
Internet Explorer, Chrome, and FireFox manage to read the actual status text:
How can i get the actual statusText from a Microsoft xmlHttp object?
Unfortunately code 400 is defined as Bad Request as part of the HTTP/1.1 RFC and XMLHTTP (well more likely URLMON or WinHTTP) is just transforming the number and ignoring the passed status text. As the status line is part of the protocol and not a response header then it makes sense it isn't defined in the list of response headers.
However I would contend that the browsers are only showing the status text "correctly" because they are displaying the custom HTML page which got sent along with it which has that text as the TITLE in the HEAD element.