Skip to content
This repository has been archived by the owner on Apr 21, 2023. It is now read-only.

"ModPagespeedImplicitCacheTtlMs " directive doesn't work in IPRO mode #865

Closed
GoogleCodeExporter opened this issue Apr 6, 2015 · 7 comments

Comments

@GoogleCodeExporter
Copy link


I'm using "mod_pagespeed 1.7.30.2-3702" beta version. 

"ModPagespeedImplicitCacheTtlMs " directive doesn't work in IPRO mode.
If the origin website doesn't specify a timeout (neither Expires nor 
Cache-Control), IPRO will be append a http header "Cache-Control: max-age=300" 
anyway, no matter what the "ImplicitCacheTttlMs" is set.

jmarantz@google.com said:
"
I think the correct behavior is that we should not put any extra cache headers 
in ipro-optimized responses, and that this might be a bug. 

We still need to use the implicit cache ttl to help tune the interval we check 
for updates at origin.  Otherwise we will add an extra round-trip to origin to 
do cache validation, which will increase latency.

However I think we *do* want to add a header (usually 
cache-control:max-age=300,private) when mod_pagespeed serves a 
not-yet-optimized resource.  This should occur only transiently while 
mod_pagespeeed optimizes the resource in the background.
"


Refer to:
https://groups.google.com/forum/#!topic/mod-pagespeed-discuss/yKJ-2bRKS7U

Original issue reported on code.google.com by centiped...@gmail.com on 10 Jan 2014 at 9:06

@GoogleCodeExporter
Copy link
Author

Original comment by jmara...@google.com on 12 Jan 2014 at 12:01

@GoogleCodeExporter
Copy link
Author

Original comment by matterb...@google.com on 14 Jan 2014 at 6:59

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

Quick question: what value did you set ImplicitCacheTtlMs to?
I /think/ any value greater than 300 will be ignored, but a smaller value 
should apply.
I will try to test this asap.

Original comment by matterb...@google.com on 15 Jan 2014 at 9:16

@GoogleCodeExporter
Copy link
Author

I have set up a test directory with a .htaccess containing:
    Headers unset Cache-Control
IIUC this will replicate the reported condition.

The results of fetching the resource with IPRO enabled with the default 
implicit TTL:
1st fetch: No Cache-Control header at all.
2nd fetch: Cache-Control: max-age=300
3rd fetch: Cache-Control: max-age=290

The 1st fetch is the case Josh thinks we should set the header to max-age=300, 
but is currently the only case we don't set it at all.

So, assuming Josh is correct, we need to do a few things:
* Plumb in the configured implicit TTL not just use the default.
* Set the max-age when responding with an unoptimized resource (*).
* DON'T set the CC header's max-age when responding with an optimized resource.

(*) This seems just wrong. Why would be want a 5 minute lifetime for a resource 
we "know" will "soon" be available in optimized form?

And what is the purpose of adding ",private" to the CC header?

Original comment by matterb...@google.com on 17 Jan 2014 at 4:35

@GoogleCodeExporter
Copy link
Author

> Quick question: what value did you set ImplicitCacheTtlMs to?
> I /think/ any value greater than 300 will be ignored, but a smaller value 
should apply.
> I will try to test this asap.

I set ImplicitCacheTtlMs for a very long time in my test. And I tried to set 
100,000ms, it's useless too.
I looked at the src code, it seems IPRO just use kDefaultImplicitCacheTtlMs 
directly (but I'm not sure.)

FYI:
For our scene (I only use IPRO mode, my MPS works as cache proxy), I'm still 
confuse whether I should add the Cache-Control header or not, because client 
side should not see a CC header if the origin doesn't have. It seems what I 
need is a configurable "MPS private" expires time. 

Original comment by centiped...@gmail.com on 20 Jan 2014 at 3:29

@GoogleCodeExporter
Copy link
Author

Needs to be documented in release 1.9.32.x but this was fixed by r3795 and was 
in 1.8.31.x.

Original comment by matterb...@google.com on 28 May 2014 at 6:39

  • Added labels: Milestone-V32, release-note

@GoogleCodeExporter
Copy link
Author

Original comment by matterb...@google.com on 28 May 2014 at 6:40

  • Changed state: Done

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant