Re: Issue 989 in modpagespeed: IPRO with LoadFromFile on a resource that is already fully optimized severs cc:max-age=300.

[modpag...@googlecode.com]

Updates:
Summary: IPRO with LoadFromFile on a resource that is already fully
optimized severs cc:max-age=300.
Owner: jcrow...@google.com

Comment #6 on issue 989 by jmara...@google.com: IPRO with LoadFromFile on a
resource that is already fully optimized severs cc:max-age=300.
https://code.google.com/p/modpagespeed/issues/detail?id=989

Summary was: wrong cache settings on static ressources /
ModPagespeedLoadFromFile

Great; that's a good temporary workaround for now.

However, we need try to repro fix this bug. Probably the correct remedy is
that mod_pagespeed should not handle unrewritten resources in the IPRO
path, but instead let Apache handle them normally.

Note that when we load resource via LoadFromFile we don't have any way to
figure out what cache-control would have been sent by Apache.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[modpag...@googlecode.com]

Comment #7 on issue 989 by osch...@we-amp.com: IPRO with LoadFromFile on a

resource that is already fully optimized severs cc:max-age=300.
https://code.google.com/p/modpagespeed/issues/detail?id=989

I would like to propose adding a "Cache-Control: s-maxage=somethingsmall"
for unoptimized IPRO responses, to force proxy caches to revalidate at some
point and force them to fetch the optimized asset in the case where the
original Cache-Control header has a long TTL.

[modpag...@googlecode.com]

Comment #8 on issue 989 by jmara...@google.com: IPRO with LoadFromFile on a

resource that is already fully optimized severs cc:max-age=300.
https://code.google.com/p/modpagespeed/issues/detail?id=989

I think there are three cases here, all in the context of LoadFromFile:

1. resource is not yet optimized
2. resource cannot be optimized (because origin resource is already optimal)
3. resource is optimized

What you are describing is case #1, and for that I think it makes sense to
send out headers that will prevent it from being cached in a proxy, at
least for a long time. However I think this bug is really about case #2,
and it turns out we also have a problem with case #3.


Case #2 can be solved, I think, by just declining to handle unoptimizable
cases in the IPRO flow.

However, I think case #3 is also a problem. We are using our implicit
cache TTL rather than the origin TTL when we grab the file with
LoadFromFile. We never learn the origin TTL because we don't let Apache
handle that request normally. I think to solve this we need a new config
file option to set the TTL used for IPRO-optimized resources read directly
from the file system.


Back to case #1 (and Otto's point) -- currently we will (with LoadFromFile)
issue the same public 300 second cache lifetime for that too, which I think
is yet another code path :)

[modpag...@googlecode.com]

Comment #9 on issue 989 by jcrow...@google.com: IPRO with LoadFromFile on a

resource that is already fully optimized severs cc:max-age=300.
https://code.google.com/p/modpagespeed/issues/detail?id=989

For case number 2, this is controled by ImplicitCacheTtlMs.

Setting something like

ModPagespeedImplicitCacheTtlMs 2592000000

should address the issue. (At least it seems to fix it from what I've seen.)

[modpag...@googlecode.com]

Updates:
Status: RequestClarification

Comment #10 on issue 989 by jmara...@google.com: IPRO with LoadFromFile on

a resource that is already fully optimized severs cc:max-age=300.
https://code.google.com/p/modpagespeed/issues/detail?id=989

Thanks for confirming, Jeff. azurro.tom: this seems like a plausible
short-term workaround for you, right? The question is, are we comfortable
using this same Option to control two different things:
1. the TTL we use as a default value for resources that lack any
Cache-Control or Expires header
2. the TTL to use for all LoadFromFile requests independent of what the
TTL would be if LoadFromFile
were not used.

Is this an acceptable long-term workaround? Or should we add a new
option? Note that we *don't* have a strategy to figure out what the
cache-control would have been had mod_pagespeed not served the resource
directly from the file-system.

[modpag...@googlecode.com]

Updates:
Status: Fixed

Comment #11 on issue 989 by jcrow...@google.com: IPRO with LoadFromFile on

a resource that is already fully optimized severs cc:max-age=300.
https://code.google.com/p/modpagespeed/issues/detail?id=989

ModPagespeedLoadFromFileCacheTtlMs option added in r4277 to address this
issue.

This option, when set will be the default load-from-file cache ttl. If not
set, it is overridded by the ImplicitCacheTtlMs.

[modpag...@googlecode.com]

Comment #12 on issue 989 by hug...@betabrand.com: IPRO with LoadFromFile on

a resource that is already fully optimized severs cc:max-age=300.
https://code.google.com/p/modpagespeed/issues/detail?id=989

I was having this exact issue described here and randomly found this report.

So just as an FYI, there's currently no documentation about
ModPagespeedLoadFromFileCacheTtlMs.

[modpag...@googlecode.com]

Comment #13 on issue 989 by jcro...@google.com: IPRO with LoadFromFile on

a resource that is already fully optimized severs cc:max-age=300.
https://code.google.com/p/modpagespeed/issues/detail?id=989

thanks for pointing this out as missing. I'll add it to the docs!