# HttpProxyModule vs HttpFastcgiModule **URL:** \ **Category:** NGINX\ **Created:** [June 20, 2012, 7:42pm UTC](https://www.ruby-forum.com/t/httpproxymodule-vs-httpfastcgimodule/220803 "2012-06-20T19:42:48Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\ **Post date:** [June 20, 2012, 7:42pm UTC](https://www.ruby-forum.com/t/httpproxymodule-vs-httpfastcgimodule/220803/1 "2012-06-20T19:42:48Z")
1. As I understand, we have to use HttpFastcgiModule for fastcgi call caching and HttpProxyModule for static files. Could someone please explain the reasons for why we have this distinction. In most of the cases I observed that there are similar directives only varying in the prefix, fastcgi\_ vs proxy\_. 2. I have a nginx server that has php-fpm. There I used the fastcgi\_ cache and I could see the caching. Now I have a proxy server where I want to achieve the caching. Now, should I be using fastcgi\_ cahe or proxy\_ cache? Most likely it should be proxy\_ cache!! But please help me understand. And if it proxy\_ cache then having fastcgi\_ cache at the first level is meaningless. We should have been fine with proxy\_ and fastcgi\_ should not have been there. 3. Clould someone also help me understand the flow of fastcgi caching. Static caching is somewhat clear. 4. I observed that the fastcgi response is cached as HTTP response (i.e. with HEADERS) unlike the static cache (files as sent to the client). I hope this is right. Why is this difference as compared to static caching. 5. Why is the temp location requied (How is spooling helpful here) ? 6. fastcgi\_cache\_use\_stale error timeout invalid\_header http\_500; - When is this directive helpful? I have gone through the nginx documentation. But I could not get these answers. It would be helpful if someone explains it. Thank you. Posted at Nginx Forum: > **[HttpProxyModule vs HttpFastcgiModule](https://forum.nginx.org/read.php?2,227731,227731#msg-227731)** > > 1. As I understand, we have to use HttpFastcgiModule for fastcgi call caching and HttpProxyModule for static files. Could someone please explain the reasons for why we have this distinction. In most of the cases I observed that there are similar... ---
**Author:** ![amodpandey](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/e9c0ed/32.png) [@amodpandey](https://www.ruby-forum.com/u/amodpandey)\ **Post date:** [June 20, 2012, 8:38pm UTC](https://www.ruby-forum.com/t/httpproxymodule-vs-httpfastcgimodule/220803/2 "2012-06-20T20:38:53Z")
On Wed, Jun 20, 2012 at 01:42:23PM -0400, amodpandey wrote: Hi there, > 1. As I understand, we have to use HttpFastcgiModule for fastcgi call > caching and HttpProxyModule for static files. Not quite. HttpFastcgiModule is for when you want nginx to talk to a fastcgi server. HttpProxyModule is for when you want nginx to talk to a http (or https) server. They speak different protocols, they use different modules. (There are other modules for when you want nginx to talk to a server using yet another protocol.) The http server you talk to using the proxy module can be as dynamic as you want – all nginx cares about is that it communicates using http. > In most of the > cases I observed that there are similar directives only varying in the > prefix, fastcgi\_ vs proxy\_. The user-facing parts are deliberately kept broadly similar among all of the “use a specific protocol to talk to an external server” modules. > 1. I have a nginx server that has php-fpm. You have an nginx server; and you have a php-fpm server, which is a fastcgi server and uses the fastcgi protocol. Therefore you use the fastcgi module to allow nginx to speak fastcgi to the fastcgi server. > There I used the fastcgi\_ > cache and I could see the caching. Now I have a proxy server where I > want to achieve the caching. Now, should I be using fastcgi\_ cahe or > proxy\_ cache? Most likely it should be proxy\_ cache!! But please help me > understand. Now you have a http server, and you want nginx to speak http to it? Use the proxy module. fastcgi\_cache can be used to cache what is returned from a fastcgi\_pass directive. proxy\_cache can be used to cache what is returned from a proxy\_pass directive. > 1. Clould someone also help me understand the flow of fastcgi caching. > Static caching is somewhat clear. I’m not sure what you are asking. “static caching” is based on the http response from a http server. “fastcgi caching” is based on the fastcgi response from a fastcgi server, which (deliberately) includes content very similar to that of a http response. Which part is unclear? From the user point of view, you probably don’t care about the difference. Request comes in; response goes out. Maybe the response came from the cache; maybe the response came from the back-end server. As the admin, you want to make sure it uses the cache where possible. As the user, you don’t care (unless it is using the cache where it really shouldn’t). > 1. I observed that the fastcgi response is cached as HTTP response (i.e. > with HEADERS) unlike the static cache (files as sent to the client). I > hope this is right. Why is this difference as compared to static > caching. That doesn’t match what I observe with the result of a proxy\_cache directive. > 1. Why is the temp location requied (How is spooling helpful here) ? Atomicity. If there is a file with the right name in the cache, then it is known to be correct. If instead you wrote that file a bit at a time, then a concurrent request could return a broken partial response. So write to a temp file, then move to the final place when it is correct. > 1. fastcgi\_cache\_use\_stale error timeout invalid\_header http\_500; - > When is this directive helpful? > **[Module ngx\_http\_fastcgi\_module](http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache_use_stale)** > > The ngx\_http\_fastcgi\_module module allows passing requests to a FastCGI server. Which part is unclear? All the best, ## f Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)