14 февраля 2012, 18:53 от António P. P. Almeida <appa@perusio.net>:
> Just to say that it works also with the cache on private:
>
> location /private/ {
> error_page 403 /403.html;
> auth_request /auth;
> # usual cache stuff
> proxy_pass http://backend;
> }
>
> location = /auth {
> proxy_pass ...
> proxy_pass_request_body off;
> proxy_set_header Content-Length "";
> proxy_set_header X-Original-URI $request_uri;
> # It's *here* that you cannot cache...
> }
>
> The previous was just an example where the cache location was really
> private. It cannot be accessed directly.
>
> I suspect the reason it cannot be cached is simply because not only it
> would defeat the authorization purpose as well due to the fact that
> this module doesn't care about the request body. It only deals with
> the headers.

You may want to read my previous post again. I wrote that caching
in the /private/ location block IS possible, but that each request
initiates an authorization subrequest, which - if allowed - retrieves
the requested file each and every time from the backend server
and then discards this file without updating the cache, and THEN
the original request retrieves the requested file from the backend
server AGAIN and stores it in the cache, where it remains until it
expires.

If you used the auth_request module without caching, each allowed
request would cause the same requested file to be retrieved twice
from the backend server. With caching, each request would cause
the requested file to be retrieved at least once if it was already in
the cache, and twice if it was not in the cache, which defeats the
purpose of caching, so you could just make sure the X-Forwarded-For
header is set correctly and pass requests directly to the backend
server.

AFAIK, the only way you can reduce the overhead of constantly retrieving
the entire file on each authorization subrequest would be to use
"proxy_method HEAD;" inside the authorization subrequest location block,
just like I did in my access_by_lua /test_access/ authorization subrequest
location block. Luckily, the auth_request module seems to work properly
with the proxy_method set to HEAD, at least in nginx version 1.1.14,
so you should always use "proxy_method HEAD;" in auth_request module
authorization subrequest location blocks to prevent entire files from
being retrieved on each authorization subrequest.

But if you use the auth_request module, you will still be unable
to do safe and reliable caching in the authorization subrequest
location block, while you can do any kind of caching safely and
reliably in the access_by_lua authorization subrequest location
block (/test_access/) - for example, you could set up a cache key
such as "$remote_addr$host$server_port$uri" to cache authorization
information to reduce the overhead even more without compromising
IP-based access control.

The auth_request module doesn't work with caching enabled
in the authorization subrequest location block because its post
subrequest handler only checks the subrequest response status
code, while the access_by_lua post subrequest handler not only
checks the subrequest response status code, but also restores
the event handlers, and properly copies the subrequest response
headers and body. BTW, nice work, Agentzh. :-)

Max
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx