Does Safari support Link rel=preload headers for XMLHttpRequest? - javascript

I'm trying to optimise the speed of some web page that loads some JSON data using XMLHttpRequest from the same origin. I have added the Link HTTP header to the response of the web page, like this:
Link: </api/endpoint>; rel=preload; as=fetch; crossorigin
This works fine in Chrome. I see that the API endpoint is requested once (due to the preload instruction), and then used for the XMLHttpRequest.
However, in Safari it does not work. I see that the API endpoint is requested twice (once due to the preload instruction, and once more for the XMLHttpRequest). Also, a warning shows up in the console:
[Warning] The resource https://my-origin.com/api/endpoint was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it wasn't preloaded for nothing.
I have tried several variants of the Link headers (without crossorigin and with crossorigin=use-credentials). I also tried setting withCredentials=true on the XHR object. None of those combinations gave a different result.
I read some other question/answer, where it was explained that preloading fetch requests is possible by using mode: "no-cors". However, it is not possible to set that mode for XMLHttpRequest.
Is it possible to preload XMLHttpRequests (from the same origin) in Safari?

Related

Allow cross-origin JS import to absolute URL in Firefox

Let's say I have two apps running, Client & Server. The Client is running on https://my.app.com and the Server on https://some.server.com. In addition to delivering data, the Server offers some (trusted) JavaScript content that can be imported and run. I might do that with:
await import(urlToContent); // e.g. https://some.server.com/my/amazing/javascript/web-component
However, the Server is often secured with credentials (in our case a cookie). For the API, we can set {credentials: 'include'} in our fetch requests to solve this (except in Chrome incognito, where Chrome prevents it anyway). This works with the following CORS headers sent by the server:
Access-Control-Allow-Credentials "true"
Access-Control-Allow-Origin "https://my.app.com"
Access-Control-Allow-Headers "Content-Type"
In order to make this work with the import statement, we added crossorigin="use-credentials" to the encompassing script tag:
<script crossorigin="use-credentials">
import('/src/main.ts'); <!-- at some point performs a dynamic import to the external address on Server -->
</script>
Although this is less than ideal (we only need it for the single dynamic import deep in the code), it is a dev environment and it works in Chrome (except in Incognito) and Edge. However, it does not work in Firefox, Private Browsing or no.
Is there another way of accomplishing this or some extra steps that are required to make it work in Firefox?
N.B.
Further things we've tried are adding more headers to the Access-Control-Allow-Headers, e.g. Origin and Host, but this would not explain why FF has no problem with the fetch requests.

Fetch API - Download Headers Only [duplicate]

Here I have this sample fiddle, where I try to get only the content-type header from a large image, using both XMLHttpRequest() and fetch() in Javascript. If you run the fiddle with Chrome's Developer Tools / Network tab (or similar tools in other browsers) open, you'll see that while the XMLHttpRequest() method gets only the 600 B where the headers are located, the fetch() method gets the whole 7.8 MB image, despite my code only needing the content-type headers.
How can I get just those few bytes needed for the headers (instead of the whole content) using the Fetch APi's fetch()?
Note: I am interested in this, because apparently, if I try to get the headers of all the links of a regular Google page, the XMLHttpRequest() method logs me out and sometimes changes my language as well, while the fetch() method does not. I assume this is because the former sends the credentials / cookies / etc., while the latter is more 'restrictive' by default...
You need to specify the method type of HEAD:
fetch(url, {method: 'HEAD'})
See updated fiddle

From Chrome extension, how to prevent Chrome from also automatically requesting resources from response’s rel=preload Link response headers?

