static resources should probably be served with no last-modified date and a content based etag
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Triaged
|
Low
|
Unassigned | ||
Bug Description
Currently requests to Launchpad are handled by two apache servers running from different Launchpad trees.
Resources such as images, CSS and Javascript get served off the file system with a Last-Modified header. Since this header comes from the filesystem, the two app servers will provide slightly different results.
When the user's browser tries to revalidate one of these resources, it sends an If-Not-Modified header with that modification date. If the user has been bounced from one app server to the other in the right direction, the server will think that they have an out of date copy of the file and send it again.
possible fixes:
* rather than pick last modified dates from the file system, pick them from Bazaar inventory, which will be the same for both app servers
* send ETag that is dependent on the content instead. The head revision ID is one possibility here, but it changes more often than the files.
* use a content hash to determine the etag (see https:/
| Changed in launchpad-foundations: | |
| status: | New → Triaged |
| importance: | Undecided → Low |
| summary: |
- Resources should probably be served with no last-modified date and a - content based etag + static resources should probably be served with no last-modified date + and a content based etag |
| description: | updated |
| description: | updated |
| description: | updated |
