Merge lp:~allenap/launchpad/trac-sniffing-broken-bug-504310 into lp:launchpad
Proposed by
Gavin Panella
Status: | Merged |
---|---|
Approved by: | Gavin Panella |
Approved revision: | not available |
Merged at revision: | not available |
Proposed branch: | lp:~allenap/launchpad/trac-sniffing-broken-bug-504310 |
Merge into: | lp:launchpad |
Diff against target: |
149 lines (+60/-14) 2 files modified
lib/lp/bugs/doc/externalbugtracker-trac.txt (+35/-4) lib/lp/bugs/externalbugtracker/trac.py (+25/-10) |
To merge this branch: | bzr merge lp:~allenap/launchpad/trac-sniffing-broken-bug-504310 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Eleanor Berger (community) | Approve | ||
Review via email: mp+17139@code.launchpad.net |
Commit message
Work around broken Trac installations that return HTTP 200 when the resource is not found. This has caused Launchpad to believe that the trac-launchpad plugin is installed when it is not.
To post a comment you must log in.
Pre-implementation call with Graham Binns.
Recently we've noticed that several Trac installations return HTTP 200 for page not found (i.e. should be a 404). This breaks the sniffing we do to detect the presence of the Launchpad plugin <https:/ /launchpad. net/trac- launchpad>.
The fix proposed here is to check all HTTP 200 responses for the presence of a trac_auth cookie. This should not be present for a should-be-a-404 response. In the very very unlikely event that the authentication token we pass when sniffing (a deliberately bogus token: "check") is valid, the trac_auth cookie will be present.
I've tested this with http:// trac.macports. org/ - one of the main culprits of broken 404 behaviour - and it works fine.
Lint free, other than the usual pylint nonsense.
Test: bin/test -vvt 'external.*bug'