I have a Drupal site where if i view the Request Header Cache Control, it is set to the following:
no-cache, must-revalidate, post-check=0, pre-check=0
However, i'm not seeing anywhere in the code where those headers are set.
I'm looking to add no-store to the cache control, and i was able to achieve that by doing the following:
drupal_add_http_header('cache-control', 'no-store, no-cache, must-revalidate, post-check=0, pre-check=0');
to the preprocess_html function of the theme. However, i want to ensure i'm doing it the right away and thats i'm not overwriting Drupal default or if there is a better way to set the header.
I did not have anything in the .htaccess in regard to cache control.
Thanks.
Related
I think I know how Safari is so "fast" they just cache the heck out of everything. What I am seeing is, two requests to the same url (even though they have different media types) are being returned with the same data. I have no cache headers in the $httpProvider but it still doesn't work. Anyone hit this?
I figure you have two options here.
Cache bust every request with a parameter, such as a timestamp
Add appropriate cache headers to your request to force Safari to respect the request
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Basically I am using a POST method but it automatically gets converted to OPTIONS method. I know browser does this but also read that it is fine and should get response as 201, but in my case it is not behaving as expected, I have also tried Access-Control-Allow-Methods in request headers but didn't get anything.
This is what my Request looks like:
OPTIONS http://xyz/abc
Accept: application/json
Content-Type: application/json
Response:
405, Method Not Allowed
Access-Control-Allow-Origin: *
Date: Tue, 05 May 2015 06:15:19 GMT
Connection: close
Accept-Ranges: bytes
Access-Control-Allow-Headers: authorization, content-type
Content-Length: 0
Access-Control-Allow-Methods: GET, PUT, POST, DELETE, HEAD
Can anyone tell me the cause of this issue and what could be the exact reason for the same after having enough research everything looks fine at my end.
Thanks in advance.
You are probably seeing pre-flight check during a POST-request in cross-origin resource sharing. I don't know how your webserver needs to be setup to support this, but this Wikipedia article might be a first help: http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
The easiest solution is to do the POST request on the same origin as the where you are loading the web-page from. A reverse proxy might be a reasonable solution.
basically my problems is use set-cookie header with angular (looks like he is ignored even with the withCredentials set to true) but here is the problem if i make the same request the cookies go, but if i change the path does't work.
Example;
POST http://localhost/app/api/oauth/ HTTP/1.1
[other headers and payload]
then i get the answer:
HTTP/1.1 200 OK
Set-Cookie: ; expires=Wed, 31-Mar-2015 01:34:53 GMT
and send a request to access a resource:
GET http://localhost/app/api/oauth/test HTTP/1.1
Cookie:blah=something;
until now evething is ok, but when i try to access other resources on my server:
GET http://localhost/app/api/othercontroller/test HTTP/1.1
the cookie is not send anymore, only if i access some path after the path that create the cookie.
that is what network monitor show me. But i can't see that blah coockie on the resource tab (on cookie area).
Note: i already try use secure cookie or not and use http only cookie or not and all combinations between both of then. And i try don't use CORS or enable CORS, but anyone work too.
Anyone know what can be ?
Thanks for you time and patience.
I'm pasting my suggestion from my comment.
Your initial cookie is set in a response of a HTTP endpoint path that is deeper than your second request.
Set-Cookie: ; Domain=foo.com; Path=/; expires=Wed, 31-Mar-2015 01:34:53 GMT
You may specify where to put your cookie by specifying a Path parameter in your response header like given above.
Some information:
"Cache-Control: must-revalidate, max-age=300"
This tells mod_cache to cache the page for 300 seconds (max-age) - unfortunately mod_cache doesn't know the s-maxage option (see http://www.mnot.net/cache_docs/#CACHE-CONTROL), that's why we must use the max-age option (which also tells your browser to cache).
If mod_cache knew the s-maxage option, we could use
"Cache-Control: must-revalidate, max-age=0, s-maxage=300"
which would tell mod_cache, but not the browser, to cache the page.
The question:
How do I know if mod_cache is actually memory caching anything at all.
With firebug, you can disable the entire cache, so every css, js, image, video ...etc, it will request to the web server.
So if this mod_cache is working, activate the firebug cache and the files that have that header, only will be requested to the web server every s-maxage time
200 responses will contain an Age header. At least it does on Apache 2.2. I did not see the header on 304 responses.
I want to disable the cache for a JSP file on my google app engine website.
I have this:
<%
// Set to expire far in the past.
response.setHeader("Expires", "Sat, 6 May 1995 12:00:00 GMT");
// Set standard HTTP/1.1 no-cache headers.
response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate");
// Set IE extended HTTP/1.1 no-cache headers (use addHeader).
response.addHeader("Cache-Control", "post-check=0, pre-check=0");
// Set standard HTTP/1.0 no-cache header.
response.setHeader("Pragma", "no-cache");
%>
But the JSP is still in cache. I need to kill the user session and login again in order to reload the JSP code.
How do I disable the cache for a app engine JSP?
It might at that point be too late to change the response headers. They will simply be ignored. You can verify the presence of response headers in a HTTP debugger tool like Firebug.
In the JSP, you need to ensure that they are set before the response is committed (i.e. all headers are already sent; you cannot send another headers afterwards). I.e. ensure that they are in the very top of the JSP file and that no template text is before that piece of scriptlet. Template text may cause a commit of the response. The normal practice, however, is to use a Filter for this.
Implement javax.servlet.Filter wherein doFilter() method look like follows:
HttpServletResponse httpResponse = (HttpServletResponse) response;
httpResponse.setHeader("Cache-Control", "no-cache", "no-store", "must-revalidate"); // HTTP 1.1
httpResponse.setHeader("Pragma", "no-cache"); // HTTP 1.0
httpResponse.setDateHeader("Expires", 0); // Proxies.
chain.doFilter(request, response);
Map this in web.xml on an url-pattern of *.jsp and it ought to work.
See also:
Making sure a webpage is not cached, across all browsers