Expose the OOPS ID when the WSGI app produces its own error page

[James Henstridge]

If a WSGI app produces its own error pages, it would still be nice if there was some way to deduce the oops ID from that response.

The simplest (although least user friendly option) would be to add the oops ID to the response headers. This should be pretty easy to do when capturing the exception from the proxy start_response() method. For U1, we've been using the "X-Oops-Id" header.

Better would be to expose the oops ID in the error page content. With wsgi-oops this is possible because it exposes the ID of the potential oops report in the WSGI environment. I'm not sure how easy this is to do with python-oops though, prior to creating the report.

A third option would be to insert the oops ID into the page via client side JavaScript. The identifier would need to be stored somewhere that would be visible to the page, which rules out custom HTTP response headers. A short lived cookie might do the trick though, and should be just as easy to insert into the response as other response headers.

[Robert Collins (lifeless)]

x-oops-id is what I added to gpgverifyd, and there is a # TODO to add
this (in the appropriate place) in 0.0.2 of oops-wsgi already, so this
should be very straight forward.

[Robert Collins (lifeless)]

I've taken the simplest option; we can investigate the others (like a cookie) in a future iteration.