I have a background task in a Chrome Extension that performs some polling/checking. In error cases, I want to retry the check using a different CDN server to verify if it's a site-wide problem or just a CDN node affected. The challenge is how to control to which CDN node to send to.
e.g. let's say I'm checking www.company.com and typically that will be served by server21.cdn.co
Now if that fails I want to check server5.cdn.co and server10.cdn2.co for the same content to see if there's a correlation.
These checks are done using XMLHttpRequest but I can't find a way to specify which host/proxy to use per-request.
I wouldn't want to "hijack" the entire browser's proxy server settings because it would cause all other pages/tabs to fail.
If it's load-balancing performed on the DNS level (which is most probable), you can't affect which server you actually contact at all.
To clarify, this can't be done because XMLHTTPRequest forbids overriding the Host header in requests. See https://security.stackexchange.com/questions/46702/how-can-i-control-the-content-of-the-http-host-header-in-requests-issued-from-my/ for an explanation of why.
Conceptually/technically it's easy to do if it weren't for this security issue. For example with curl:
curl --verbose --header 'Host: www.example.com' 'http://10.1.1.36/the_url_to_test'
But as mentioned in the question, we're stuck inside a Chrome extension so curl is not an option!
Related
in our company we need to implement a self hosted Rest Service that has to be deployed in the client workstations in order for our internal web applications to interact with them.
The web applications are in https, and we are not using, at the moment, the CSP headers.
Our concern is whether it's necessary to call the local service also in https or this can ne avoided (and so we can avoid to manage a certificate to deploy in every single workstation).
We made some trials with Chrome and Edge and it seems that the ajax calls are working also in plain http, but we would like to know if that is actually supported or not. Our internal web applications are not using, at the moment, the Content Security Policy headers.
Thank you!
On an HTTPS connection browsers will block HTTP content as mixed content, CSP will not change that. However, Chrome will allow mixed content on http://127.0.0.1 and http://localhost while Firefox will allow it on http://127.0.0.1, see note on https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content.
When you implement CSP you should include http://127.0.0.1 (or http://localhost) for the appropriate directive.
I am making a Chrome extension which makes an AJAX call to a local http server. The local server is not https. My extension doesn't work when visiting an https site, because of mixed-content rules.
This is disappointing because I thought the content scripts were totally isolated from the main DOM, so these rules wouldn't matter.
Is there a way to get around this?
You don't have to make the request from the content script itself.
You can delegate that to a background page by requesting it via Messaging.
Also, make sure you have host permissions for your local server. It may even solve the original issue.
Say I have a server that serves an HTML file at the url https://example.com/ and this refers to a css file at the url https://test.com/mystyles.css. Is it possible to push the mystyles.css file alongside the html content as part of an HTTP2 connection, so that a browser will use this css content?
I have tried to create such a request using a self-signed certificate on my localhost (and I have pre-created a security exception for both hosts in my browser) by sending the html file when a request arrives at http://localhost/, and pushing the css with a differing hostname/port in the :authority or Host header. However, on a full-page refresh, the CSS file is fetched in a separate request from the server, rather than using the pushed css file.
See this gist for a file that I have been using to test this. If I visit http://localhost:8080/ then the text is red, but if I visit http://test:8080/ it is green, implying that the pushed content is used if the origin is the same.
Is there a combination of headers that needs to be used for this to work? Possibly invoking CORS?
Yes it is theoretically possible according to this blog post from a Chrome developer advocate from 2017.
As the owners of developers.google.com/web, we could get our server to
push a response containing whatever we wanted for android.com, and set
it to cache for a year.
...
You can't push assets for
any origin, but you can push assets for origins which your connection
is "authoritative" for.
If you look at the certificate for developers.google.com, you can see
it's authoritative for all sorts of Google origins, including
android.com.
Viewing certificate information in Chrome Now, I lied a little,
because when we fetch android.com it'll perform a DNS lookup and see
that it terminates at a different IP to developers.google.com, so
it'll set up a new connection and miss our item in the push cache.
We could work around this using an ORIGIN frame. This lets the
connection say "Hey, if you need anything from android.com, just ask
me. No need to do any of that DNS stuff", as long as it's
authoritative. This is useful for general connection coalescing, but
it's pretty new and only supported in Firefox Nightly.
If you're using a CDN or some kind of shared host, take a look at the
certificate, see which origins could start pushing content for your
site. It's kinda terrifying. Thankfully, no host (that I'm aware of) offers full control over HTTP/2 push, and is unlikely to thanks to this little note in the spec: ...
In practice, it sounds like it's possible if your certificate has authority over the other domains and they're hosted at the same IP address, but it also depends on browser support. I was personally trying to do this with Cloudflare and found that they don't support cross-origin push (similar to the blog post author's observations about CDNs in 2017).
We use Apigee proxy to invoke our API. All works well when we test it out within Apigee trace. Also works fine with curl. But on a browser, it gives a 503. This is not consistent though, sometimes it gives a 200 on the browser too. Tried Chrome and Firefox, same behavior.
Our API still executes well though. We do not return any response, merely set the status. Any ideas on what we could try out to get a 200 on the browser?
Couple of things to check:
Check if your Browser has a DNS entry caching. Sometimes services like ELB changes the actual IPs. So caching DNS entries may result in 503.
Another you may want to check is the difference is in the HTTP Verb used. Browsers send a GET request. But curl commands can do all. So if your service is specifically not serving GET calls you may get some server side errors. Also curl sends certain headers even if you do not explicitly send. E.g., Accept:/ header and user-agent header etc. Check if the server is behaving differently based on those headers.
You should look into using Chrome or Firefox extensions for this. There are two in particular which support a wide range of additional features for API developers.
For Chrome, try Postman.
For Firefox, try RESTClient.
Thanks.
I'm new to xmlhttprequest, and I need a little help with cross origin requests.
I make a xmlhttprequest from web service, everything is going nice and smooth from my local host.
but when I'm running from the server I get cross-origin exception (that's because the origin (site) and the web service are not located at the same location)...
I've tried to set the Access-Control-Allow-Origin to '*' threw req.setRequestHeader function without success.
P.s I'm writing in javascript.
I'll be glad for any help.
Well the answer is:
We can't locate our client files in one server and make a httprequest to another,
for security reasons the browser blocks the request...
so the options are:
To locate both client & server files in on the same server.
There couple ways to manipulate the server which include changing scripts in the server files (really not recomended for beginners... )
Enjoy