I have a web app that returns a PDF to the browser, which works fine in Chrome and Firefox, however it does not work in Edge (version 38.14393.0.0). The response header looks like this:
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Origin: *
Cache-Control: no-store, no-cache, must-revalidate
Content-Disposition: inline; filename="Invoice.PDF"
Content-Length: 9255
Content-Type: application/pdf
Date: Mon, 30 Jan 2017 04:38:25 GMT
Pragma: no-cache
Server: Microsoft-IIS/10.0
I've seen other questions suggesting that 2 requests are sent from Edge, one of which should be ignored, but in my case there is only one, and it appears that the payload is being ignored because Edge reports:
This resource has no response payload data
..which is in the Response Body section for the request in the Network analyzer in Developer Tools. Using attachment instead of inline also does not work, and I wouldn't expect it to if Edge thinks there's no content in the response.
Any clues?
Edit: When the Content-Type is changed to: text/plain, the response body is no longer being discarded (but does not solve the problem), so I assume it's something specific to application/pdf
In my case, it appears the payload data is being discarded because I was attempting to use createObjectURL on the result. This post:
Setting window.location or window.open in AngularJS gives "access is denied" in IE 11
Has a solution that kind of works: Edge still does not actually open the PDF like other browsers are capable of, however it gives the user the option to save it.
Related
I'm trying to implement a UI5 service using an OData v4 backend.
In general my bindings seem to work, however, there seems to be a problem parsing the headers of the batch requests. Parsing the batch parts by skipping the code in the debugger works fine.
In the console I get the following error:
2022-10-11 13:14:09.584899 $batch failed - Error: Expected 'OData-Version' header with value '4.0' but received value 'null' in response for http://localhost:8080/odata/$batch
at h.doCheckVersionHeader (http://localhost:1337/resources/sap/ui/core/library-preload.js:4753:314)
at Object.<anonymous> (http://localhost:1337/resources/sap/ui/core/library-preload.js:4786:415)
at Object.<anonymous> (http://localhost:1337/resources/sap-ui-core.js:2099:9272)
at p (http://localhost:1337/resources/sap-ui-core.js:2219:26833)
at Object.fireWith [as resolveWith] (http://localhost:1337/resources/sap-ui-core.js:2219:27676)
at y3 (http://localhost:1337/resources/sap-ui-core.js:2219:84906)
at XMLHttpRequest.<anonymous> (http://localhost:1337/resources/sap-ui-core.js:2219:87536) sap.ui.model.odata.v4.ODataModel`
However, inspecting the headers in the developer tools the OData-Version header seems to be set
HTTP/1.1 202
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Access-Control-Allow-Origin: *
OData-Version: 4.0
Content-Type: multipart/mixed;boundary=batch_63059dbf-3e96-4650-b6b9-c6237b7e3b9e
Content-Length: 3848
Date: Tue, 11 Oct 2022 11:14:06 GMT
Keep-Alive: timeout=60
Connection: keep-alive
In the function h.doCheckVersionHeader only the Content-Type and Content-Length are aviable.
I start my project via ui5 serve and seem to be using version 1.102.1.
Does anyone know how I can get the requests to work?
I have resolved the issue by adding the
Access-Control-Expose-Headers header to the response: https://github.com/SAP/openui5/issues/3613#issuecomment-1274609280
The section "Response Headers" from the documentation topic "Model Instantiation and Data Access" now lists headers that need to be added to the Access-Control-Expose-Headers response header:
The OData model processes some of the response headers, namely:
DataServiceVersion (only when consuming an OData V2 service),
Date,
ETag,
OData-Version,
Preference-Applied,
Retry-After,
SAP-Messages,
X-CSRF-Token.
Some SAP applications will also require the processing of SAP-ContextId, SAP-Err-Id, and SAP-Http-Session-Timeout. When using cross-origin resource sharing (CORS), it is important to add all these headers to the Access-Control-Expose-Headers response header.
Also, make sure that values assigned to the headers are syntactically valid. E.g. no dangling characters: OData-Version: 4.0; → OData-Version: 4.0.
I have a WCF service which I make API requests to.
This API call returns a JSON response object and also is able to return it in GZIP compression as well when "gzip" value is used in "Accept-Encoding" header.
The problem is when I try to get the response in GZIP, Postman shows "Could not get any response" although I see response and response's content are OK (200 status code) in Fiddler and can easily decompress the response content in my C# client.
I took a look in Postman Console but all I see is "Error: incorrect header check".
I hardly tried to find any documentation regarding this header check but couldn't find any.
These are the request headers:
POST /correction/v1/document?lang=US HTTP/1.1
Content-Type: text/plain
Accept-Encoding: gzip
User-Agent: PostmanRuntime/7.6.0
Accept: */*
content-length: 630
Connection: close
These are the response headers:
HTTP/1.1 200 OK
Content-Length: 512
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Server: Microsoft-HTTPAPI/2.0
Date: Sun, 24 Feb 2019 14:05:50 GMT
Connection: close
The only thing I suspect is wrong is this message from Fiddler:
I integrated this code into mine in order to use GZIP in WCF.
https://github.com/carlosfigueira/WCFSamples/tree/master/MessageEncoder/GZipEncoderAndAutoFormatSelection
Basically, it captures the response before returning to client and use GZipStream for compression.
I got the same issue, I added the following header to fix this issue.
Accept-Encoding : *
I was able to solve a similar issue by using the header Accept-Encoding: */* or if you want to be specific do Accept-Encoding: */* that way the HTTP client will be able to process the response based on the type of encoding received, in the case of a gzip, it will decode the response and show it as normal text.
For me, I removed 'Accept-Encoding' in the request header.
I got this issue when the REST service was returning a zip content (aka. WinZip format). I solved the error by compressing the data using 7zip to produce true gzip format.
I'm trying to collect and download my lifelog user data. The first step into doing this is getting a user-access token. I am encountering problems while requesting authorization.
From the sony developer authenticization page I am told to input the following code into my API explorer:
https://platform.lifelog.sonymobile.com/oauth/2/authorize?client_id=YOUR_CLIENT_ID&scope=lifelog.profile.read+lifelog.activities.read+lifelog.locations.read
I am supposed to receive the authorization code as such:
https://YOUR_CALLBACK_URL?code=abcdef
However, this is what the current situation is actually like:
I have replaced my actual client ID below with MY_CLIENT_ID for security reasons
INPUT:
GET /oauth/2/authorize?client_id=MY_CLIENT_ID&scope=lifelog.profile.read%2Blifelog.activities.read%2Blifelog.locations.read HTTP/1.1
Authorization:
Bearer kN2Kj5BThn5ZvBnAAPM-8JU0TlU
Host:
platform.lifelog.sonymobile.com
X-Target-URI:
https://platform.lifelog.sonymobile.com
Connection:
Keep-Alive
RESPONSE:
HTTP/1.1 302 Found
Content-Length:
196
Location:
https://auth.lifelog.sonymobile.com/oauth/2/authorize?scope=lifelog.profile.read+lifelog.activities.read+lifelog.locations.read&client_id=MY_CLIENT_ID
Access-Control-Max-Age:
3628800
X-Amz-Cf-Id:
HILH9w3eOm-6ebs_74ghegYQyWS4xyqA1l0gXPRJuuubsoZ6eiiS3g==
Access-Control-Allow-Methods:
GET, PUT, POST, DELETE
X-Request-Id:
76caccfc976d40259ef30415d10980e9
Connection:
keep-alive
Server:
Apigee Router
X-Cache:
Miss from cloudfront
X-Powered-By:
Express
Access-Control-Allow-Headers:
origin, x-requested-with, accept
Date:
Sun, 22 Jan 2017 03:00:42 GMT
Access-Control-Allow-Origin:
*
Vary:
Accept
Via:
1.1 dc698cd00b7ec82887573cfaba9ecca6.cloudfront.net (CloudFront)
Content-Type:
text/plain; charset=utf-8
Found. Redirecting to https://auth.lifelog.sonymobile.com/oauth/2/authorize?scope=lifelog.profile.read+lifelog.activities.read+lifelog.locations.read&client_id=MY_CLIENT_ID
Nowhere can I see the authorization code in the above code. I even tried copying and pasting the URL (on the last line) into my browser, it says "localhost.com took too long to respond"
This is where I input my request
I am not sure whether it is an issue with the callback URL. I don't have an actual website or app made, I just used the default localhost
I am a beginner in this and would really appreciate all help.
A page at http://www4.example.com that tries to an xhr connection to http://www6.example.com/
The browser sends a GET request with this header:
Origin: http://www4.example.com
The www6.example.com server sends back:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://www4.example.com
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/plain
Date: ...
Keep-Alive: timeout=5, max=100
Transfer-Encoding: Identity
Server: Apache/2.2.20 (Ubuntu)
Vary: Accept-Encoding
X-Powered-By: PHP/5.3.6-13ubuntu3.7
And yet I get:
XMLHttpRequest cannot load http://www6.example.com/myscript.php?xhr=1&t=1234333223. Origin http://www4.example.com is not allowed by Access-Control-Allow-Origin.
My code matches my understanding of the CORS standard, and works fine with Chrome, Firefox, Opera, etc. so I'm going to assume this is a Safari 5.1 bug? My question is what do I need to do to work around it?
After a lot of trial and error, and watching network traffic, I think I can self-answer.
The Safari bug is that it sends an OPTIONS pre-flight request first, even though it is a GET request.
To add some extra complexity, it appears to only send this on the 2nd request. (I think this is because my 2nd request sends an extra custom header... but I couldn't actually isolate that, so I think there is something else going on as well - perhaps cache interactions?)
Sending Access-Control-Allow-Headers in the main response does not fix the problem: it does the OPTIONS request first, so never gets that far.
The fix I did was to put this at the very top of the PHP script:
if($_SERVER['REQUEST_METHOD'] == 'OPTIONS'){
header("Access-Control-Allow-Origin: ".#$_SERVER['HTTP_ORIGIN']);
header("Access-Control-Allow-Credentials: true");
header("Access-Control-Allow-Headers: Last-Event-Id, Origin, X-Requested-With, Content-Type, Accept, Authorization");
exit;
}
Sending back "Access-Control-Allow-Headers: *" did not work. You have to explicitly list the headers you want. I briefly experimented and it appears they are case-insensitive.
Sending back "Access-Control-Allow-Methods: POST, GET, OPTIONS" was not needed.
As an aside, Cookies are sent, but basic auth details are not sent (despite explicitly listing the Authorization header there). This might be a deliberate limitation of the CORS implementation, as of this version of WebKit (534.57.2), not a bug.
I use Fiddler to debug my application. Whenever the response is compressed by server, instead of decompressed response, Fiddler shows unreadable binary data:
/* Response to my request (POST) */
HTTP/1.1 200 OK
Server: xyz.com
Date: Tue, 07 Jun 2011 22:22:21 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.3.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Encoding: gzip
14
����������������
0
How can I get the response decompressed?
I use fiddler version 2.3.4.4 and just noticed that in the Inspectors tab ("Raw" sub-tab), above the response section (in case of gzip-ed response), appears "Response is encoded and may need to be decoded before inspection. Click here to transform."
If you click on that, the response becomes readable.
The settings are pretty much the default, I just installed Fiddler and did not change anything.
If you don't want to have to click per response as in the accepted answer, using the menu, click Rules -> Remove All Encodings.
From the fiddler faq
Q: I like to navigate around a site then do a "search" for a text on all the logged request/responses. I was curious if Fiddler automatically decompressed gzipped responses during search?
A: Fiddler does not decompress during searches by default, since it would need to keep both the compressed and decompressed body in memory (for data integrity reasons).
In current versions of Fiddler, you can tick the "Decode Compressed Content" checkbox on the Find dialog.
Here is a link to the site
http://www.fiddler2.com/fiddler/help/faq.asp