<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, 1 Feb 2019 at 13:30, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>> wrote:<br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><br></div><div class="gmail_attr">Hi Maxim!</div><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
The 406 looks wrong to me. It tells the client that the response <br>
is not acceptable as per accept headers in the request. In your <br>
case it is more like 500,</blockquote><div><br></div><div>Concur. I did some research on Wikipedia and followed Cloudflare's example to use 520.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Note well that HTTP servers are allowed to return gzipped <br>
responses even to requests with "Accept-Encoding: identify". <br>
Quoting RFC 2616 (<a href="https://tools.ietf.org/html/rfc2616#section-10.4.7" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc2616#section-10.4.7</a>):<br>
<br>
Note: HTTP/1.1 servers are allowed to return responses which are<br>
not acceptable according to the accept headers sent in the<br>
request. In some cases, this may even be preferable to sending a<br>
406 response. User agents are encouraged to inspect the headers of<br>
an incoming response to determine if it is acceptable. <br></blockquote><div><br></div><div>Being a reverse proxy, in a sense it is that sort of inspection which I am attempting :-)</div><div><br></div><div>They are certainly allowed to do it in this circumstance, but it's not helpful for the proxy in question.<br></div><div> <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
This is not going to work as rewrite module directives are <br>
processed while selecting a configuration to work with (see <br>
<a href="http://nginx.org/en/docs/http/ngx_http_rewrite_module.html" rel="noreferrer" target="_blank">http://nginx.org/en/docs/http/ngx_http_rewrite_module.html</a>). <br>
Obviously enough this happens before the request is passed to the <br>
upstream, and before the response is received.<br></blockquote><div><br></div><div>Yep. NGINX is a marvel, but working out which bits of configuration are executed in what order, is still a challenge for me without coffee.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
You should be able to do what you want by writing a header filter <br>
which will check headers returned and will return an error if <br>
these headers don't match your expectations.<br></blockquote><div><br></div><div>Eventually I went with this, using Lua; I am still trying to work out how to make it return an informative message AS WELL AS the 520 error code, perhaps by using an internal redirect?</div><div><br></div><div>I am wondering whether a header filter can cause an internal redirect to a more useful "520 page"</div><div><br></div><div>Thank you for getting back to me! :-)</div><div><br></div><div>- alec</div><div><br></div><div><br></div><div>Extract from: <a href="https://github.com/alecmuffett/eotk/blob/master/templates.d/nginx.conf.txt" target="_blank">https://github.com/alecmuffett/eotk/blob/master/templates.d/nginx.conf.txt</a> </div><div><br></div><div><font face="monospace, monospace"> init_by_lua_block {<br></font></div><div><div><font face="monospace, monospace"> Dictionary = function (list)</font></div><div><font face="monospace, monospace"> local set = {}</font></div><div><font face="monospace, monospace"> for _, l in ipairs(list) do set[l] = true end</font></div><div><font face="monospace, monospace"> return set</font></div><div><font face="monospace, monospace"> end</font></div><div><font face="monospace, monospace"> is_compression = Dictionary{ "br", "compress", "deflate", "gzip", }</font></div></div><div><font face="monospace, monospace"> }</font></div><div><font face="monospace, monospace"><br></font></div><div><div><font face="monospace, monospace"> header_filter_by_lua_block {</font></div><div><span style="font-family:monospace,monospace"> local ce = ngx.var.upstream_http_content_encoding or ""</span><br></div><div><font face="monospace, monospace"> if is_compression[ce] then</font></div><div><font face="monospace, monospace"> -- I'd prefer to do something nice like this:<br></font></div><div><font face="monospace, monospace"> -- ngx.status = 520</font></div><div><font face="monospace, monospace"> -- ngx.say("upstream content was compressed and therefore not rewritable")</font></div><div><font face="monospace, monospace"> -- ngx.exit(ngx.OK)</font></div><div><font face="monospace, monospace"> -- ...but say() needs an API that is not available in this phase:</font></div><div><font face="monospace, monospace"> -- <a href="https://github.com/openresty/lua-nginx-module#header_filter_by_lua" target="_blank">https://github.com/openresty/lua-nginx-module#header_filter_by_lua</a></font></div><div><font face="monospace, monospace"> -- therefore:</font></div><div><font face="monospace, monospace"> ngx.exit(520) -- <a href="http://en.wikipedia.org/wiki/List_of_HTTP_status_codes" target="_blank">en.wikipedia.org/wiki/List_of_HTTP_status_codes</a></font></div><div><span style="font-family:monospace,monospace"> end</span><br></div></div><div><span style="font-family:monospace,monospace"> }</span></div><div><br></div></div>-- <br><div dir="ltr" class="m_-3670528509048985357gmail_signature"><a href="http://dropsafe.crypticide.com/aboutalecm" target="_blank">http://dropsafe.crypticide.com/aboutalecm</a><br></div></div></div></div></div></div>