I am optimizing an Express JSON API for consumption by iOS & Android Apps and do not seem to be able to get Express to respond with the correct 304 header when the Apps specify an etag within the If-None-Match header.
I needn't setup Etag generation as Express was already providing those; however when the Apps specify that etag again in a second request; Express' response is still a 200 with the data, as you can see in my tests in Postman:
How can I enable this functionality?
Update: The iOS dev is seeing the correct 304 Not Modified responses from the Express server but I don't understand why I am not seeing them within Postman - Does Postman support such actions?
I just stumble across this today, you need to disable Postman default behaviour of sending Cache-Control as none. To do this just go to settings change Send no-cache header to No.
Related
I have a doubt related to the hsts response header. I'm developing a web application and currently I covered all the endpoints (with 200 ok responses)... this means that all the endpoints will return the hsts header when the response is 200. I don't know if it is needed for the server errors too. Thanks!
We usually include the HSTS header in all server responses no matter which HTTP status code is provided. In most cases this is easier to implement than everything else (either through config or one dedicated filter to rule them all). On the other hand there is no reason not to do it this way - the TLS channel has been opened successfully.
EDIT: Oh, and there are some other opinions on this too: https://security.stackexchange.com/questions/122441/should-hsts-header-be-sent-on-an-error-response
I'm programmatically downloading a file from a Sharepoint 2016 document library. The URL goes:
https://hostname.com/Site/Folder/_layouts/15/download.aspx?{long, long URL}
The site emits the ETag header, but when I send a request with an If-None-Match, providing the ETag I just got, there's no 304 Not Modified response, it's 200 and the whole document again.
The ETag header I'm receiving goes:
ETag: "{EED54197-A30B-4625-9EBA-8DC7F9D62CF3},1435"
The request header then goes:
If-None-Match: "{EED54197-A30B-4625-9EBA-8DC7F9D62CF3},1435"
I'm testing the same setup against a static file in IIS - it works as expected, 304 comes.
What am I missing, please? Could it be an oversight in the Sharepoint API?
EDIT: one unsatisfactory workaround involves firing a HEAD request first and manually matching the ETag values on the client.
So I'm trying to implement the OAuth 2 flow, while my webapp is the server that give away authorization code/access token.
Cors error happens when sending the code back to third-party website(zapier in this case):
XMLHttpRequest cannot load https://zapier.com/dashboard/auth/oauth/return/App505CLIAPI/?code=somecode&state=somestate. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://myurl' is therefore not allowed access.
If I manually open a new tab, paste that zapier uri, everything works perfectly.
Seems like a typical CORS issue, but none the popular solutions works for me:
Add Access-Control-Allow-Origin: I'm using this oauth2orize
library, and sending reponse to preflight seems also part of the
library. So I cannot add header.
Using cors: Have tried app.use(cors()) and app.options('*',
cors()) which should apply to all routes, but simply not working.
My webapp sits on a node express server, in front of which there's an nginx proxy server.
Any idea where the problem might be is appreciated.
The issue that error message indicates isn’t caused by the app code running at https://myurl/. Instead it’s just that https://zapier.com/dashboard/auth/… doesn’t seem to support CORS.
Specifically, the response from that https://zapier.com/dashboard/auth/… URL doesn’t include the Access-Control-Allow-Origin response header, so your browser won’t let your frontend JavaScript code access the response.
It seems like that is all intentional on the part of Zapier—they don’t intend for that auth endpoint to be accessed from frontend AJAX/XHR/Fetch code running in a browser. Instead I guess it’s intended that you only access that auth endpoint from your backend code. Or something.
Anyway there is no way from your side that you can fix the fact the response from that Zapier API endpoint doesn’t include Access-Control-Allow-Origin.
And as long as it doesn’t include Access-Control-Allow-Origin, your browser blocks your frontend code from being able to get to the response—and there’s no way to get your browser to behave otherwise as long as your frontend code is trying to hit that API endpoint directly.
So the only solution is to not hit that API endpoint directly from your frontend code but to instead either set up a proxy and change your frontend code to make the request through that, or else just handle it in some other way in your existing backend code, as mentioned above.
The answer at Why does my JavaScript code receive a "No 'Access-Control-Allow-Origin' header is present on the requested resource" error, while Postman does not? gives some details on how you can set up a special CORS proxy, if you want to go that route.
We have come across an issue in production logs where "Accept-Language" is missing in the http request from the browser. Although I am not able to replicate it so I want to understand any valid use case where any specific browser may send a request without "Accept-Language" header.
Even GET / HTTP/1.0 is a valid HTTP request. You can create one from the telnet client if you wish and it will still return a result from the server!
Accept-Language is a header to aid in content negotiation and is optional. The most widely used browsers send the correct headers, but there may be corporate proxies who may be filtering such headers. You should not rely on this header being present.
If I have configured Access-Control-Allow-Origin: http://mydomain correctly, should it be listed in the response headers if I view them using the web developer plugin? I don't see it. Should it be there?
I have tried viewing the response headers after submitting my post request, and just calling the page.
Background
I need to transfer a couple of values from mydomain to receivingdomain via XMLHttpRequest POST request and am trying to troubleshoot
XMLHttpRequest Page1.asp cannot load https://receivingdomain. No Access-Control-Allow-Origin header is present on the requested resource
If I turn on the Allow-Control-Allow-Extension plug-in my post requests work correctly. However, when this plug-in is disabled, my post requests are being received ok (the data is inserted into the database) - I'm just not getting any result back from the receiving server.