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.
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'