Can you not load webcomponents from other domains?
I'm getting a cors error in firefox/linux.
I added this to nginx but still can't load it:
add_header Access-Control-Allow-Origin *;
<html lang="en">
<head>
<meta charset="utf-8" />
<script type="module" src="//briskreader.com/components/feed-list.js"></script>
</head>
<body>
<feed-list topic="bitcoin"></feed-list>
</body>
</html>
Here's the error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://briskreader.com/components/feed-list.js. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Loading module from “http://briskreader.com/components/feed-list.js” was blocked because of a disallowed MIME type (“text/html”).
test.html
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://briskreader.com/components/feed-list.js. (Reason: CORS request did not succeed).
Heres the header from briskreader.com:
$ curl -I 'https://briskreader.com/components/feed-list.js'
HTTP/2 200
server: nginx/1.18.0 (Ubuntu)
date: Sun, 21 Nov 2021 06:30:51 GMT
content-type: application/javascript
content-length: 2187
expires: Sun, 21 Nov 2021 06:30:50 GMT
cache-control: no-cache
cache-control: no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0
access-control-allow-origin: *
accept-ranges: bytes
Web components has nothing to do with CORS. The attribute type="module" on <script> tag causes the CORS request. Unlike classic scripts, module scripts require the use of the CORS protocol for cross-origin fetching.
Next this line add_header Access-Control-Allow-Origin *; is useless on origin domain. You must set Access-Control-Allow-Origin header on briskreader.com domain. If you do not control briskreader.com, then consider using classical script. You can still use Web components with classical script.
Related
I get the following header on CURL request.
Am I correct to assume that because the last-modified is that back in the past - the request is not cached in the browser?
➜ curl -I https://dommain.com/assets/sounds/intro.mp3
HTTP/2 200
date: Sat, 12 Nov 2022 23:39:39 GMT
content-type: audio/mpeg
content-length: 33976
last-modified: Tue, 01 Jan 1980 00:00:01 GMT
etag: "12cea601-84b8"
cache-control: no-cache
accept-ranges: bytes
strict-transport-security: max-age=15724800; includeSubDomains
No. You might be thinking of the Expires header. In the absence of Cache-Control an Expires header with a date in the past would mean that the cached response couldn't be used without revalidation.
In this case, the cache policy is set by the Cache-Control: no-cache header. That means that the browser can store the response, but can't serve it without confirming that it's up to date by making a conditional request.
Since the response has an ETag header, that will be used to determine if the cached response is still valid or not. In the absence of ETag, Last-Modified would be used for that purpose.
In sum, what you have here is a perfectly standard approach to caching, especially for large files. The response can be stored indefinitely, but can only be served from the cache after the origin server has confirmed that the stored response is still valid.
I have single page application that is frequently updated and I need a way to prevent browsers to cache my web app.
I have added
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="0">
to my headers. I also use file versioning and update my file names according to the newest version.
But to my observations, google chrome always caches my application.
What may be the root cause here?
On a different platform, I have read that using no-cache , no-store and must-revalidate may cause conflicts and the browser may choose to use whichever it want, I have yet to find further proof of that statement. AFAIK the browser should use the most restrictive statement.
Here are my response headers:
Accept-Ranges: bytes
Cache-Control: max-age=31536000
Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate, max-age=0
Connection: keep-alive
Content-Length: 312
Content-Type: application/json
Date: Mon, 11 Oct 2021 22:01:42 GMT
ETag: "61643c76-138"
Last-Modified: Monday, 11-Oct-2021 22:01:42 GMT
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
I have a web application running on centos ec2 instance behind Nginx reverse proxy with SSL certification (Let's Encrypt).
I have a javascript file located at the URL for example https://example.com/static/src/js/allEnd.js
I used CloudFront to delivered the static file with the origin server as the HTTP ec2 instance (not using the s3 bucket.)
My origin server is mapped with the domain name https://example.com I have the following configuration I have made so far:
1. www.example.com is redirected to example.com in Nginx
2. The CloudFront URL is an alias with my custom domain ie cdn.example.com
3. SSL for example.com is done on Nginx whereas SSL for cdn,example.com is done on AWS.
What I have understood so far is the first time the CloudFront will serve the static content by getting the file from my ec2 server and then the next time it will serve from CloudFront but every time the CloudFront redirect to the origin server to get the static file which CloudFront is not serving in my case.
Here is the header for both the origin server and CloudFront server.
1. Origin server (https://example.com)
get https://example.com/static/src/js/allEnd.js
HTTP/2 200
server: nginx/1.12.2
date: Sun, 12 May 2019 12:27:50 GMT
content-type: application/javascript
content-length: 168435
etag: "wzsdm-1557567525-168435-283837276"
cache-control: max-age=604800, public
expires: Sun, 19 May 2019 12:27:50 GMT
strict-transport-security: max-age=15768000; includeSubdomains; preload
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
strict-transport-security: max-age=15768000
2. CloudFront with origin as https://example.com (https://cdn.example.com)
get https://cdn.example.com/static/src/js/allEnd.js
HTTP/2 301
content-type: text/html
content-length: 185
location: https://example.com/static/src/js/allEnd.js
server: nginx/1.12.2
date: Sun, 12 May 2019 09:17:40 GMT
strict-transport-security: max-age=15768000; includeSubdomains; preload
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
strict-transport-security: max-age=15768000
age: 17
x-cache: Hit from cloudfront
via: 1.1 76d9b50884e58e2463b175e34e790838.cloudfront.net (CloudFront)
x-amz-cf-id: HBbfJXbFgKQz4eYlQSpLPQAk8pxZRKuGsb6YjFu8-AJL0JwPfs8FZw==
As you can see the response header that the cdn.example.com (CloudFront) redirect to the origin (example.com).
Also, I am confused with the content-type:text/html which should be content-type: application/javascript
What are the possibilities that I may have misconfigured?
If anything more you want to know, Please feel free to ask. Thanks.
P.S: I am new to the Nginx and AWS configuration and most importantly cache control.
You will need to examine the origin server configuration and log files to understand why this happened.
Check the origin server logs and you will find that the origin server originally generated that 301 redirect response -- not CloudFront.
Notice that the response headers from CloudFront include server: nginx/1.12.2. CloudFront did not add this.
The Content-Type is set as it is, because your origin server also returned HTML saying something like "object has moved" or "you are being redirected." Modern browsers typically don't display that message, they just follow the redirect.
In any event, if the origin server returns a redirect, CloudFront does not follow the redirect returned by the origin server -- it simply returns the redirect to the browser.
One possible explanation for the behavior you see is that you set the Origin Protocol Policy in CloudFront to "HTTP Only" instead of "HTTPS Only" or "Match Viewer," so the origin is trying to redirect the connection to use HTTPS since it sees the incoming connection (from CloudFront) as HTTP instead of HTTPS.
Another possibility is that you configured CloudFront's Cache Behavior settings to whitelist the Host header for forwarding to the origin.
I use Nginx to do reverse proxy for image server. (I am Nginx newbie).
To get the image from the original server we need to pass a token so the orignal url looks like this
http://www.myphoto.com/htm/GetDocumentAPI.aspx?F=TRX&DocID=15-551703&token=726gxJexU69LsQplDw#a.gIyDnVTtd0#LbcGe47Ku4*
and the response headers
Cache-Control →private
Content-Length →2653278
Content-Type →image/jpeg; charset=utf-8
Date →Wed, 10 May 2017 16:20:29 GMT
Server →Microsoft-IIS/8.0
X-AspNet-Version →4.0.30319
X-Powered-By →ASP.NET
content-disposition →inline;filename="15-551703.jpg"
My Nginx server:
location ~ ^/big/(.+) {
proxy_pass http://www.myphoto.com/$1;
}
When I try to get image from my server
http://localhost/big/htm/GetDocumentAPI.aspx?F=TRX&DocID=15-551703&token=726gxJexU69LsQplDw#a.gIyDnVTtd0#LbcGe47Ku4*
Instead of the image I get:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
and the response:
Cache-Control →private
Connection →keep-alive
Content-Encoding →gzip
Content-Type →text/html; charset=utf-8
Date →Wed, 10 May 2017 16:07:08 GMT
Server →nginx/1.4.6 (Ubuntu)
Transfer-Encoding →chunked
X-AspNet-Version →4.0.30319
X-Powered-By →ASP.NET
Changing the content type didn't work too
We seems to be having an issue with a css file caching on the client. I generally stop this from causing issue by adding a version number to the file, i.e.
<link href="Default.css?4.31.0.17051" rel="stylesheet" type="text/css">
But in this circumstance this isn't working and I don't understand why.
The version number was incremented last night from 4.30.0.xxxxx to 4.31.0.17051
Some users, and I've seen it myself, are getting a HTTP 304 response. What's strange is if I inspect it using the IE dev tools it shows a HTTP 304, if I fire up fiddler it doesn't show any request at all.
Content caching is not enabled on the server.
Here's the HTTP header if I do a ctrl-f5:
HTTP/1.1 200 OK
Content-Length: 45861
Content-Type: text/css
Last-Modified: Tue, 23 Jul 2013 14:19:40 GMT
Accept-Ranges: bytes
ETag: "0a61aabaf87ce1:bdba"
Vary: Accept-Encoding
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Tue, 30 Jul 2013 16:05:54 GMT
So:
why don't I see this in fiddler? is it not sending the request at all as this question suggests (https://stackoverflow.com/a/8958279/542251)
Why isn't this cache control (i.e. adding the ?4.31.0.17051 to the file) working?
EDIT
I've now touched the file, to update the Last-modified date but it's still not requesting it.
So the page is returning a HTTP 200, so this isn't the page caching as suggested below:
Request:
GET http://www.mysite.com/Agent/Hotel HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://www.mysite.com/Agent/Flights
Accept-Language: en-GB
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Accept-Encoding: gzip, deflate
Host: www.mysite.com
Connection: Keep-Alive
Response:
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 53184
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
X-AspNetMvc-Version: 3.0
Date: Wed, 31 Jul 2013 08:33:25 GMT
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<link href="Default.css?4.31.0.17051" rel="stylesheet" type="text/css" />
.........
As noted in my answer that you cited, the F12 Tools can show a HTTP/304 when the response was really served from the cache. If you don't see the request in Fiddler, it wasn't sent over the network.
Are you sure that the page that refers to the CSS file wasn't pulled from the cache? If it were, then you'd still have the old URL reference. (Look carefully at the CSS request's URL in the F12 tools, as the URL will be accurate even if the "304" was not).
Two points:
- What does "Why isn't this cache control working?" mean? Your HTTP-response headers don't include any Cache-Control directives.
- Changing the Last-Modified date on the server obviously isn't something the client will know about unless it actually issues a Conditional GET request to the server.
So I got a solution but not necessarily an answer.
In the end I updated the tag on the site to:
<link href="Default.css?v=4.31.0.17051" rel="stylesheet" type="text/css">
I'm not sure if adding the v= turning it into a valid querystring was the solution or whether it was just the fact that I altered the URL again solved this issue.
I haven't been able to replicate this issue in staging so I don't really know how or why this started happening.