I am requesting mock server with redirect response (HTTP 303)
When I am checking network in Google Chrome (v66.0.3359.170), I can see one additional GET request compared to Firefox (v60.0 Ubuntu)
Request
req.open("POST", "http://localhost:9001/rederict", true);
req.send();
Response for http://localhost:9001/rederict
HTTP/1.1 303 See Other
Location: http://localhost:9001/response
Content-Type: application/json; charset=utf-8
Access-Control-Allow-Origin: *
Response for http://localhost:9001/response
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Access-Control-Allow-Origin: *
{ "Random": "content" }
Firefox network
Chrome network
Is there any reason why chrome requests one additional GET? (the same situation apply if in request I am using GET instead of POST)
Related
As I know that if cors request comes with some extra headers set, first server needs to process it.
With CORS, the server must send the Access-Control-Allow-Headers header to allow uncommon request headers from the client.
Access-Control-Allow-Headers ... - Comma-delimited list of the supported request headers.
e.g suppose my pre-flight request is
OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...
Then from server-side I will send response
Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8
My question is -
should I close the connection on server side while we send pre-flight response to client?
One more thing how can I cached pre-flight request for all other distinct subsequent requests?
Thanks
You could cache the OPTIONS request using the
Access-Control-Max-Age
header.
Attach it to the headers collection of the OPTIONS response.
But nevertheless an initial OPTIONS request by the user agent (browser) has to be made, you cannot avoid this.
But all further OPTIONS requests are cached and not issued to the server.
No need to close the connection.
Access-Control-Allow-Origin: http://hello-world.example
Access-Control-Max-Age: 3628800
Access-Control-Allow-Methods: PUT
as explained here, search for
could have the following headers specified
to get to the designated text section.
I have been encountering error in storing a file to Object Storage using HTTP POST method sent using Async XMLHttpRequest. The request is a CORS HTTP request sent to the Object storage public URL with required headers set. The error message says: Reason: CORS header Access-Control-Allow-Origin missing.
The error seems to happen with multipart form data send request using POST. If PUT is used to create the file, the required file (resource) gets created. The response to the PUT request contains the required Access-Control-Allow-Origin header, whereas the response to POST does not contain despite the meta data attributes being set on the container.
I have even tried using X_AUTH_TOKEN header instead of X_STORAGE_TOKEN, but the failure continues to happen.
Raised the ticket with Softlayer support, but have not received a solution. Any ideas to resolve the above would be helpful.
The details are below:
The container prod_file has following meta data attributes set:
access-control-expose-headers: Access-Control-Allow-Origin
access-control-allow-origin : *
The Firefox browser version is: Mozilla Firefox 46.0
Client OS is: Linux 3.16.0-71-generic #91~14.04.1-Ubuntu SMP Mon Apr 18 1K9:43:36 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Request URL: https://*****.objectstorage.softlayer.net/v1/AUTH_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/prod_file/6ffb51fc-e40f-4cf5-982c-44cb5c342851.fl.file.orig.txt
Request HTTP Method: POST
Mechanism used: Async XMLHttpRequest
Request Headers:
Host: *****.objectstorage.softlayer.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-Storage-Token: AUTH_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Referer: http://*****myorg******.com/organization/572680760cf26af856c7432c/resources
Content-Length: 4500
Content-Type: multipart/form-data; boundary=---------------------------2139255891192408661525197545
Origin: http://*****myorg******.com
Connection: keep-alive
Response Headers:
Connection: keep-alive
Content-Length: 50
Content-Type: text/plain
Date: Sat, 14 May 2016 14:57:02 GMT
X-Trans-Id: *****Some Transaction Id********
The error response has the following message:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://*****.objectstorage.softlayer.net/v1/AUTH_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/prod_file/6ffb51fc-e40f-4cf5-982c-44cb5c342851.fl.file.orig.txt. (Reason: CORS header 'Access-Control-Allow-Origin' missing)
Thanks for the help in advance.
It looks like you set wrong the headers for your container, please take a look this documentation and try it:
http://docs.openstack.org/developer/swift/cors.html
https://swiftstack.com/blog/2013/04/02/using-cors-with-swift/
Renember that softlayer object storage is based in Open Stack.
Let me know if you are still having troubles
Regards
While trying to redirect user to a URL, it works with GET requests but not with postback requests.
Through firebug's Network window, I can see the redirect response received by browser after the postback request (that should cause redirect) completes. The browser seemingly initiates a GET request for the redirect URL but doesn't actually successfully redirect. It remains there on the same page.
I use JSF server side. The initiated GET request is not received at all by the server. However initiated by the browser on server's demand. I guess problem is somewhere client side only
Can anyone please explain how to make redirect work successfully ? Let me know incase I should provide any more information.
Edit:
Request header for redirect:
GET /Px10Application/welcome.xhtml HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: application/xml, text/xml, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://localhost:8080/Px10Application/channelPages.xhtml?channelId=-3412&type=Group
X-Requested-With: XMLHttpRequest
Faces-Request: partial/ajax
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: hb8=wq::db6a8873-f1dc-4dcc-a784-4514ee9ef83b; JSESSIONID=d40337b14ad665f4ec02f102bb41; oam.Flash.RENDERMAP.TOKEN=-1258fu7hp9
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Response header for redirect:
HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1 Java/Sun Microsystems Inc./1.6)
Server: GlassFish Server Open Source Edition 3.1
Set-Cookie: oam.Flash.RENDERMAP.TOKEN=-1258fu7hp8; Path=/Px10Application
Pragma: no-cache
Cache-Control: no-cache
Expires: -1
Content-Type: text/xml;charset=UTF-8
Content-Length: 262
Date: Wed, 22 May 2013 17:18:56 GMT
X-Requested-With: XMLHttpRequest
Faces-Request: partial/ajax
You're thus attempting to send a redirect on a JSF ajax request using "plain vanilla" Servlet API's HttpServletResponse#sendRedirect(). This is not right. The XMLHttpRequest does not treat a 302 response as a new window.location, but just as a new ajax request. However as you're returning a complete plain vanilla HTML page as ajax response instead of a predefined XML document with instructions which HTML parts to update, the JSF ajax engine has no clues what to do with the response of the redirected ajax request. You end up with a JS error (didn't you see it in the JS console?) and no form of visual feedback if you don't have the jsf.ajax.onError() handler configured.
In order to instruct the JSF ajax engine to change the window.location, you need to return a special XML response. If you have used ExternalContext#redirect() instead, then it would have taken place fully transparently.
externalContext.redirect(redirectURL);
However, if you're not inside JSF context, e.g. in a servlet filter or so, and thus don't have the FacesContext at hands, then you should be manually creating and returning the special XML response.
if ("partial/ajax".equals(request.getHeader("Faces-Request"))) {
response.setContentType("text/xml");
response.getWriter()
.append("<?xml version=\"1.0\" encoding=\"UTF-8\"?>")
.printf("<partial-response><redirect url=\"%s\"></redirect></partial-response>", redirectURL);
} else {
response.sendRedirect(redirectURL);
}
If you happen to use JSF utility library OmniFaces, then you can also use Servlets#facesRedirect() for the job:
Servlets.facesRedirect(request, response, redirectURL);
See also:
Authorization redirect on session expiration does not work on submitting a JSF form, page stays the same
JSF Filter not redirecting After Initial Redirect
I'm trying to get Firefox to allow me to make an XmlHttpRequest for data from an application port.
I can see that the initial send triggers an OPTIONS message, and I have trapped this using NetMon, and I can see the HTTP fields...
OPTIONS /any.htm HTTP/1.1
Host: www.mysite.co.uk:10090
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Origin: http://www.mysite.co.uk
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
I respond to this with an OK to tell FireFox to get a move on and send me the data in the XHR request...
HTTP/1.1 200 OK
Access-Control-Allow-Methods: POST,-GET,-OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 172800000
Server: Kawasu-OrderSub
Date: Wed, 23 Jan 2013 15:00:50 GMT
But the POST is never sent, which I assume means that FireFox is not happy with the 200 OK response. The POST sends data with a Content-Type of "application/json"
I've got FireBug and the Net tab has the XHR button, but this will only show the XHR after the pre-flight check has been passed.
Main Question: How can I see (and debug) what FireFox does not like about the server response?
Much obliged for any help in advance.
You need to include the Access-Control-Allow-Headers: content-type response header. This is because the request has the Access-Control-Request-Headers: content-type header, and this value needs to be included in the response.
I'm getting some odd response back from shopify ajaxapi for jsonp.
If you cURL a Shopify ajax api location
http://storename.domain.com/cart.json?callback=handler
you will get a jsonp response. But something is breaking the same request in browsers.
It appears to be related to compression? Here are some responses from each browser when attempting to call the jsonp as documented.
Firefox: The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.
Internet Explorer: Internet Explorer cannot display the webpage
Chrome/Safari/Webkit: Cannot decode raw data, or failed (chrome)
Attempted use via jquery:
$.getJSON('http://storename.domain.com/cart.json?callback=?', function(data) { ... });
// Results in a failed request, viewable network request panels of dev tools
Here is some output from cURL including response headers:
$ curl -i http://storename.domain.com/cart.json?callback=CALLBACK_FUNC
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 18 Dec 2012 13:48:29 GMT
Content-Type: application/javascript; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Status: 200 OK
ETag: cachable:864076445587123764313132415008994143575
Cache-Control: max-age=0, private, must-revalidate
X-Alternate-Cache-Key: cachable:11795444887523410552615529412743919200
X-Cache: hit, server
X-Request-Id: a0c33a55230fe42bce79b462f6fe450d
X-UA-Compatible: IE=Edge,chrome=1
Set-Cookie: _session_id=b6ace1d7b0dbedd37f7787d10e173131; path=/; HttpOnly
X-Runtime: 0.033811
P3P: CP="NOI DSP COR NID ADMa OPTa OUR NOR"
CALLBACK_FUNC({"token":null,"note":null,"attributes":{},"total_price":0,...})
Also related unanswered here:
https://stackoverflow.com/questions/13750841/shopify-ajax-api-jsonp-supported
Thanks