Filtering all blogs tagged as "apache."    Clear filter

Skipping cache for POST actions in Apache1

If you used page caching in a site that implements RESTful interface, you may face a problem. You could have multiple actions that share a single URL with different HTTP methods. For example, showing a document is served at /documents/1, while updating the same document is also at /documents/1. When I'm trying to update a document, the request is something like

PUT /documents/1

If your Apache is not well configured, it may respond with a cached file at /documents/1.html. This is wrong because this file should be served for GET requests only. In fact, POST, PUT and DELETE actions should never be cached because they change server state. Investigating in this issue, I found the following snippet at my .htaccess file.

Read More

Keeping separate caches for mobile browsers4

Among the three methods of caching views in Rails, I particularly prefer page caching. The main advantage of page caching is that it is delivered by the web server without accessing your Ruby on Rails server. In this blog post I'll describe how you can keep two separate caches: one for pc browsers and one for iPhone. You can easily extend it to support more than two versions.


In this tutorial I assume you are using Apache to serve your application with mod_rewrite and .htaccess files enabled.

Final solution (for impatient readers)

  1. Add the following code snippet in your ApplicationController
    layout proc { |controller| controller.request.subdomains.first}
    before_filter :set_cache_directory
    def set_cache_directory
      ActionController::Base.page_cache_directory = File.join(Rails.public_path, request.subdomains.first)
  2. Create two different layouts in your app/views/layouts directory. 'www.html.erb' for normal browsers and 'iphone.html.erb' for iPhone browsers.
  3. Add the following rewrite rules to <RAILS_ROOT>/public/.htaccess. Create it if it doesn't exist.
    RewriteEngine On
    # Force adding www at the beginning of URL
    # This rule is only applied when the host contains only one dot (.)
    RewriteCond %{HTTP_HOST} ^[^\.]+\.[^\.]+$
    RewriteRule ^(.*)$ http://www.%{HTTP_HOST}%{REQUEST_URI} [R,L]
    # Redirect users to subdomains by user agent
    RewriteCond %{HTTP_HOST} ^www
    RewriteCond %{HTTP_USER_AGENT} Mobile.+Safari [NC]
    RewriteCond %{HTTP_HOST} ^[^\.]*\.(.*)$
    RewriteRule ^(.*)$ http://iphone.%1%{REQUEST_URI} [R,L]
    #Caching for the index page (work around till I know a better solution)
    RewriteCond %{THE_REQUEST} ^GET
    RewriteCond %{REQUEST_URI} ^/$
    RewriteCond %{HTTP_HOST} ^([^\.]*)
    RewriteCond %{DOCUMENT_ROOT}/%1/index.html -f
    RewriteRule ^(.*)$ %1/index.html [L]
    # Redirect to caches in different subdirectories
    # Each cache corresponds to different subdomain
    RewriteCond %{THE_REQUEST} ^GET
    RewriteCond %{HTTP_HOST} ^([^\.]*)
    RewriteCond %{DOCUMENT_ROOT}/%1%{REQUEST_URI}.html -f
    RewriteRule ^(.*)$ %1%{REQUEST_URI}.html [L]

Now if you access your application using a normal browser it'll use the layout 'www' and the cached files will be stored under 'public/www'. If you use an iPhone or iPod touch, it'll use 'iphone' layout and store cached files under 'public/iphone'. You can easily add more layouts by adding an entry to .htaccess file and adding a new layout file.

If you need to know how this works, read the rest of this blog post.

Read More