Activity log for bug #718898

Date Who What changed Old value New value Message
2011-02-14 17:55:31 Anthony Lenton bug added bug
2011-02-14 17:56:41 Anthony Lenton rnr-server: importance Undecided Medium
2011-02-16 11:40:15 Canonical ISD bug wrangler tags kb-task
2011-02-16 16:20:25 Canonical ISD bug wrangler tags kb-task kb-improvement
2011-02-22 09:10:36 Canonical ISD bug wrangler rnr-server: importance Medium Low
2011-02-22 09:10:36 Canonical ISD bug wrangler rnr-server: status New In Progress
2011-02-22 09:10:36 Canonical ISD bug wrangler rnr-server: assignee Michael Nelson (michael.nelson)
2011-02-22 09:37:28 Launchpad Janitor branch linked lp:~michael.nelson/rnr-server/718898-review-unique-prefix
2011-02-22 14:52:20 Łukasz Czyżykowski rnr-server: status In Progress Fix Committed
2011-02-22 15:24:57 Michael Nelson description Our current review filter/getter api call is at "/reviews/api/1.0/(?P<language>\w+)/(?P<origin>\w+)/(?P<distroseries>\w+)/(?P<package_name>[\w%+.;-]+)/$" This doesn't have a unique prefix path, as there are also url patterns for /reviews/api/1.0/reviews/ and others. With a bit of bad luck this will mean that at some point we'll be bitten by this pattern matching something we don't want it to match (get all reviews in language "reviews", origin "124", distroseries "flag"...). Even atm, when we don't have that problem, setting up Apache to avoid redirecting the right urls to https is proving to be a chore due to this badly chosen url layout. We should probably add a unique prefix to this call, for example, "/reviews/api/1.0/filter/(?P<language>\w+)/(?P<origin>\w+)/(?P<distroseries>\w+)/(?P<package_name>[\w%+.;-]+)/$" or "/reviews/api/1.0/get_reviews/(?P<language>\w+)/(?P<origin>\w+)/(?P<distroseries>\w+)/(?P<package_name>[\w%+.;-]+)/$" or something. This is a backwards incompatible change, so we'll need to support the old api still for a while, until the client is updated to use the newer api. Our current review filter/getter api call is at "/reviews/api/1.0/(?P<language>\w+)/(?P<origin>\w+)/(?P<distroseries>\w+)/(?P<package_name>[\w%+.;-]+)/$" This doesn't have a unique prefix path, as there are also url patterns for /reviews/api/1.0/reviews/ and others. With a bit of bad luck this will mean that at some point we'll be bitten by this pattern matching something we don't want it to match (get all reviews in language "reviews", origin "124", distroseries "flag"...). Even atm, when we don't have that problem, setting up Apache to avoid redirecting the right urls to https is proving to be a chore due to this badly chosen url layout. We should probably add a unique prefix to this call, for example, "/reviews/api/1.0/filter/(?P<language>\w+)/(?P<origin>\w+)/(?P<distroseries>\w+)/(?P<package_name>[\w%+.;-]+)/$" or "/reviews/api/1.0/get_reviews/(?P<language>\w+)/(?P<origin>\w+)/(?P<distroseries>\w+)/(?P<package_name>[\w%+.;-]+)/$" or something. This is a backwards incompatible change, so we'll need to support the old api still for a while, until the client is updated to use the newer api. QA Notes: Once you're certain that the USC version you are using includes rnr-client r31, ensuring that the client still pulls reviews from the server when displaying packages demos that this is qa-ok.
2011-03-31 20:44:09 Canonical ISD bug wrangler rnr-server: status Fix Committed Fix Released