I have an S3 Bucket fronted with a Cloudfront CDN. In that bucket, I have some woff2 fonts that were automatically tagged with the content type octet-stream. When trying to load that font from a CSS file on a live production website, I get the following error:
Access to Font at 'https://cdn.example.com/fonts/my-font.woff2' from origin
'https://www.live-website.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'https://www.live-website.com' is therefore not allowed access.
The thing is that a curl reveals that the Access-Control-Allow-Origin is present:
HTTP/1.1 200 OK
Content-Type: binary/octet-stream
Content-Length: 98488
Connection: keep-alive
Date: Wed, 08 Aug 2018 19:43:01 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Last-Modified: Mon, 14 Aug 2017 14:57:06 GMT
ETag: "<redacted>"
Accept-Ranges: bytes
Server: AmazonS3
Age: 84847
X-Cache: Hit from cloudfront
Via: 1.1 <redacted>
X-Amz-Cf-Id: <redacted>
Everything is working fine in Firefox, so I guess that Chrome is doing an extra validation that blocks my font.
Turns out that the problem was actually with the Content-Type. As soon as I changed the content type to application/font-woff2 and invalidated the cache of these woff2 files, everything went through smoothly.
My problem with CORS and multi domain was that Cloudfront was taking in cache the first request so I had to select in Whitelist Headers the Origin option. And it works.
enter image description here
Related
I recently set up a content delivery network for mp3 files (spoken word podcast stuff) with Microsoft Azure. At first everything worked fine, but recently the files started "skipping", i.e. resetting themselves. For example when the player reached the 3:30 mark of the file it would go back to the 0:15 mark of the file. For some reason this is only happening when serving the files under https, not under http
Specifics:
It is only happening on Chrome - I've tested under Edge and Firefox too - they work perfectly
It happens across multiple computers
Only the https version of the file has the problem, the http version is fine
It works using the plain vanilla audio tag - no fancy player involved
When this happens there is no entry in the console in the dev tools, nor a new download in the media window
I uploaded the same file to Amazon S3 - put it in the same plain vanilla player and it plays just fine under https.
How can this be happening?
Headers from the NOT working request from Azure
Request Method: GET
Status Code: 206 Partial Content (from disk cache)
Referrer Policy: no-referrer-when-downgrade
Accept-Ranges: bytes
Access-Control-Allow-Origin: *;
Access-Control-Expose-Headers: x-ms-request-id;
Content-Disposition: attachment; filename=XXXXXXXXXXX.mp3;
Content-Length: 76434500;
Content-Range: bytes 0-76434499/76434500;
Content-Type: audio/mpeg;audio/mpeg3;;
Date: Mon;
ETag: "0x8D5EC5B899726B0";
Last-Modified: Wed;
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0;
status: 206;
x-ms-blob-type: BlockBlob;
x-ms-lease-state: available;
x-ms-lease-status: unlocked;
X-MS-Ref: 0DGxVWwAAAAA2BOMWL9GzRqSzc9yi5SF4QkwyRURHRTA1MTIAMzc1ZmRlZDMtMjA3My00Y2YxLTljZGMtNzc4NGMxYmI3ZmZi;
x-ms-request-id: 998f9297-301e-00bc-2945-22fa9f000000;
x-ms-version: 2014-02-14;
Headers from the working request from Azure
Request Method: GET;
Status Code: 206 Partial Content (from disk cache);
Remote Address: 52.239.152.234:80;
Referrer Policy: no-referrer-when-downgrade;
Accept-Ranges: bytes;
Access-Control-Allow-Origin: *;
Access-Control-Expose-Headers: x-ms-request-id;
Content-Disposition: attachment; filename=XXXXXXXXXXX.mp3;
Content-Length: 76434500;
Content-Range: bytes 0-76434499/76434500;
Content-Type: audio/mpeg;audio/mpeg3;;
Date: Mon;
ETag: "0x8D5EC5B899726B0";
Last-Modified: Wed;
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0;
x-ms-blob-type: BlockBlob;
x-ms-lease-state: available;
x-ms-lease-status: unlocked;
x-ms-request-id: 6246c264-401e-017b-1b47-22c00b000000;
x-ms-version: 2014-02-14;
Headers from the working request from S3
Accept-Ranges: bytes;
Content-Length: 76303428;
Content-Range: bytes 131072-76434499/76434500;
Content-Type: audio/mp3;
Date: Mon;
ETag: "09fac410597469e6db237376a0e2505d-5";
Last-Modified: Sun;
Server: AmazonS3;
x-amz-id-2: ictUYlZjFNJwa2g8q09TowZuc3quHiHmZsYmq7b/hjIgEsoIKpZIYrlqBCea1NYScr9QukHPqZY=;
x-amz-request-id: 6FE8390CF92213AF;
I am trying to inspect an HTTP request made in my browser with the chrome dev tools. I want to see the response but it seems to be empty (failed to load data), whereas the Content-Type is set to 4464326.
Below the HTTP response headers :
HTTP/1.1 200 OK
Last-Modified: Tue, 21 Jan 2014 12:08:30 GMT
ETag: "3ba731138c01f1ad6536bc1d4030cfdd"
Content-Type: audio/mpeg
Server: AmazonS3
Content-Length: 4464326
Accept-Ranges: bytes
Date: Wed, 04 May 2016 13:02:20 GMT
Via: 1.1 varnish
Age: 153069
Connection: keep-alive
Cache-Control: no-cache, no-store, private
X-Served-By: cache-fra1226-FRA
X-Cache: HIT
X-Cache-Hits: 2
X-Timer: S1462366940.863431,VS0,VE0
Plus, in the timeline, I see a download time of 4.61s so I guess to response was not actually empty.
I also tried with Fiddler but responser is still unavailable. Does someone has an explanation, or even better, knows how I can try to read the response ?
As you can see,
Content-Type: audio/mpeg
Can the chrome dev tools read this type of content?
When you are streaming a video, the Response panel shows as empty because the request hasn't completed yet. Once completed, it displays "Failed to load response data", since the data is likely to be too large to display as text in the panel.
You could try Wireshark to capture the HTTP response data.
I'm experiencing an issue with Chrome that I can't seem to fully understand, I'm curious if folks here have dealt with it before. This doesn't reproduce in Firefox. The steps are as follows:
Start incognito Chrome, navigate to https://foo.mysite.com and have the JS on the page make a GET ajax request to S3 for https://s3.amazonaws.com/mystuff/file.json . You get back a 200 response with:
HTTP/1.1 200 OK
x-amz-id-2: somestuffhere
x-amz-request-id: somestuffhere
Date: Tue, 14 Oct 2014 03:06:41 GMT
Access-Control-Allow-Origin: https://foo.mysite.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
Cache-Control: max-age=86400
Content-Encoding: gzip
Last-Modified: Sun, 05 Oct 2014 00:29:53 GMT
ETag: "fe76607baa40a793eb3b3cbd373a3fb8"
Accept-Ranges: bytes
Content-Type: application/json
Content-Length: 5609
Server: AmazonS3
Open a second tab, navigate to https://bar.mysite.com and have its JS make a GET ajax request to S3 for the same file https://s3.amazonaws.com/mystuff/file.json . Get back the following 304 response:
HTTP/1.1 304 Not Modified
x-amz-id-2: somestuffhere
x-amz-request-id: somestuffhere
Date: Tue, 14 Oct 2014 03:06:58 GMT
Access-Control-Allow-Origin: https://bar.mysite.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
Cache-Control: max-age=86400
Last-Modified: Sun, 05 Oct 2014 00:29:53 GMT
ETag: "fe76607baa40a793eb3b3cbd373a3fb8"
Server: AmazonS3
Open a third tab, navigate to https://foo.mysite.com (the first site) and repeat the same steps as in 1. Chrome kills the response for CORS reasons and reports the following:
XMLHttpRequest cannot load https://s3.amazonaws.com/mystuff/file.json. The 'Access-Control-Allow-Origin' header has a value 'https://bar.mysite.com' that is not equal to the supplied origin. Origin 'https://foo.mysite.com' is therefore not allowed access.
What's the story here? This doesn't reproduce in Firefox. In Firefox I'm happily getting a 304 in both steps 2 and 3, which I would expect to see in Chrome as well.
A temporary workaround for this issue in Chrome is to set Cache-Control: no-cache on the file in S3, but then I'm forcing our clients to be re-downloading that file for no good reason, so it's not a real solution.
Is this intended and documented behavior? Is this a bug with Chrome? Any other thoughts?
Looks like this is caused by Chromium issue 260239
I found this blog that help: Add Vary headers to S3
It helped by adding Vary headers to all XHR request.
I did run into a problem with html request (i.e. ) but I was able to overcome that by using hackround#2 described here:https://serverfault.com/a/856948
TL;DR of hack#2 is to use a "dummy" query string parameter that differs for HTML and XHR or is absent from one or the other. Example:
<img src="https://s3.png?x-request=html">
I just add a timestamp in request URL to force load the asset from S3 again, not from cache, such as xxxx?timestamp=yyyy
I am making the manifest file work for my web page but it is not working when turn of internate and open web page on ipad it says connect to internet.how to solve this issue i have given all the resources used in web page in the manifest file but still it is not working
Below is My Manifest File
CACHE MANIFEST
CACHE:
index.html
brd_icon.png
newstyle_tester.css
draxxin.pdf
exede.pdf
js/jquery-1.7.2.min.js
js/script.js
js/jquery.queryloader2.js
image/startbutton.png
image/mockup_splash_1.png
image/testing_file_3.png
image/overview.gif
image/strategy.gif
image/draxxin.gif
image/excede.gif
image/reference.gif
image/results.gif
image/seperator.png
image/overview_active.png
image/strategy_active.png
image/draxxin_active.png
image/excede_active.png
image/result_active.png
image/references_active.png
image/pageone_image.png
image/whiteslide.png
image/option.png
image/option_1.png
image/pagetwo_graph_one.png
image/pagetwo_graph_two_4.png
image/optiononeone.png
image/optiononetwo.png
image/optiontwofirst.png
image/optiontwosecond.png
image/backward.png
image/forward.png
image/button_7days.png
image/button_14days.png
image/close.png
image/popup_page_1.png
image/popup_1_page_2.png
image/popup_2_page_2.png
image/popup_page_3.png
image/popup_page_4.png
image/popup_1_page_5.png
image/popup_2_page_5.png
image/popup_3_page_5.png
image/popup_4_page_5.png
image/smallicon_1.png
image/smallicon_2.png
image/bg_img_lightbox.png
image/tag.png
image/result_graphic_1.png
image/result_graphic_2.png
image/result_graphic_3.png
image/graph1.png
image/graph2.png
image/graph3a.png
image/graph4.png
image/graph5.png
image/graph_one.png
image/graph_three.png
image/bottle_1.png
image/bottle_2.png
image/arrow_1.png
Your problem is that you've not configured the content type header correctly on your server. Here's the response to the HTTP request for cache.manifest:
HTTP/1.1 200 OK
Date: Tue, 08 May 2012 09:33:41 GMT
Server: Apache
Last-Modified: Tue, 08 May 2012 05:07:32 GMT
Etag: "733106-652-4bf7f5d3692a8"
Accept-Ranges: bytes
Content-Length: 1618
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/plain
See that last line? It should be text/cache-manifest. Change the content type in your server configuration. For Apache you can add this line to the server config or in an .htaccess file:
AddType text/cache-manifest appcache manifest
I am playing around with HTML 5 cache manifests, and I am seeing a very strange issue in Chrome. Here's the page's header:
<html id="html" xmlns="http://www.w3.org/1999/xhtml" manifest="Portal/CacheManifestHandler.ashx">
Here are the manifest contents captured from fiddler:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/cache-manifest; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 20 Apr 2012 15:56:20 GMT
Content-Length: 56
CACHE MANIFEST
NETWORK:
*
#Timestamp: 634705337615835020
I have one particular script on the page's header inside tag that is generated dynamically on server. Here are the contents returned for that script tag the first time user accesses the page:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/javascript; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 20 Apr 2012 15:36:33 GMT
Content-Length: 74
document.location='/Portal/Login.aspx?ReturnUrl=%2fPortal%2fDefault.aspx';
You can see neither the script is in Cache-manifest, nor its headers allow browser (Chrome) to cache it.
Still when I subsequently open the same page in browser, Chrome loads the page from cache-manifest, which is okay.
However surprisingly it loads the <script> also from cache. I can verify it as my server breakpoints are not hit, nor does Fiddler show a request for this <script>. The network is not down and the server is accessible (this should not have made a difference because Chrome was asked to not cache this <script> anyways).
Is this the expected behavior? Shouldn't Chrome have requested the <script> again from server even when its containing page was loaded from manifest cache.
Chrome's chrome://appcache-internals also shows only 2 urls in the cache which again is fine, why then it loads the <script> from cache and not the server
We had the same issue, our resolution was to stick a * in the network section of our app.manifest so our Network section looked like
NETWORK:
*
I'm now digging to see if that's really "by design" for Google or just plain wrong.