> Am 29.01.2016 um 00:06 schrieb Lukas <[email protected]>: > >> Lukas <[email protected]> [2016-01-28 22:04]: >> >>> [email protected] <[email protected]> [2016-01-28 15:12]: >>> >>> a customer has this in his .htaccess file (among other things): >>> >>> RewriteCond %{REQUEST_FILENAME} !-f >>> RewriteCond %{REQUEST_FILENAME} !-d >>> RewriteRule ^(.+)\.(\d+)\.(php|js|css|png|jpg|gif|gzip)$ $1.$3 [L] >>> >>> This is to enable versioning of various files, so you can have long >>> "Expires" on them and still update them as needed while retaining >>> the old ones, if needed. >>> >>> I want to deliver static files directly from nginx, so I created this: >>> >> >> Not exactly sure about the notation in nginx but for regexp what >> about: >>> location ~* ^(.+)\.(\d+)\.(js|css|png|jpg|gif|gzip)$ { > > Btw. > > a) ".+" matches a series of any character > b) "\d+" matches a series of any digit > >> coda-slider.1.1.1.1452703531.js > > would then be returned as > > coda-slider.1.1.1.js > > since the first series of digit-dot is matched by a).
Which is correct. > > If your customer has a file to be delivered that is named for example > > linux-4.2.1.gzip > > your regular expression would return > > linux-4.2.gzip > > since it strips off just the last digits-dot pair. OK, that would be sub-optimal ;-) On request, the customer switched off the cache-breaking, so that problem has been solved. As for the regex itself, I checked it in regex101.com and it did match the files. The customer has elected not to use typo3’s static file-cache and serve every page from typo3’s page-cache inside the database. To get some sort of sanity, I want to micro-cache all successful GET requests for a minute. Thanks for your ideas. Rainer _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
