I have a newsstand application that uses a bar to show download progress. It works by getting the content-length from the file download. This used to work on our development server, however we use an nginx server for production and it doesn't seem to be returning a content-length header.
Does anyone know why this would be or a better solution?
Thanks
The lack of a Content-Length header is likely caused by you having compression enabled on your live server but not on your dev server. Because Nginx compresses data as it's sent, it's not possible to send a Content-Length header at the start of the response, as the server can't know what size the data will be after it's compressed.
If you require a Content-Length header for a download progress then the best option is to compress the content yourself, set the Content-Length header to the size of the compressed data, and then serve the compressed data.
Although this will be slightly slower for the first user to download that piece of content, you can use it as an effective caching mechanism if you use unique filenames for the compressed files, with the filename generated from the parameters in the users request. You can also then use Nginx's x-sendfile ability to reduce the load on your server.
btw if you're using Amazon CloudFront CDN (and probably others) you really ought to be setting the Content-Length header as they can serve partial (aka corrupt) files, if there is no Content-Length header and the download from your server to CloudFront is interrupted during transfer.
Related
I've configured CloudFront in front of my Elastic Beanstalk/load-balanced web application and the static content rule (Png images etc) are being caching and served GZIPPED.
However my JSP pages aren't being Gzipped.
Please note that I have explicitly set my default rule to not cache by setting the min TTL to 0, but it's probably un-necessary because my origin server isn't returning a Content-Length header for JSP pages, so it will never be cached anyway.
CloudFront will only cache if...
Filetype is supported (text/html is)
Response is 1,000 -> 10,000,000 bytes (it is)
Content-Length header must be provided (it is NOT)
Content-Encoding must not be set (it is not)
So that explains why it's not being cached, fair enough.
But why don't my HTML pages get GZIPPED? FYI my HTML and JSP file extensions are all processed through the JSP processor.
Looks like I was right, until my page was modified to return the Content-Length response header, CloudFront did not cache nor GZIP the content.
We have files that are over 1mb and excluded from the automatic compression through Azure Verizon CDN.
To accommodate we manually compress the files before uploading to the Azure Blob backbone. We upload both an compressed and uncompressed version of the file.
We have also configured Azure CDN to handle json file :
Now if i curl the blob or cdn with the appropriate headers, I do not get compressed content.
So what is the standard approach to doing this with Azure? Am I missing a setting or header?
Is content swapping not doable based on the Accept-Encoding header?
Do I need to drop the .gz extension and always serve the json zipped?
Any insights would be appreciated.
Edit for clarity:
The recommended solution here is to gzip and upload your asset to blog storage without the .gz extension and make sure it returns the "Content-Encoding:gzip" header.
After that, just request that asset through the CDN endpoint. If your request contains an Accept-Encoding:gzip header, the CDN will return the compressed asset. If your request does not contain the Accept-Encoding header, the CDN will uncompress the file on the fly and serve the client the uncompressed version of the asset.
Original Answer:
Hey, I'm from the Azure CDN team.
First, are you using a Verizon or Akamai profile?
Verizon has a limit of 1MB for edge compression while Akamai does not. Also, this limit is just for CDN edge compression, so if your origin responds with the correct compressed file, the CDN should still serve it to the client.
Blob storage doesn't automatically do content swapping as far as I'm aware.
Note that if an uncompressed version of the file was already cached on the CDN edge, it will continue to serve that file until it expires. You can reset this by using the 'purge' function.
We also have a troubleshooting document here: https://learn.microsoft.com/en-us/azure/cdn/cdn-troubleshoot-compression
I'd be happy to help you troubleshoot further, if the above doesn't help.
Just send me your origin and cdn endpoint URLs privately at rli#microsoft.com.
When a page is requested there would be parameters as below:
Pragma
Cache-Control
Content-Type
Date
Content-length
Is there a way to remove Date for example? Or remove most of them (except Pargam and some caching mechanisms) for image files? Could we get performance gain here? Should we do it on web server layer?
The Date header is required by HTTP/1.1. Content-Type and Content-length are also valuable and small to have, and you already mentioned that cache headers were important to you. So, I think you are looking in the wrong place for optimization.
What you can do is make sure that images served from a domain separate from the application to make sure the clients aren't sending cookie headers when they request static images. Using a CDN for serving static content is also recommended.
Two general questions I'm wondering about both in the case for a given file(.js, .css, etc.) where you've set an expires header and also when you have not:
Do browsers request a new file (NOT serving the cached one) only if the file name has changed? Browser's don't assess the file contents too, correct?
Do ALL browsers behave the same regarding question #1 or are there known to be differences between them, for example on mobile (iOS safari, etc.)?
thank you,
tim
The browser can't check file contents unless it downloads the file. (The browser does not, for example, request a checksum). It usually delegates the task of content-checking (or timestamp-checking) to the server. The browser will send an if-modified-since header with a timestamp. The webserver will check to see if the file has changed, and if not, it will send a 304 not modified code.
All browsers follow this basic protocol. Servers may vary in how they decide if a file has changed.
I have a few files that are served via a content delivery network. These files are not gzipped when served from the CDN servers. I was wondering if I gzip the content on my servers' end, would Akamai first get the gzipped content and then serve gzipped content once it stores my content on their servers?
Akamai can fetch content from your origin without gzip, and then serve the content as gzipped on their end. They will store the content unzipped in their cache, and then compress on the fly for those browsers that support it.
I can't find a reason where settings Gzip compression to always is not beneficial to your end user. You can do this by setting Last Mile Acceleration to Always in Akamai