Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Pagespeed 404s css files while they are being optimized. #12

Closed
augustoroman opened this issue Oct 23, 2017 · 1 comment
Closed

Pagespeed 404s css files while they are being optimized. #12

augustoroman opened this issue Oct 23, 2017 · 1 comment
Assignees
@augustoroman

Comments

@augustoroman
Copy link

augustoroman commented Oct 23, 2017 •
edited

See: apache#1644
hallerm pushed a commit that referenced this issue Oct 23, 2017
@augustoroman @hallerm
Fix #12 404 errors on css files while they are being optimized
2a9c2ca 
* Fix #9 X-Mod-Pagespeed header ends with "null"

The X-Mod-Pagespeed header is populated partially via LASTCHANGE from
src/build/lastchange.sh in the pagespeed build process. This script
looks like they intended for local builders to modify it, but it is
always fixed at zero. This fixes the earlier, failed attempt to put
our own version number in that field.

This is essentially equivalent to PR #10, but for the 1.12.34.2 branch
instead of 1.11.33.5.

Fixes #9 again.

* kill ResourceFetchTest

* Add fallback fetching of resources that are being optimized.

This adds a new pagespeed option "ModPagespeedFetcherFallbackTimeOutMs"

The problem causing 404s on websites with large CSS files was caused by the
call to BlockingFetch timing because the scheduler that was working on
optimizing the CSS file was taking too long.

In particular, this occurred when the CSS file referred to many other image
resources and the scheduler had those downloads queued up -- all subsequent
requests for the optimized file would initiate a refresh fetch to the underlying
resource, but that would get stuck in the scheduler queue behind all the other
resources to download.

Because of this, BlockingFetch would timeout after 5 seconds and return a 404
to the original client. That's bad.

Now, the code is modified so that after BlockingFetch starts the request for
the optimized resource it will start a second fallback request directly to the
unoptimized resource if the first request doesn't complete within a specified
timeout. This timeout is controlled by the ModPagespeedFetcherFallbackTimeOutMs
configuration setting.

The core logic in this change is encapsulated in the FetchRace class. This
class allows starting multiple background fetches in a race to write to the
output fetch. The first background fetch that starts writing a response wins.

* Rename RacerFetch -> Racer
@hallerm hallerm closed this as completed Oct 23, 2017
@hallerm
Copy link

hallerm commented Oct 23, 2017

Will verify this in a control branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@augustoroman augustoroman

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@augustoroman @hallerm