I have a webserver without content-coding (boa and not enough ressources). is there a possibility to put ziped javascript-file on the webserver and unzip it at the browser after downloading like content-coding?
In theory yes. You would need to add the Content-Encoding: deflate header to your http response.
You can not place a zip file created by a zip program on the server to be transferred, as it contains a header with the file structure before the deflate payload begins.
Also mind the differences between gzip and deflate. With gzip, similar is possible, too.
Related
My company is thinking of moving from AWS to GCP. One of the feature we want to support from CloudCDN is brotli encoding. We have a techstack that will bundle our javascript into 3 files:
chunk.js
chunk.js.gz
chunk.js.br
If CloudCDN receives client request headers Accept-Encoding: br, gzip is CloudCDN smart enough to serve up Brotli file? Moreover, will it be cached? If not, are there any other approaches in achieving this in CloudCDN.
AWS Cloudfront only offers this feature with the use of 2 lamdbas. Which I think is a bad idea.
Yes, Cloud CDN can cache all 3 representations and serve the correct one based on the client's Accept-Encoding header so long as the response from your origin server includes a Vary: Accept-Encoding header. There's more information at https://cloud.google.com/cdn/docs/caching#vary_headers.
Update:
I didn't realize you were using a Cloud Storage bucket as the origin. Unfortunately, neither Cloud CDN nor Cloud Storage have functionality that will rewrite client requests for /chunk.js to /chunk.js.br based on whether the client supports Brotli. I agree that would useful, so I filed an internal feature request.
When an origin server such as nginx is configured to select the appropriate file, Cloud CDN needs to go back to the origin server only on a cache miss. So long as the origin server's responses contain a Vary: Accept-Encoding header, Cloud CDN can serve cache hits directly from the edge by comparing the client's Accept-Encoding request header with the Accept-Encoding value specified when the response was cached. Clients that specify Accept-Encoding: br, gzip will be served from one cache entry while clients that specify Accept-Encoding: gzip will be served from another.
CloudFront now supports Brotli compression natively. If you're using S3 as your origin (or any origin that returns uncompressed content), CloudFront can automatically compress at the edge using Brotli or Gzip. You don't need to create three versions of the file or use Lambda#Edge.
https://aws.amazon.com/about-aws/whats-new/2020/09/cloudfront-brotli-compression/
My backend, in Rocket (Rust), does not have compression built in. So, it is dependent on the proxy to compress it. Though nginx ingress controller supports it, I thought whether the default one had it too as it has high availability.
If it does not have, then how should I setup?
UPDATE(2018-01-31): It looks like Cloud HTTP(S) Load Balancer supports GZIP. You just have to serve compressed content from your backend and the load balancer will pass it on.
However, NGINX is confused because of the Via header (it thinks proxies don't support GZIP, and on most cloud providers this is correct, but not Google). See this FAQ: https://cloud.google.com/cdn/docs/troubleshooting#compression-not-working
If you are using the nginx web server software, modify the nginx.conf
configuration file to enable compression. The location of this file
depends on where nginx is installed. In many Linux distributions, the
file is stored at /etc/nginx/nginx.conf. To allow nginx compression to
work with HTTP(S) load balancing, add the following two lines to the
http section of nginx.conf:
gzip_proxied any;
gzip_vary on;
I believe nginx does not compress requests via a proxy by default.
You can change its config to enable that:
gzip_proxied any;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
Source: https://blog.percy.io/tuning-nginx-behind-google-cloud-platform-http-s-load-balancer-305982ddb340
I am having problems with our .net openID authorisation
I am trying to use fiddler to view to flow of addresses and data, but fiddler isn't showing the url parameters in the return to localhost
so i tested this by typing
https://localhost:8080/#id=2
into IE and seeing what showed up in fiddler, it was
1281 502 HTTP Tunnel to localhost:8080 512 no-cache, must-revalidate text/html; charset=UTF-8 iexplore:19884
i tried looking at fiddler help for configuration it suggested not using localhost but using your machine name, I tried this is wasn't any different.
Thank you in advance.
This is the pre-question to get all the information I will need for the next question about the openid problem :)
I wanted to be looking at the response of the line above for the information I needed. This question is closed thanks
How do we enable gzip to reduce latency on both mobile and desktop users of static web resources?
You can upload Google Cloud Storage objects with a gzip Content Encoding, and they'll be served zipped to clients that send Accept-Encoding: gzip, which most browsers do.
See Transcoding of gzip-compressed files for more information.
I have a JBoss 5.1.1 server which needs to send SOAP messages to an outside party. This party has provided some WSDL files that I have used to generate the WebService code from. This is all working just fine.
However, now I need to enable GZIP support for the SOAP messages. In theory, it's as simple as adding an "Accept-Encoding: gzip, deflate" header to the SOAP requests' HTTP messages. The outside party will then send the response with GZIP encoding. However, I haven't found a way to make JBoss add that header. I'm hoping someone around here can tell me how to do that.