Static or dynamic content

[Francis Daly]

On Thu, Oct 20, 2016 at 09:19:29AM +0000, Jens Dueholm Christensen wrote:
> On Tuesday, October 18, 2016 08:28 AM Francis Daly wrote,

Hi there,

> > what output do you get when you use the test config in the earlier mail?
> 
> Alas I did not try that config yet, but I would assume that my tests would show exactly the same as yours - should I try or is it purely academic?

Academic now, I think.

> If upstream returns 503 or 404 I would like to have the contents of the error_page for 404 or 503 returned to the client regardless of the HTTP request method used.

> > Possibly in your case you could convert the POST to a GET by using
> > proxy_method and proxy_pass within your error_page location.

> How would you suggest I could use proxy_method and proxy_pass within the @error_503 location?
> I'm comming up short on how to do that without beginning to resend a POST request as a GET request to upstream - a new request that could now potentially succeed (since a haproxy backend server could become available between the POST failed and the request is retried as a GET)?

I was imagining doing a proxy_pass to nginx, not to upstream, for the
503 errors. So dealing with upstream is not a concern.

However, I've tried testing this now, and it all seems to work happily
if you omit the @named location for error_page.

I add "internal" below, to avoid having the url be directly
externally-accessible.

Does this do what you want it to do?

  server {
    listen 8080;
    error_page 503 /errors/503.html;
    location / {
      root html;
      try_files /offline.html @xact;
    }
    location @xact {
      # this server is "upstream"
      proxy_pass http://127.0.0.1:8082;
      proxy_intercept_errors on;
    }
    location = /errors/503.html {
      internal;
      # this serves $document_root/errors/503.html
    }
  }

For me, when "upstream" returns 503, I get back 503 with the content of
my /usr/local/nginx/html/errors/503.html, whether the initial request
was a GET or a POST.

So perhaps the previous awkwardness was due to the @named location and
the various rewrites.

If that does do what you want, then you can add something similar for 404,
I guess.

Cheers,

	f
-- 
Francis Daly        francis at daoine.org