Jekyll - Setting Cache Headers and gzip - jekyll

Just getting going with Jekyll - running it on Debian, base install, base config.yml.
I am serving some static resources from a url ( and folder named the same )
/assets
How would I go about setting some cache headers on stuff in there ?
Done much searching and reading the docs and not much finding. Config setting ??
Hope I can be pointed in the right direction.
Cheers!
Rob

Headers, gzipping, and such would be handled by your web server, and the exact configuration mechanism and details will differ from server to server.

One great alternative is the s3_website script (https://github.com/laurilehmijoki/s3_website). It syncs your static files with S3 from AWS and can set headers and also gzip selected files. It works really nice and does all with one command.

Related

How to serve static files of a service using path-based routing?

I've been searching for quite a while on many forums, how to serve static files referenced by HTML pages like href="/", when the frontend service isn't located at the root / of my host, using Nginx Ingress.
This question has been asked many times here, but briefly: I have a example.com/ host, and I need to expose a frontend service in a path like example.com/front1. This simply cannot work. The index.html returns perfectly, but then a href="/styles.css" hits the gateway asking for example.com/styles.css instead of example.com/front1/styles.css. And nginx just returns a 404.
The only "clean" solution I've found is to manage one subdomain for each frontend service, so it would request something like front1.example.com/styles.css. I'm afraid it might not be a great solution.
Some people do hacks like using sub filters annotations to replace href="/ strings with href="/front1/ for each file returned by that ingress and stuff like that, but this also falls short with dynamically javascript-generated pages and so on. And of course I can throw all my stuff in a S3 server, but think about it: If I have a cluster of many microfrontends and other third-party self-hosted frontend services (like signoz, which I have no control on the source code), it would be amazing if I could reference every service by its path like example.com/service-name/ and not worry about anything else.
I've been thinking of a possible solution in a lost comment of using nginx.ingress.kubernetes.io/server-snippet to inject some njs logic to replace the base URL by the Referer header (http://example.com/front1) whenever it references a known service, but I have no idea of how to use njs, if it is even possible, let alone if it is a good solution.
Anyway, my question is, has anyone solved that problem and could point me in the right direction? It is for a friend

urls to html files generated by applications in openshift environment

My (java) application (in openshift environment) generates/updates a few html files for each user (based on changes of user data) on daily basis. Since these are application-generated files, they are stored in a directory under ~/jbosseap/ (e.g. ~/jbosseap/htmls/xxxxxx.html). what should be the urls to these html files, by which they can be accessed on internet?
Just an update on how have I solved the problem I presented above. First of all, it is good to rephrase the issue for clarity:
My objective: I have an application which creates/updates a set of html pages regularly. These pages are stored (by the application) in a directory on the file system. For the purpose of this writing, let's say the fullpath to the directory is "/opt/mydata/*".
Users of the app need to access these html pages from internet. Therefore, urls to these pages need to be provided: e.g., http://mycompany.com/static/sample.html for /opt/mydata/sample.html.
My environment: my app is a J2EE application, developed with Springframework 3.1, running in Openshift's jbosseap environment
My solution: add the following line to the (servlet's) context configuration:
<mvc:resources mapping="/static/**" location="file:/opt/mydata/"/>
The trick, I think, is "file:" in the clause to allow inclusion of resources
on a file system external to the application.
It has worked for me. Hope it helps anyone who have wondered too.
Credit Thanks to Eugen Paraschiv, whose post led me to the answer.

Forcing Grails to not cache the "cache manifest" file?

I am building a Grails app that will utilize HTML5's Offline Mode. In that article, the author talks about the requirement for your web server to not cache something called the "Cache Manifest" file:
So here’s one thing you should absolutely do: reconfigure your web server so that your cache manifest file is not cacheable by HTTP semantics.
So I need to figure out how to tell Grails (2.4.x) not to allow clients to cache a particular file. I found this answer but am not confident it is the generally-accepted "Grails way" of doing this.
So I ask:
Is that answer the generally-accepted way of prohibiting a file from being cached in Grails? If not, then what is?; and
If it is, then what is CacheFilters, where do I define it, and are there any docs on its all, before, after, afterView, etc. methods?
You cannot easily control the headers in a web-app file as far as I know.
A quick workaround for now could be to map /cache.manifest to a controller action in the urlmappings and simply set the header manually.
In the action you can do something like this after setting the appropiate headers:
response.outputStream.write(grailsApplication.applicationContext.getResource("/cache.manifest").getFile().bytes)
Coded freehand, but you get the general idea.

How do I specify a wildcard in the HTML5 cache manifest to load all images in a directory?

I have a lot of images in a folder that are used in the application. When using the cache manifest it would be easier maintenance wise if I could specify a wild card to load all the images or files in a certain directory to be cached.
E.g.
CACHE MANIFEST
# 2011-11-3-v0.1.8
#--------------------------------
# Pages
#--------------------------------
../index.html
../edit.html
#--------------------------------
# JavaScript
#--------------------------------
../js/jquery.js
../js/main.js
#--------------------------------
# Images
#--------------------------------
../img/*.png
Can this be done? Have tried it in a few browsers with ../img/* as well but it doesn't seem to work.
It would be easier, but how's it going to work? The manifest file is something which is parsed and acted upon in the browser, which has no special knowledge of files on your server other than what you've told it. If the browser sees this:
../img/*.png
What is the first image the browser should request from the server? Let's start with these:
../img/1.png
../img/2.png
../img/3.png
../img/4.png
...
../img/2147483647.png
That's all the images that might exist with a numeric name, stopping semi-arbitrarily at 231-1. How many of those 2 billion files exist in your img directory? Do you really want a browser making all those requests only to get 2 billion 404s? For completeness the browser would probably also want to request all the zero-filled equivalents:
../img/01.png
../img/02.png
../img/03.png
../img/04.png
...
../img/001.png
../img/002.png
../img/003.png
../img/004.png
...
../img/0001.png
../img/0002.png
../img/0003.png
../img/0004.png
...
Now the browser's made more than 4 billion HTTP requests for files which mostly aren't there, and it's not yet even got on to letters or punctuation in constructing the possible filenames which might exist on the server. This is not a feasible way for the manifest file to work. The server is where the files in the img directory are known, so it's on the server that the list of files has to be constructed.
I don't think it works that way. You'll have to specify all of the images one by one, or have a simple PHP script to loop through the directory and output the file (with the correct text/cache-manifest header of course).
It would be a big security issue if browsers could request folder listings - that's why Tomcat turns that capability off by default now.
But, the browser could locate all matches to the wildcards referenced by the pages it caches. This approach would still be problematic (like, what about images not initially used but set dynamically by JavaScript, etc., and it would require that all cached items not only be downloaded but parsed as well).
If you are trying automate this process, instead of manually doing it. Use a script, or as I do I use manifestR. It will output your manifest/appcache file and all you have to do is copy and paste. I've used it successfully and usually only have to make a few changes.
Also, I recommend using the network header with the wild card:
NETWORK:
*
This allows all assets from other linked domains via JSON, for instance, to download into the cache. I believe that this is the only header where you can specify a wildcard. Like the others have said here, it's for security reasons.
The cache manifest is now deprecated and you should use HTML headers to control caching.
For example:
<meta http-equiv="Cache-control" content="public">
Public - may be cached in public shared caches.
Private - may only be cached in private cache.
No-Cache - may not be cached.
No-Store - may be cached but not archived.

Restlet - serving up static content

Using Restlet I needed to serve some simple static content in the same context as my web service. I've configured the component with a Directory, but in testing, I've found it will only serve 'index.html', everything else results in a 404.
router.attach("/", new Directory(context, new Reference(baseRef, "./content"));
So... http://service and http://service/index.html both work,
but http://service/other.html gives me a 404
Can anyone shed some light on this? I want any file within the ./content directory to be available.
PS: I eventually plan to use a reverse proxy and serve all static content off another web server, but for now I need this to work as is.
Well, I figured out the issue. Actually Restlet appears to route requests based on prefix, but does not handle longest matching prefix correctly, it also seems to ignore file extensions.
So for example, if I had a resource attached to "/other"... and a directory on "/". And I request /other.html, what actually happens is I get the "/other" resource. (The extension is ignored?), and not the static file from the directory as I would expect.
If aynone knows why this is, or how to change it, I'd love to know. It's not a big deal, just for testing. I think we'll be putting apache or nginx in front of this in production anyway.
Routers in Restlet by default use the "Template.MODE_STARTS_WITH" matching mode. You could always set the Router default by doing router.setMatchingMode(Template.MODE_EQUALS). This will turn on strict matching by default for attach. You can choose to override individual routes with setMatchingMode.
Good documentation on Restlet Routing