For-purchase apps not showing up on Oneiric
Bug #938736 reported by
Michael Nelson
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
software-center (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Oneiric |
Fix Released
|
High
|
Unassigned | ||
Precise |
Fix Released
|
High
|
Unassigned |
Bug Description
TEST CASE:
- there is no really good test case except for a regression test, the issue happens with a certain ~/.cache/
There have been reports recently (from jpugh, davmor2 and a dev) of for-purchase apps not displaying in Software Center (the most recent being https:/
Apparently it was discussed recently (I wasn't involved) and diagnosed as some type of cache issue, but I'll let those in the know update this description with something more useful.
Related branches
Changed in software-center (Ubuntu Oneiric): | |
status: | New → In Progress |
Changed in software-center (Ubuntu Precise): | |
status: | Confirmed → In Progress |
Changed in software-center (Ubuntu Oneiric): | |
importance: | Undecided → High |
Changed in software-center (Ubuntu Precise): | |
importance: | Undecided → High |
description: | updated |
To post a comment you must log in.
>> The issue is that we have 3 applications (all PDFs) that show up fine in /apps.ubuntu. com/cat/ applications/ oneiric/ fullcircle- issue-57/ /apps.ubuntu. com/cat/ applications/ oneiric/ fullcircle- it-spec- 3/ /apps.ubuntu. com/cat/ applications/ oneiric/ fullcircle- it-issue- 56/ software- center/ scaclient/ software- center. ubuntu. com,api, 2.0,application s,en,ubuntu, oneiric, i386,,d8cf7fa67 c82edc14789f34f 01dad0df /software- center. ubuntu. com/api/ 2.0/application s/en/ubuntu/ oneiric/ i386/ redirect- url: software- center. ubuntu. com/api/ 2.0/application s/en/ubuntu/ oneiric/ i386/ redirect- url" from center. ubuntu. com,api, 2.0,application s,en,ubuntu, oneiric, i386
>> apps.ubuntu.com.
>>
>> https:/
>> https:/
>> https:/
>>
>> 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/
>
> """
> content-location: https:/
> -x-permanent-
> http://
> """
> This causes the httplib2 code to immediately raise a error.
>
> As a workaround we need to remove the "-x-permanent-
> 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-
(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 ...