Merge lp://staging/~stevenk/launchpad/new-twisted into lp://staging/launchpad

I guess you can qa this pretty well by doing an IMS request against
the librarian and observing if it has a content-type in the response;
that should avoid depending on just what is or isn't cached.

We might then want to flush the librarian squid cache?

> We might then want to flush the librarian squid cache?

Why?

On 24 October 2011 16:55, Robert Collins <email address hidden> wrote:
>> We might then want to flush the librarian squid cache?
>
> Why?

iirc (I may not), when it gets a 304 with a content-type from the
upstream server, it updates its own cached c-t. So the librarian
squid persistently contains some files with the wrong c-t.

On Mon, Oct 24, 2011 at 7:06 PM, Martin Pool <email address hidden> wrote:
> On 24 October 2011 16:55, Robert Collins <email address hidden> wrote:
>>> We might then want to flush the librarian squid cache?
>>
>> Why?
>
> iirc (I may not), when it gets a 304 with a content-type from the
> upstream server, it updates its own cached c-t.  So the librarian
> squid persistently contains some files with the wrong c-t.

As with most things its complex :)

On metadata updates: Firstly, squid doesn't rewrite the disk image for
the content, so after a restart squid will restore to the original c-t
anyhow.

On persistent caching: to remain cached the content will need to be
refreshed again, and (I'd need to check the headers) the C-T isn't
part of our minimal meta-data, so we'll read from disk each time. We
can confirm if this is the case by prompting a squid-side refresh and
seeing if the subsequent 200 from it has the wrong C-T (my memory of
the bug is that it doesn't). If it does have the wrong C-T, then yes
we probably need to pivot out the cache and start a deletion of the
current one.

-Rob