Welcome! Log In Create A New Profile

Advanced

Re: Rewrite rule for cache busting URLs

June 09, 2010 02:36PM
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/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx
Subject Author Posted

Rewrite rule for cache busting URLs

bkirkbri June 09, 2010 11:21AM

Re: Rewrite rule for cache busting URLs

Igor Sysoev June 09, 2010 11:32AM

Re: Rewrite rule for cache busting URLs

bkirkbri June 09, 2010 12:13PM

Re: Rewrite rule for cache busting URLs

Igor Sysoev June 09, 2010 02:36PM

Re: Rewrite rule for cache busting URLs

bkirkbri June 09, 2010 03:56PM

Re: Rewrite rule for cache busting URLs

Igor Sysoev June 09, 2010 04:14PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 207
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready