Disable Shindig Caching - google-gadget

How can I disable caching in shindig? I tried passing nocache=1 parameter in the request. It disabled shindig caching but added Pragma: no-cache and Cache-Control: no-cache to the response.
I don't want to disable browser caching but just shindig caching. What is the right way to do so.
Any thoughts? Ideas?

You could disable content rewriting for all or some URLs in your gadget which will cause Shindig to not rewrite those URLs to go through the content proxy.

Related

Azure Webapp x-frame-options defined but Cloudflare seems to add sameorigin

We're hosting a .NET application on a WebApp in Azure. This has a web.config defined where we:
remove x-frame-options
add x-frame-options: ALLOW FROM randomurl.com;
When we directly go to the webapp with the hostname of azurewebsites, we get the correct x-frame-options defined.
However, when we go through Cloudflare, it always seem to add x-frame-options: SAMEORIGIN
Resulting in 2 x-frame-options in the response and probably ignoring our ALLOW since SAMEORIGIN is stricter.
I've checked all possible settings in Cloudflare but I can't find anything that would add this header.
We don't have any HTTP Response Header Modification set.
I don't think any WAF ruleset would automatically add a header.
Anyone has some ideas where to look further or what to test?

Cloudflare doesn't respect my origin cache control header

My nginx server return
cache-control: public, max-age=14400, s-maxage=2592000
for every request.
But for html files, it still returns
cf-cache-status: DYNAMIC
for other cachable file extensions, it returns:
cf-cache-status: EXPIRED
I've already purge all cache and refresh my browser for several times.
Something wrong with my settings?
Check cloudfalre cache level settings.

How to disable caching of a rewrite rule which proxies an internal server?

I'm using an htaccess rule to proxy to an internal server, using the answer recommended on this question, "Can ProxyPass and ProxyPassReverse Work in htaccess". I'm using htaccess as that is all I have access to. The method suggested works, but when I make a change on one of the internal pages and reload (from the external server) I don't even see it hitting the internal server, even after clearing the cache on the browser. In fact, if I try to load the page from another browser which never has tried to load the page before, it too gets the old copy.
This suggests something is being cached on the server, but how to change this? The apparent caching is rather annoying as I am trying to fix some issues that only occur on the proxied page.
If I hit the internal server directly and reload after a change, I always get the latest page.
I have tried a <filesMatch ...> rule for the affected pattern (using the same pattern as used in the RewriteRule in the following manner:
<filesMatch "^/?somedir/(.*)$">
Header set Cache-Control "max-age=0, private, no-store, no-cache, must-revalidate"
</filesMatch>
My rewrite rule looks like this, and comes after the filesMatch directive:
RewriteEngine On
RewriteRule ^/?somedir/(.*)$ https://internal.local.net:8000/$1 [L,P]
But this has not had any effect. I have also tried "NoCache *" but this directive causes an error as it is not allowed in an .htaccess file.
The P-flag in your RewriteRule causes the request to be proxied to the internal server using mod_proxy. mod_proxy by itself does not cache content. The caching is probably a result of mod_cache being enabled as well on the server. The settings you need to disable caching for your internal server can unfortunately only be done in server or virtual-host config. The solution would be to add what you tried to the configuration of the internal server thus telling mod_cache that it should not cache any response from your internal server:
Using .htaccess
Header set Cache-Control "max-age=0, private, no-store, no-cache, must-revalidate"
or PHP
header('Cache-Control: no-cache, no-store, must-revalidate'); // HTTP 1.1.
header('Pragma: no-cache'); // HTTP 1.0.
header('Expires: 0'); // Proxies.
Try adding this in an htaccess file in your "somedir" directory:
ExpiresActive On
ExpiresDefault "now"

header charset. where does it come from?

I have a problem with charset in http header. it shows "utf-8":
Content-Type: text/html; charset=utf-8
Where I can change this to iso-8859-1? I changed default charset in apache and nginx config, but it did not fix the issue.
it's coming from your application instead of apache and nginx. how you call your application, via CGI or fast cgi to php?

Prevent Apache from chunking gzipped content

When using mod_deflate in Apache2, Apache will chunk gzipped content, setting the Transfer-encoding: chunked header. While this results in a faster download time, I cannot display a progress bar.
If I handle the compression myself in PHP, I can gzip it completely first and set the Content-length header, so that I can display a progress bar to the user.
Is there any setting that would change Apache's default behavior, and have Apache set a Content-length header instead of chunking the response, so that I don't have to handle the compression myself?
You could maybe play with the sendBufferSize to get a value big enough to contain your response in one chunk.
Then chunked content is part of the HTTP/1.1 protocol, you could force an HTTP/1.0 response (so not chunked: “A server MUST NOT send transfer-codings to an HTTP/1.0 client.”) by setting the force-response-1.0 in your apache configuration. But PHP breaks this settings, it's a long-known-bug of PHP, there's a workaround.
We could try to modify the request on the client side with an header preventing the chunked content, but w3c says: "All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding", so I don't think there's any header like 'Accept' and such which can prevent the server from chunking content. You could however try to set your request in HTTP/1.0, it's not really an header of the request, it's the first line, should be possible with jQuery, certainly.
Last thing, HTTP/1.0 lacks one big thing, the 'host' headers is not mandatory, verify your requests in HTTP/1.0 are still using the 'host' header if you work with name based virtualhosts.
edit: by using the technique cited in the workaround you can see that you could tweak Apache env in the PHP code. This can be used to force the 1.0 mode only for your special gzipped content, and you should use it to prevent having you complete application in HTTP/1.0 (or use the request mode to set the HTTP/1.0 for you gzip requests).