I have written a webextension for Chrome which can query bookmarks to see if the sites are still online.
I use the fetch API for querying the sites.
This works fine, but I have found an issue with one bookmark:
When fetching "https://victoryroadvgc.com", Chrome automatically also requests JS & CSS resources from HTTP Link response headers with rel=preload params; like this (wrapped for readability):
link: </min/d77e9.css>; rel=preload; as=style,
</wp-includes/js/jquery/jquery.js>; rel=preload; as=script,
</min/0d640.js>; rel=preload; as=script,
</min/02cea.js>; rel=preload; as=script,
</wp-content/plugins/litespeed-cache/js/webfontloader.min.js>; rel=preload; as=script
…which definitely is unwanted behaviour.
If I fetch that URL from the Chrome console, it does not request the additional resources.
The code I use to check if a site is available looks like this:
const request = await fetch(bookmark.url);
return (request.status !== 404);
Things I have tried to prevent this, but didn't work:
Setting the "no-cors" mode for the request
Setting the "Content-Type" header to "text/plain"
Using XHMLHttpRequest instead of the fetch API
Why is the extension behaving like this and can I prevent this somehow?

Origin header is "null" in XHR requests in iFrame

We have micro-service that allows CORS using the Access-Control-Allow-Origin. It works fine. However we have a complicated setup:
subdomain-A.welt.de has an iFrame that points to subdomain-B.welt.de. subdomain-B.welt.de calls the micro-service (somewhere else) via XHR and requires CORS.
Within that iFrame, and only there, subdomain-B.welt.de sends null as Origin-header for every XHR-request.
I am not absolutely certain on what's the cause of this and in my research I stumbled upon document.domain, but as I am uncertain I don't know if that is something to consider (or the right way to fix whatever is happening here).

Externally load Json with jquery.getJSON

I don't know if this is a duplicate post or not, sorry if it is. I'm using jquery.getJSON to load a json on my server which works just fine. Although, if I try and load a json file on a different server it doesn't work. I know I don't have any code here (because there's not much point) but I just want to know if I'm using it wrong or if it isn't supposed to load external files. I'm using the iOS Safari browser if that effects anything.
EDIT: I've looked at the console (idk what the error thing really means, it's just red with an x by the url it's trying to get the json from) and it looks like it's not actually receiving the data. Plus, do remember I'm on iOS, not desktop so I couldn't look at the console in the "Develop tab :P
EDIT 2: Great! I think I got it working! http://skitty.xyz/getJSON/
You're most likely encountering a path issue; the purpose of $.getJSON is to acquire data via http GET request so yes, it is intended to work remotely. To diagnose your issue, make certain you can access the json file in your browser first: http://domain.com/my_data.json. If that works, use that as the URL you pass into $.getJSON:
$.getJSON( 'http://domain.com/my_data.json', function(data) {
// do something with your data
});
http://api.jquery.com/jquery.getjson/
jquery.getJSON uses ajax which is all about external resources. Here's a couple things to check for if it's not working on an external resource:
1: Is the path you specified correct? The usage is jquery.getJSON(path, callback). The path should be something you can just drop in your browser and see. If an incorrect path is your problem, you'll see a 404 in the console.
2: Is the resource http and your site https? Non-secure resources on secure pages will get blocked by browser security features. You'd see a error to this effect in the console.
3: Is CORS (Cross-origin resource sharing) enabled for your site on the external resource? Servers will sometimes use a whitelist of IPs and domains to determine what origins are allowed to make requests of it. You'd also see an error to this effect in the console.
There probably some other things to look for but this is where I'd start.
Also, by all means, use the debugging features of Safari to LQQK at the actual HTTP data-streams that are passing back-and-forth in response to what you're doing. (You might need to click on a preference to see the "Develop" menu, which will take you to "Show Web Inspector" and its Network tab.)
This approach will instantly answer many questions that a JavaScript-centered approach will not so-readily tell you. (And of course, you can look at the JavaScript console too ... and at the same time.) "The actual data streams, please." Safari will tell you "exactly what bytes" your app actually sent to the server, and "exactly what bytes" the server sent in return. "Priceless!™"
Are you saying you are using jquery ajax request to load some json data from a server?
check the "not working server" has the same end point as your server.
Check if the url you want to get data from is correct.
check if console logged any errors.
Also quote from http://api.jquery.com/jquery.getjson/
"Additional Notes:
Due to browser security restrictions, most "Ajax" requests are subject to the same origin policy; the request can not successfully retrieve data from a different domain, subdomain, port, or protocol.
Script and JSONP requests are not subject to the same origin policy restrictions."

Categories