>> The issue is that we have 3 applications (all PDFs) that show up fine in
>> apps.ubuntu.com.
>>
>> https://apps.ubuntu.com/cat/applications/oneiric/fullcircle-issue-57/
>> https://apps.ubuntu.com/cat/applications/oneiric/fullcircle-it-spec-3/
>> https://apps.ubuntu.com/cat/applications/oneiric/fullcircle-it-issue-56/
>>
>> However all three of these cannot be found in the Software Center client
>> (5.04) in Oneiric.
>>
>> Michael V is not able to reproduce and I believe that Anthony is unable
>> to reproduce the problem either. However the developer, Dave M and I can
>> reproduce it.
> There is a error when the client tries to update the data from the
> software-center agent server. With the help of you and Dave I found
> that the cache of httplib2 contains the follwing in e.g.:
> ~/.cache/software-center/scaclient/software-center.ubuntu.com,api,2.0,applications,en,ubuntu,oneiric,i386,,d8cf7fa67c82edc14789f34f01dad0df
>
> """
> content-location: https://software-center.ubuntu.com/api/2.0/applications/en/ubuntu/oneiric/i386/
> -x-permanent-redirect-url:
> http://software-center.ubuntu.com/api/2.0/applications/en/ubuntu/oneiric/i386/
> """
> This causes the httplib2 code to immediately raise a error.
>
> As a workaround we need to remove the "-x-permanent-redirect-url" from
> the servers response and then figure out if/how to fix httplib2.
- At first I thought it was httplib2 that was storing the https and
  http responses under the same file, but then I noticed that the cache
  filename includes an md5 sum of the complete url, including the
  scheme.
- Confirmed by looking at a dump of davmor's cache, that there were
  *two* files starting with
  software-center.ubuntu.com,api,2.0,applications,en,ubuntu,oneiric,i386
  (jpugh, could you confirm that you have two as well?), one for http
  and one for https, and they're redirecting the browser between each
  other, causing the infinite loop.
- As mentioned in my previous email, requesting available apps via https
  bounces you over to http, but requesting them via http returns the
  actual list of apps, so this didn't add up with the contents of
  davmor's cache.
- With RT #50628 we added a squid cache in front of our 2.0 API.  Until
  then, it seems the list of apps was being served over http*s*, and
  requesting over http would bounce you over (exactly opposite to how
  it is now.  This was a bug that was fixed during this RT.
- This RT was set up on production on February 2.  Checking the dates in
  the responses in davmor's cache, the redirect from http->https is from
  December (before the RT), and the redirect for https->http is from
  February 8 (after the RT), so that makes sense.
- The thing with 301 responses is that they *never* get expired by
  httplib2's cache.  They're permanent redirects, so that's technically
  the correct thing to do.

So I don't know how many users will be affected by this, but it seems
like the way to work around this would be to either:
a) Modify httplib2 a bit to expire permanent redirect responses from the
cache every once in a while, or
b) zap the entire cache and start over every once in a while.

Option a) would be tidier I think.  As for a short term fix, just
removing the cache (or just the entry for the http->https redirect)
should get rid of the problem.