I'm trying to get the response headers from an ajax request but jQuery's getAllResponseHeaders xhr method only displays the "Content-Type" header. Anyone know why?
This is the response header
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:If-Modified-Since, Cache-Control, Content-Type, Keep-Alive, X-Requested-With, Authorization
Access-Control-Allow-Methods:GET, PUT, POST, DELETE, OPTIONS
Access-Control-Allow-Origin:*
Access-Control-Max-Age:1728000
Authorization:apikey="apikey1" AuthenticationToken="62364GJHGJHG"
Connection:keep-alive
Content-Length:240
Content-Type:application/json; charset=utf-8
X-Powered-By:Express
This is the success function
params.success = function (response, textStatus, jqXHR) {
console.log(jqXHR.getAllResponseHeaders())
}
This is what it logs...
Content-Type: application/json; charset=utf-8
Just ran into this. It's because you're doing a CORS request and you're not exposing the Location header.
You need to add a Access-Control-Expose-Headers to your preflight CORS response in Express:
res.header('Access-Control-Expose-Headers', 'Content-Type, Location');
res.send(200);
That will solve the issue.
according to the following
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers
The Access-Control-Expose-Headers response header indicates which headers can be exposed as part of the response by listing their names.
By default, only the 7 CORS-safelisted response headers are exposed:
Cache-Control
Content-Language
Content-Length
Content-Type
Expires
Last-Modified
Pragma
So this will work perfectly for all headers to be accessible and exposed
res.header('Access-Control-Expose-Headers', '*');
Related
I got this:
XMLHttpRequest cannot load
http://62.244.120.89:9000/api/v2/content/categories/sl_1-main/.
Request header field HTTP_LANGUAGE_CODE is not allowed by
Access-Control-Allow-Headers in preflight response.
I found question: Request header field Access-Control-Allow-Headers is not allowed by itself in preflight response
In one answer they suggest to add response headers
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Credentials", "true");
response.setHeader("Access-Control-Allow-Methods", "GET,HEAD,OPTIONS,POST,PUT");
response.setHeader("Access-Control-Allow-Headers", "Access-Control-Allow-Headers, Origin,Accept, X-Requested-With,
Content-Type, Access-Control-Request-Method,
Access-Control-Request-Headers");
Do I do this on server on client ?
You would set the response headers in the server that you are making the request to.
I am making a POST request from a local https server to an ElasticSearch endpoint which has been configured as follows
http.cors.enabled: true
http.cors.allow-credentials: true
http.cors.allow-origin: "*"
http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE
http.cors.allow-headers: X-Requested-With, X-Auth-Token, Content-Type, Content-Length, Authorization, Access-Control-Allow-Headers, Accept
The request has headers:
Access-Control-Allow-Headers: Accept, Access-Control-Allow-Headers, Authorization, Content-Type
Content-Type: application/json; charset=utf-8
Accept: application/json; charset=utf-8
Access-Control-Allow-Credentials: true
Authorization: (basic authentication token)
On a POST request, the following error appears: Request header field Access-Control-Allow-Headers is not allowed by Access-Control-Allow-Headers in preflight response.
The network debugger indeed shows that the Access-Control-Allow-Headers header is not present in the response header. The response header:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://dl.dropboxusercontent.com
Vary: Origin
Access-Control-Allow-Methods:
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1728000
content-length: 0
date: Fri, 29 Apr 2016 14:08:14 GMT
Note that Access-Control-Allow-Headers is not present and Access-Control-Allow-Methods is blank. All possible string formats have been tested, and these headers do not appear.
You should add following signs to your elasticsearch.yml:
http.cors.allow-methods : OPTIONS, HEAD, GET, POST, PUT, DELETE
http.cors.allow-headers : Authorization, X-Requested-With,X-Auth-Token,Content-Type, Content-Length
and then restart the es, enjoy!
I finally solved the problem with these config lines in elasticsearch.yml:
http.cors.enabled: true
http.cors.allow-origin: /https?:\/\/(localhost)?(127.0.0.1)?(:[0-9]+)?/
http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE
http.cors.allow-headers: Authorization, X-Requested-With,X-Auth-Token,Content-Type, Content-Length
As of 2022, according to https://docs.elastic.co/search-ui/tutorials/elasticsearch
try include all headers below
http.cors.allow-origin: "*"
http.cors.enabled: true
http.cors.allow-credentials: true
http.cors.allow-methods: OPTIONS, HEAD, GET, POST, PUT, DELETE
http.cors.allow-headers: X-Requested-With, X-Auth-Token, Content-Type, Content-Length, Authorization, Access-Control-Allow-Headers, Accept, x-elastic-client-meta
In my case, I forget to wrap the end of the line and thus get missing header error.
And this is the top search I got, so just put it here in case anyone made same mistake.
I enabled CORS on server side using:
Header add Access-Control-Allow-Origin "*"
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
Header add Access-Control-Allow-Methods "GET, POST, OPTIONS"
I send a post message using angular $http.post() to server and everything is working good. But if the server is sending 403 header, preflight fails.
header("HTTP/1.1 403 Not allowed");
Whatever I send the same result occurs. Even if I send http status 200.
Cross-Origin Request Blocked:
The Same Origin Policy disallows reading the remote resource at http://api.server.com/.
(Reason: CORS preflight channel did not succeed).
For pre-flight to succeed, an OPTIONS call to the URL must return 200 along with the CORS headers.
The follow up POST (or whatever) can return other status codes, but the OPTIONS request must succeed.
Header always add Access-Control-Allow-Origin "*"
Header always add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
Header always add Access-Control-Allow-Methods "GET, POST, OPTIONS"
Pay attention to the always.
For more information, see Apache doc
I have the following coffee script which performs some sort of login:
signIn: (url, completion) ->
$.ajax
method: 'GET'
url: url
dataType: 'json'
error: (jqXHR, status, errorThrown) ->
completion false, errorThrown
success: (data)->
completion true, data.Identifier
When I check the given URL in the browser I get a valid JSON Response back.
However, when this call is executed using JavaScript I get the following error in the console . Please note that I have changed the URLs for obfuscation:
XMLHttpRequest cannot load http://my.servicedomain.com/session/someIdentifier?access_token=secret.
Origin http://html.server.net is not allowed by Access-Control-Allow-Origin.
These are my headers, which I get from the my.servicedomain.com server:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 1417
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Authorization
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Authorization
Date: Wed, 10 Jul 2013 14:24:35 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Connection: Keep-Alive
Why do I get this error, even though I have Access-Control-Allow-Origin: * in the response header?
I have just figured out the answer myself. I knew that I had duplicated headers in my response, but I was assuming this would not be a problem.
It looks like this is a Problem according to the CORS Spec:
If the response includes zero or more than one Access-Control-Allow-Origin header values, return fail and terminate this algorithm.
This is also described in this SO Thread:
Will duplicate "Access-Control-Allow-Origin: *" headers break CORS?
The server has been modified to send the right request headers.
Server - Response Headers:
Access-Control-Max-Age: 86400
Access-Control-Allow-Methods: GET, OPTIONS, POST
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type, X-Requested-With
I'm using Spring web mvc for the server (a.foo.com), and using mvc interceptors to set the HttpResponseHeaders.
I also attempted setting the origin to the domain of the request, instead of '*'.
Client - jQuery Code
I'm using jQuery/AJAX - jquery 1.7.1
Here is a summary of the POST request.
var settings = {};
settings.url = "http://a.foo.com/api";
settings.type = 'POST';
settings.data = JSON.stringify(request);
settings.dataType = 'json';
settings.contentType = 'application/json; charset=utf-8';
settings.crossDomain = true; // adding or removing this, didn't make a difference
.... (setup callbacks etc)
jQuery.ajax(settings);
The website - html/js is hosted on a.bar.com
Error on Client - javascript console (testing on chrome)
XMLHttpRequest cannot load http://a.foo.com/api. Origin http://a.bar.com is not allowed by Access-Control-Allow-Origin.
Question
Is there anything else I'm missing? I would like to avoid using JSONP, mostly because I require POST support.
Thanks for any pointers, and your help.
I didn't have the response headers set for the OPTIONS request. I was setting it for the GET/POST requests.
Following this blog helped:
http://zhentao-li.blogspot.com/2012/06/enable-cors-support-in-rest-services.html
Now when I hit the endpoint (a.foo.com/api/*) with the request method OPTIONS/GET/POST, I get the following headers:
Date: Wed, 08 Aug 2012 02:58:05 GMT
Connection: keep-alive
Content-Length: 0
Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS
Server: Apache-Coyote/1.1
Access-Control-Max-Age: 1800
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Content-Type: text/plain; charset=UTF-8
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type
I tested this out on Chrome. I wonder if there will be issues with IE! :)
I'd like for this to work with IE9 as well, but from what I read, I shouldn't get my hopes up.
Thanks #Strelok for your suggestions. And #sth and #xdazz.