I'm generating dynamic CSS URLs for cache-busting. I.e. they're in the format styles-thisisthecontenthash123.css.
I also want to use HTTP Link headers to load the files slightly faster. I.e. have the header Link: <styles-thisisthecontenthash123.css>; rel=stylesheet
I'm pretty sure it's possible to do this in Fastly using VCL, but I'm not familiar enough with the ecosystem to figure it out. The CSS URL is in index.html, which is cached. I'm thinking I can open index.html and maybe use regex to parse out the CSS URL. How would I do this?
If I'm understanding your question correctly, you want to include a link header for all requests for index.html. You can do that with Fastly, but if the URL for the CSS file is changing you're not going to be able to pull that info out with VCL (you can't inspect the response body).
You could use edge dictionaries and whenever your CSS filename changes, update the reference via the API.
Thing is, if you're going to make an API call whenever the file changes, might as well just keep the filename consistent (styles.css) and whenever you publish a new version send a cache invalidation (purge). Fastly will clear the cache in ~150ms, so you then all you have to do is add the header which is can be done in the Fastly web portal with a condition.
Related
I've been using S3 to host static websites and I've made changes to the HTML & CSS files and have seen those changes reflected in the past. For some reason I go to do the exact same thing I've done before, change the style of one of my sites, and no change would take place. In-fact after deleting all previous files, the old build was still rendering. I had no version control on that particular bucket.
Content-type is set to 'text/css'. My file structure is normal with index.html being in the root. My normal steps of creating or updating new or existing sites has not changed, but S3 has for some reason.
When I click on the index.html file and go to the public url link, it reflects all my changes.
My only fix is to add the full url to the style link.
<link href="https://s3.amazonaws.com/{bucket-name}/css/style.css">
Does anyone know why this is happening or how to fix it other than adding the http link? If not, I hope my solution helps others for this weird S3 issue. Normally you can just upload your files to a bucket, set the policy and finally enable hosting after stating the root html file.
It might be due to your browser caching, where it's loading locally stored assets (CSS stylesheet) from a previous time you've visited the URL rather than fetching the new resources in an attempt to speed up load times. There are settings you can change in your browser to determine how long your browser will hold onto cached resources before fetching new ones.
By setting the stylesheet link directly to the s3 bucket URL, it will cause it to fetch the new stylesheet every time the page is loaded, which leads me to believe that caching is the issue here.
Try clearing your cache and see if it solves the problem.
Here is a deeper explanation of the concept with respect to browsers, and a list of commands to perform a cache refresh depending on what browser/OS you have!
I think it's the CSS folder's doesn't allow you to access the files inside. If you make the folder public, it will work.
Select all your files and folders, go to actions tab and then select make public to allow objects to access one another.
I have a page as part of my IIS 7 (ASP.NET) website which serves images from a database. It uses a querystring to select the image and sets the content type header appropriately (image/jpeg) so that, for example, image.aspx?ID=1234 will be displayed in the browser as a jpeg image.
What I want to do instead is offer a URI formed in a manner such as image/1234.jpg which will produce the same result. In other words, there is no actual file on the server named 1234.jpg, it's just the contents of a database record, but from the browser's perspective, it will appear as if there is such a file.
I'm sure this is possible, but I can't figure out how it's accomplished, or where to look for answers. I'm thinking it may be done with an ISAPI filter, but I haven't found an accessible path into the docs to know if that's even the correct basis for a solution.
Possibly the best option here would be to implement a URL rewrite rule that changes image/1234.jpg to image.aspx?ID=1234
You can find more on URL rewrite for IIS here.
If, for whatever reason, URL rewrite isn't an option to you, then another possible method might be to implement a custom 404 page. When your request to image/1234.jpg doesn't result in a real file, it'll end up there.
You should be able to detect the URI at that point and serve up the image.
In the head section of the sample html file from the html5boilerplate project, I notice this:
<link rel="stylesheet" href="css/style.css?v=2">
Note the v=2 request variables. I also notice that this is never done for javascript files.
What is the actual function of doing this ?
The ?v=2 might be to prevent reading from cache by the browser. It's used when loading dynamic content from a static file, like so:
changingListOfStuff.txt?randomUselessPropertyToTrickBrowser=123456789
This forces the browser to use this exact file, not a cached version of changingListOfStuff.txt previously downloaded and stored by the browser. Caching speeds up loading time, but might provide an older version of the file if it changes rapidly.
Read more about caching here: http://en.wikipedia.org/wiki/Web_cache
this is just telling the version of the url. This is done to make a fresh request to the server.In case of css as we know to achieve performance some headers are modified so that next time css is served by the browser history.But every time a css is modifed specifically in case of version releases. Browser should make new requests that would happen only when the url changes. So v=2 probaly means a new version is in and the url should freshly fetch the content from css.
This is called cache busting...you can read it here too
http://manikandanc.blogspot.com/2005/11/cache-busting-with-javascript.html
this will avoid client to get the version from browser. When you change the javascript or css , the end client who already visited your website may get javascript from his cache.
You can increment the version no whenever you deploy the files to the production , so that it will get the latest file
I do not really understand how Google Code handles file versioning.
I am building a jQuery plugin that anyone can access. Like so:
<script type="text/javascript" src="http://jquery-old-browser-warning.googlecode.com/files/jquery.browser-warning.js"></script>
This script accesses other files on the same project (via ajax).
The problem is, that when I upload a new file, it just seems like there aren't any changed to it. Google recommends that new files should have new names.
But then I would have to change the filenames that the script loads.
But then I would have to change the script file as well, and that would break everybodys implementation (with the script-tag above)
Is there a way to force a file to change when uploading with the same filename?
PS: If I go directly to the project page's file list. Then I do get the file with the updated content. But as I said, not when getting it through ajax.
The cheapest trick in the book to prevent caching is adding some random content to a GET parameter:
www.example.com/resources/resource.js?random=1234567
You can for example use the current timestamp for this.
This, however, causes any and every access to re-fetch the content, and invalidates any client-side caching mechanism as well. I would use this only as a last resort. If Google are that stringent about caching, I'd rather develop a workflow that allows for easy renaming of files.
I don't know your workflow, but maybe you can work with versioned directories?
Like so:
www.example.com/50/resources/resource.js
www.example.com/51/resources/resource.js
that would keep whatever caching the client employs intact, but whenever there's a change from your end, the browser would reload the content.
I think Its just a cache on the browsers, So when you request file from ajax, just add random parameters or version number.
For example, Stackoverflow add version parameter to static contents like
http://sstatic.net/so/all.css?v=6638
Are you talking about uploading files to the "Downloads" area? Those should have distinct filenames, for example they should be versioned. If you're uploading the script code, that should be submitted by the version control system you're using, and should most definitely keep the same name across revisions.
Edit: your code snippet didn't show up on my page, misunderstood what you're trying. Don't imagine Google would be happy with you referencing the SVN repository every time some client page is loaded :)
I'm currently playing around with a build / deployment script for minifying static resources. Following good practice I'd like to set an expire header far into the future for most of my javascript, stylesheet and images.
To my question, when one or more of the static files has changed clients should ask for the newest version of the file. Will adding something like /css/style.css ?1235 after the url be enough to trigger a new request? Or do I have to rename all my static files for each build (something like /css/style _12345.css)?
Update: Just to clarify, the reason that I'm asking is that I've noticed that a lot of other deployment scripts seems to take the "hard" path by renaming each file.
Will adding something like
/css/style.css ?1235 after the url be
enough to trigger a new request?
Yes, of course.
You can do it like this:
style.css?UNIXTIMESTAMP
where UNIXTIMESTAMP is the time when the file was created in unix timestamp format
RFC 2616 3.2 Uniform Resource Identifiers says:
As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location, or any other characteristic--a resource.
So, http://foo/bar is a different resource to http://foo/bar?baz.
Some URIs are treated as equivalent, so http://foo/bar?baz is the same resource as http://foo/bar?BAZ (see 3.2.3 URI Comparison).
HTTP does contain some caching exceptions for handling the query part (see 13.9 Side Effects of GET and HEAD). I understand these to only apply to the exact same query.
if you can use mod_rewrite i add a rule like this:
RewriteRule ^/((.*)_[0-9]+(\.(?:js|css|swf).*))$ /$2$3 [NC,L]
which rewrites any javascript, css or flash file back to the original name so
/css/style_1234.css
gets rewritten back to
/css/style.css