# .htaccess issues **URL:** \ **Category:** NGINX\ **Created:** [February 10, 2012, 6:08pm UTC](https://www.ruby-forum.com/t/htaccess-issues/216682 "2012-02-10T18:08:59Z")\ **Posts on this page:** 2\ **Page:** 2
**Author:** ![guilherme](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/77aa72/32.png) [@guilherme](https://www.ruby-forum.com/u/guilherme)\ **Post date:** [February 15, 2012, 8:06pm UTC](https://www.ruby-forum.com/t/htaccess-issues/216682/21 "2012-02-15T20:06:51Z")
Max, > 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. > (…) After reading your last 2 responses, I believe that you’re either seriously misusing auth\_request module or you simply don’t understand how it’s supposed to work. Long story short, Antonio is right and you’re not. Best regards, Piotr S. \< [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) \> ---
**Author:** ![guilherme](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/77aa72/32.png) [@guilherme](https://www.ruby-forum.com/u/guilherme)\ **Post date:** [February 15, 2012, 6:40pm UTC](https://www.ruby-forum.com/t/htaccess-issues/216682/22 "2012-02-15T18:40:26Z")
14 февраля 2012, 18:53 от António P. P. Almeida [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > proxy\_pass … > 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 [Previous page](https://www.ruby-forum.com/t/htaccess-issues/216682.md?page=1)