Intercept error pages and serve custom content

[RealOrangeOne]

Fixes #7

The primary fix for this is proxy_intercept_errors, which enables error_page to be used when processing responses from proxy_pass.

Warning: If applications previously served their own status pages, or returned responses with a 404, 500-504 status, they'll be served the website's custom pages. This can be changed by adding error_page to the relevant location block

[PeterJCLaw]

Warning: If applications previously served their own status pages, or returned responses with a 404, 500-504 status, they'll be served the website's custom pages. This can be changed by adding error_page to the relevant location block

Do you have an example of what such a block might look like?
I'm mostly interested in knowing whether it's consistent between locations or not -- is it spelled as "don't intercept error pages for this proxy", or is it more like "for this proxy, override the handling to be these specific error pages". The latter strikes me as undesirable because it means that the proxy will need to know the details of how each of the underlying applications works.

I also wonder whether it will be possible to have the interception disabled or merely redirected. For example, something like the IDE or nemesis (at /userman) might want to return a 404 status code with a dynamic JSON body as part of an API response. If that response instead returned (static) HTML, then that could substantially complicate the client code for that application.

Edit: apologies for missing this when I suggested that proxy_intercept_errors might be useful; it only just occurred to me.

[RealOrangeOne]

The example there of nemesis is my primary concern, as in its current configuration, that would happen!

My original thought was that you'd define explicitly the 404 pages you'd want for each proxy location, but actually I agree that's less than ideal. The specific syntax would more likely work by disabling the proxy_intercept_errors setting, ie:

location /userman {
    proxy_intercept_errors off;
    ...
}

This would then function as it does right now, naively forwarding all statuses to the client without error_page modification.

[PeterJCLaw]

Yeah, if adding proxy_intercept_errors off nested works, I think that that's a great solution. Could we test that that works somehow?

[RealOrangeOne]

Theoretically, although I've not tested the current state of this PR, as everything has been read direct from the docs, and the SO post from #7 seems to show this working fine.

[PeterJCLaw]

@RealOrangeOne I've fixed the baseline error handling in master, which unfortunately creates conflicts with this branch (though I think may simplify the changes needed here).

Are you likely to have time to look at this (and the changes discussed above) any time soon?

[PeterJCLaw]

In fact, what would you say to instead having each of the proxied things turn on proxying of errors per-proxy rather than enabling overall and then disabling for some?

This moves to a default assumption that the underlying entity is probably going to have some handling and avoids the issue of needing to work out which would be broken by overriding that.

I'm thinking that for the moment we'd have only those which are proxying to GitHub Pages opt in to the error page interception, which is the main ones we're looking to fix here anyway.

[RealOrangeOne]

I think it's a reasonable assumption to assume the upstream apps handle 404s themselves, so there's little need to handle them ourselves. The only downside I see is that said upstream error pages might look terrible, which isn't the best UX, although the fact they're application-specific is a bit nicer!

[PeterJCLaw]

Yeah, I'm definitely thinking about this as being a prettiness factor only.