| 2007-03-15 12:02:30 |
James Henstridge |
bug |
|
|
added bug |
| 2009-11-06 05:22:30 |
Curtis Hovey |
launchpad-foundations: status |
New |
Triaged |
|
| 2009-11-06 05:22:33 |
Curtis Hovey |
launchpad-foundations: importance |
Undecided |
Low |
|
| 2011-06-25 22:18:41 |
Robert Collins |
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 |
|
| 2011-06-25 22:18:56 |
Robert Collins |
description |
Currently requests to Launchpad are handled by two app 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.
Two ways to fix this include:
* 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. |
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.
Two ways to fix this include:
* 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. |
|
| 2011-06-25 22:19:32 |
Robert Collins |
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.
Two ways to fix this include:
* 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. |
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 |
|
| 2011-06-25 22:46:08 |
Robert Collins |
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 |
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://issues.apache.org/bugzilla/show_bug.cgi?id=50654) |
|
