Rewrite rule for cache busting URLs

[Igor Sysoev]

On Wed, Jun 09, 2010 at 12:13:22PM -0400, bkirkbri wrote:

> Thanks Igor!
> 
> I should have been more specific though.  Sometimes the same resource is referenced in a versioned _and_ non-versioned form.  Also, the versioning applies to many resource locations.
> 
> So we would need many config entry pairs like this:
> 
> [code]
> location ~ ^/r\d+(/some/resources/.+)$ {
>     alias /path/to/resources/$1;
>     add_header Cache-Control 'public, max-age=2592000'; # 30 days
> }
> 
> location ^~ /some/resources {
>     alias /path/to/resources;
> }
> 
> ...
> [/code]
> 
> We can do that, but it makes the config harder to maintain.

People usually think that if they will "rewrite" to pass a processing
in one common location, it makes a configuration easier to maintain.
And if they will make many location given by literal strings (not regexs),
it makes a configuration harder to maintain.

They are wrong. The maintaince is divided to

1) changing configuration,
2) adding functionality.

If you will make many literal locations, the adding is easy: you just
add location in ANY place and you do not need to look how they affect
to old locations. If you need to change configuration you need just
to find/replace relevant things in your favourite editor.
You do not need to look and understand whole configuration.
You need just to be attentive. That's all.

If you use regex locations or even worse, rewrite's, then the adding
becames nightmare: you have to look through all configuration to see
how the addintion will affect to previuos configuration.
As to the changing, it may be easy or may be the same nightmare.

> Another related question: if we configure FastCGI access to our application in a separate file and include that same config file in many location {} blocks with "include" will that cause any problems?

No, however, it's better to  configure FastCGI in this way:

       location /dir1/ {
           fastcgi_pass   backend;
           fastcgi_param  SCRIPT_FILENAME  /path/to/$fastcgi_script_filename;
           fastcgi_param  QUERY_STRING     $query_string;
           include        fastcgi_common;
       }

       location /dir2/ {
           fastcgi_pass   backend;
           fastcgi_param  SCRIPT_FILENAME  /path/to/$fastcgi_script_filename;
           fastcgi_param  QUERY_STRING     $query_string;
           include        fastcgi_common;
       }

       location /dir3/ {
           fastcgi_pass   backend;
           fastcgi_param  SCRIPT_FILENAME  /path/to/index.php;
           fastcgi_param  QUERY_STRING     q=$uri;
           include        fastcgi_common;
       }

Because SCRIPT_FILENAME and QUERY_STRING usually defines how location
should be processed.


-- 
Igor Sysoev
http://sysoev.ru/en/