I am working on some projects and I came across a problem.
The main problem is this:
When I go to an API end-point by typing the at the browser, it loads the html page returned.
However, if I hit the same end-point using the Fetch API in an onclick listener, it does not load the page. I am sure the html page arrives as a part of the response tho.
I investigated the problem to see what is causing it. I realized that the request headers differ slightly when the browser is making the request vs fetch api making the request.
The main difference is this:
Browser version:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Fetch API version:
Accept: */*
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
I tried modifying these specific headers to match the browser version in the fetch request however, no matter how much I tried, they did not change.
I now know what to do to get the desired functionality. I can either use windows.location and make browser reload or I can use redirect function in my express js server.
What I am asking is this:
Are those headers what making my html page not load when the request is sent from a button using Fetch API?
What are those headers doing?
Are they not modifiable if so, why?
Related
I'm working on a web app and I'm having the following problem:
When I go on some page my server sends a response with cache-control: no-cache header.
Then I do some changes (graphql mutations) on that page.
When I go to an other page and then click browser back then my browser reads the outdated "response" from the disk cache instead of sending a request to the server to get the change data.
browser loads response from cache although no-cache header is set
I wondering if there is something missing in my headers telling the browser to not use the disk cache?
Some info:
The browser does not send a request to my server. (So it is not cached somewhere else.)
It is not the back-forward cache. (There is already some logic handling the bfcache.)
I can reproduce it in all my browsers. (e.g. Firefox, Chrome, ...)
When I disable the disk cache in the Firefox settings then it is working correctly. (Now, the bfcache kicks in.)
I also found the following thread. Is there a better solution?
Chrome is caching even with HTTP no-cache headers
Just curious, I can see some http2 pseudo headers fields like :method,
:scheme,:authority when I go to some website that has enabled http2.
Example, for homepage of www.ft.com, there are these pseudo request headers:
:authority:www.ft.com
:method:GET
:path:/
:scheme:https
Is it possible to read/modify those fields in chrome extension, just like we can read/modify Cookie, Referer, User-Agent?
Or if it is not possible in chrome, can we do it in other browsers like firefox?
So all HTTP/2 headers start with a : (to distinguish them from HTTP/1.x headers)
Not aware of any extensions to alter them, but I guess the real question is why would you want to?
I'm trying to protect a Classic ASP web application from HTTP Header Injected XSS attacks and am having trouble finding a solution that stops scripts found in the User Agent String.
Here is an example HTTP request to the web application:
HTTP Request
GET /WebApp/Login.aspx HTTP/1.1
Host: WebServer.Webapp.Com
User‐Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0**alert(1)**
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
Cookie: ASP.NET_SessionId=foobarID
Connection: keep‐alive
Basically what we're trying to do is keep that alert script in the User Agent String from firing off when the page is loaded. I've been doing a lot of research and haven't been able to find too much help for this old app.
We do have validateRequest and EnableHeaderChecking set to true, But this script still executes. Any help is really appreciated.
The issue was from the user agent string (with the malicious script) being rendered on the page at the bottom for debug purposes. If you're having this issue, please check that you aren't displaying the object with the bad script on the page.
If you are, than remember to use HTML Encoding to render it safely.
Thanks to the_lotus and Lankymart for the quick answers.
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.
I'm attempting to communicate with Domino via REST via a cross domain request, but I'm encountering an issue. I've setup an Internet Site document with the IP Address, localhost and a server name listed as the host names. The internet site is working as a redirect rule I've setup on that internet site is working. I've also setup a Web Site Rule with the following:
Now when I attempt to hit the rest.xsp page via an html GET request I'm getting this error:
XMLHttpRequest cannot load
http://192.168.1.104/testing/restService.nsf/rest.xsp/testRest?reqType=UserCanAc…TOP&startId=BA4241EC74912860ED60FD1123473BF7&returnType=ARRAYOBJECTS.
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin
'http://127.0.0.1:8020' is therefore not allowed access.
Here are the request headers:
Accept:application/json, text/javascript, */*; q=0.01
Cache-Control:max-age=0
Origin:http://127.0.0.1:8020
Referer:http://127.0.0.1:8020/Backbone%20Playground/index.html
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36
I can't for the life of me figure out what I've missed. Can someone point me in the right direction?
The CORS header is part of the response, so you need to check if you get a CORS response header with your page. In any case, for an XPage you can get direct access to the servlet response object and set the header in your XPage:
var externalContext = facesContext.getExternalContext();
var response = externalContext.getResponse();
response.setHeader("Access-Control-Allow-Origin","*");
You want to replace the * with a little more restrictive setting. Cors doesn't work in all browsers, so you need to check that end too.
I think your configuration is fine and you can test it using CURL . You should be able to see the Custom Headers by checking any URL different to the one you're using.
The problem, maybe, is due to the XPages Extension Library control, REST Service, you're using. I think the "HTTP response headers" are not applied for this control. I've tested it in Domino 8.5.3
I know this is kinda old thread but since it's not being answered and there are some news, I think it's worth throwing in my own findings.
Mark Leusink caved into this and discovered that there's a need to accept also return code 204 for GET and 201 also for any write (PUT / POST) operations
There is now a new possibility to include a fourth Response Header to all website rules by the means of notes.ini parameter "HTTPAdditionalRespHeader=", see this technote
However, I'm also struggling on completing a CORS task currently, because Domino always responds with an 401 to the preflight (which seems clear as it comes unauthenticated, at least within Chrome).