PHPackages                             mindgruve/mg-reverse-proxy - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Caching](/categories/caching)
4. /
5. mindgruve/mg-reverse-proxy

ActiveLibrary[Caching](/categories/caching)

mindgruve/mg-reverse-proxy
==========================

Simple reverse proxy cache

0.9.2(9y ago)32.0k2[4 issues](https://github.com/mindgruve/mg-reverse-proxy/issues)MITPHP

Since Dec 31Pushed 9y ago5 watchersCompare

[ Source](https://github.com/mindgruve/mg-reverse-proxy)[ Packagist](https://packagist.org/packages/mindgruve/mg-reverse-proxy)[ RSS](/packages/mindgruve-mg-reverse-proxy/feed)WikiDiscussions master Synced today

READMEChangelog (10)Dependencies (5)Versions (34)Used By (0)

mg-reverse-proxy
================

[](#mg-reverse-proxy)

MG-Reverse-Proxy provides a bridge between your web application and the Symfony HTTP Cache. Using MG-Reverse-Proxy you can cache applications like Wordpress similar to how you would cache a Symfony application. It works by transforming the output buffer and headers created by your application into a Symfony Reponse object that the can be intellegently cached. It works great for legacy projects and applications not built on Symfony full stack framework (like WordPress, Joomla, even Magento sites).

Similar to Symfony HTTP Cache, MG-Reverse-Proxy will cache responses that are set to PUBLIC, have a positive MAX-AGE, and the request is a 'safe' HTTP methods (ie GET or HEAD).

Since MG-Reverse-Proxy is a simple wrapper around the Symfony HTTPCache, the documentation provided by Symfony will be helpful in understanding the internals of MG-Reverse-Proxy. For more information on the Symfony HTTPCache see: [http://symfony.com/doc/current/book/http\_cache.html](http://symfony.com/doc/current/book/http_cache.html)

Use Cases
---------

[](#use-cases)

Content heavy sites are a good candidate for MG-Reverse-Proxy. You can customize the cacheability of the responses by setting cache headers in your application or configuring your cache adapter (described below).

You can use MG-Reverse-Proxy in situations where installing a dedicated caching solution like Varnish might not be posible. In contrast to Varnish, MG-Reverse-Proxy is written in PHP which allows you to add a caching layer to web applications easier.

Benefits of caching...
----------------------

[](#benefits-of-caching)

Initial request (or stale cached requests):

```
Request -> Is caching enabled?
        -> MG-Reverse-Proxy bootstraps your application and creates a Symfony HTTPCache object and HTTPKernel.
        -> Your application generates webpage (multiple hits to database)
        -> MG-Reverse-Proxy captures the outputbuffer and transforms it into a Symfony Response object
        -> The cache adapter sets headers if applicable
        -> The Response object is returned to the Symfony HTTPCache
        -> The Symfony HTTPCache stores result in local cache
        -> Finally, the response is returned to user

```

Subsequent Requests:

```
Request -> Is caching Enabled?
        -> Webpage respone pulled from cache
        -> Returns cached response to user

Note: With a cached response, your application is not bootstrapped at all!

```

Cache Adapters
--------------

[](#cache-adapters)

Cache Adapters are the entry point for you to add your caching business logic. A Symfony Response object is created and provided to your Adapter so that you can set the Cache headers. MG-Reverse-Proxy will then use that Response to intellegently cache. Included in the source code are two sample adapters - a generic adapter, and one for WordPress. You should write own adapter for your application either extends the **GenericCacheAdapter** or implements the **CacheAdapterInterface**.

Stores
------

[](#stores)

Symfony HTTPCache has the concept of a cache store. By default, this is a local directory on the file system. If you want to use a different caching strategy (memcache, redis...), you can use your own implementation of the **Symfony\\Component\\HttpKernel\\HttpCache\\StoreInterface** and pass it as an constructor argument.

\##Example Usage - Wordpress index.php The index.php file for WordPress looks like...

```