Don't update Last-Modified when cache-extending #1085
Comments
Hello, I've check this for one JS that push a lot of "waiting ..." #1048 , it's the same : most of call to that js file give the error messages + Last-Modified is modified with the last call time. This file is not memcached, size > 1024 ko, but in file cache, and is LoadFromFile with IPRO on. Thanks, Eric |
you mean 1024 kb, (1M?) That is a large JS file. What is the exact configuration of your file-cache? Is it on a local disk? -Josh On Tue, Jun 2, 2015 at 8:21 AM, eldk notifications@github.com wrote:
|
Hello,
Yes, 1 Mbytes. I Know, it's a script based on openlayers : http://api.ign.fr/tech-docs-js/2.1.2/jsdoc/index.html .
Yes, on local disk, files up to 1024 Mbytes to file cache, others to memcached.
Yes, it's on local disk, only some folders : images which never changed (thumbnails, nav ...), and the folder which is dedicated to "openlayers" that contain script (one), styles, and images. The concern domain is now set apart on its own server. Thanks, Eric
|
Hmm.. How are these comments related to the issue I am seeing? We are instructing pagespeed Serf to fetch using the localhost. Here's the salient parts of our config (with default pagespeed.conf, this comes after): NOTE MapPagespeedOriginFromFile is not defined. <IfModule pagespeed_module>
# Needed because our SLB for the web terminates SSL and we are on a non-SSL port.
# see this: https://developers.google.com/speed/pagespeed/module/https_support
#
ModPagespeedRespectXForwardedProto on
# For SSL localhost server, we need to have a file fetch path for pagespeed to use as the origin
# server, for SSL original request we need a non-SSL localhost access path. See the description
# in here: https://developers.google.com/speed/pagespeed/module/domains
#
<IfDefine MapPagespeedOriginFromFile>
ModPagespeedLoadFromFileMatch "^https?://.*?/assets/(.*)" "${sandbox}/assets/\\1"
</IfDefine>
<IfDefine !MapPagespeedOriginFromFile>
ModPagespeedMapOriginDomain http://localhost https://*
</IfDefine>
# The LoadFromFile match causes page speed to avoid http fetches from origin webserver,
# The header mods below set The origin caching policy to 10 minutes. If we use MapOriginDomain
# and a CDN then this dictates how frequently mod_pagespeed must re-read the content files and recompute
# the content-hash. As long as the content doesn't actually change,
# the content-hash will remain the same, and the resources stored
# in browser caches will stay relevant.
<Location /assets/tve >
Header unset Etag
Header set Cache-control "public, max-age=600"
</Location>
|
Here's the bug.... Looking at a pcap analysis of the packets for a pagespeed fetch (numbers are the TCP frame number in the trace)
Because the 304 response does not have LastModified, this code in pagespeed, ads the "now" Last-Modified header: If no such header exists in the request. It should check the 304 |
@elkd I think your comment makes a lot more sense in the context of Issue 1048. Please follow up there (to the extent you haven't already). @stevemayhew I am trying to repro your problem but no success yet. I've managed to repro the problem: wget -q -O - --save-headers localhost:8080/mod_pagespeed_test/load_from_file/index.html?PageSpeedFilters=extend_cache each time I repeat the second wget I get a new Last-Modified header. The problem is specific to extend_cache, because that filter doesn't bother cache the rewritten file (it is usually identical or trivially transformed from the origin file). For other filters, the rewritten file and its computed Last-Modified header is saved, so the Last-Modified reflects the timestamp when PageSpeed optimized it, which seems correct to me :) But extend_cache it re-"optimizes" it on every request, which does not really give us what we want. This is something we should fix, but I'm trying to understand what the symptom is that this exhibits. The filename is already signed and cached for a year, so we don't really need if-modified-since behavior or anything like that. |
Sorry; garbled message above; I did get the repro case. I have a candidate fix which needs to be reviewed. Also in the comments above there is an observation that we rewrite an entry in the cache:
I think this is an inefficiency in our system, but it's separate from the Last-Modified problem. I'll split that off into a separate bug: #1122 |
When fetching a local resource, pagespeed is adding a Last-Modifed header. This breaks extend-cache function completely
As you can see from the last 2 curl's that pagespeed added a Last-Modified header with date/time as now (it keeps changing)
This faithfully is forwarded along to the service of the hashed file
Thus rendering the Expires useless.
Looks like it is re-writing the cache file each time a request is made to the hashed URL:
It would be best of PageSpeed completely ignored Last-Modified and relied on the shasum of the file for a check period.
The text was updated successfully, but these errors were encountered: