I can see how serving XML as static could be an issue with web2py since it can be used in so many different ways. I think I'll remove that part.
I was thinking that there seems to be instances when images would be served from outside of the static directory, like an app's custom upload directory, dynamically generated imagery similar to those you'd get from PHP's GD or Imagick libraries, etc. I can think of circumstances where those might not be best stored in the static directory. Perhaps two static location blocks would be beneficial. One to cover the whole static folder and one to cover any static file types you may find yourself wanting to store outside of the static directory. Thanks for the clarification on gzip. I already had it enabled for pages, I'll enable it for static content as well and zip up my static folder before deploying. On Wednesday, August 21, 2013 1:46:06 PM UTC-7, Niphlod wrote: > > with your config you enable for everything that ends with those extensions: > - the "disable" of the access log > - the cache header set to a very distant time in the future > This means that if someone by any chance requests an url from your > application that ends in xml, you short-circuit nginx to think it should be > served as a static file instead of a dynamic xml response from your app. > > the web2py config instead stands by the convention that everything is > supplied by a dynamic "something" (i.e. usually a controller) and that > everything under "/static/" is a real static file to be served. > Optionally, it enables the same cache headers and, if you want, it enables > the serving of pre-compressed static files. > > PS: More on the precompression topic: usually you'd want everything served > compressed. it cuts off response times considerably, because you shorten > the time a resource takes to be transferred in the compressed format vs the > original one (the compressed format is a gz compression, kinda like a zip > archive). > But, for static files, you don't want your nginx server to use cpu cycles > for every request to compress those files, because they are static and they > never change. > Web2py uses the same convention: if a ".gz" file is found, it serves that > instead of the original one to cut off the size of the transferred files. > So, if you have bootstrap.css and bootstrap.css.gz in your folder, with > that > > include /etc/nginx/conf.d/web2py/gzip_static.conf; > > line you enable serving boostrap.css.gx instead of bootstrap.css without > requiring nginx to compress dinamically the bootstrap.css file. > There's a script (scripts/zip_static_file.py) that creates those ".gz" > files for you. > This is explained at > http://web2py.com/books/default/chapter/29/13/deployment-recipes#Compress-static-files > > On Wednesday, August 21, 2013 8:59:18 PM UTC+2, HittingSmoke wrote: >> >> I've been going back over my configuration compared to various other >> deployment recipes after realizing I was missing some non-critical uwsgi >> related parameters. I noticed my static location block in nginx was >> different than the one recommended in the web2py nginx+uwsgi setup script. >> >> Here's what I use, which I took from the config I use on PHP vhosts, with >> only the commented out gzip line added for web2py: >> >> location ~* \.(jpg|jpeg|gif|png|svg|css|js|ico|xml|ttf|otf|woff)$ { >> access_log off; >> log_not_found off; >> expires max; >> >> #include ~/nginx/conf/web2py/gzip_static.conf; >> } >> >> Here is what's created by the stock web2py script: >> >> location ~* ^/(\w+)/static/ { >> root /home/www-data/web2py/applications/; >> #remove next comment on production >> #expires max; >> ### if you want to use pre-gzipped static files (recommended) >> ### check scripts/zip_static_files.py and remove the comments >> # include /etc/nginx/conf.d/web2py/gzip_static.conf; >> ### >> } >> >> Is there any disadvantage to my static handling over what's recommended? It >> seems mine would be advantageous as it would also serve file system uploads >> that are not saved to the static directory directly with nginx. >> >> >> Additionally, is it okay to enable static_gzip before zipping my static >> assets? If I've not yet reached production with an app will the server >> fallback to the unzipped assets in the absence of zipped files? >> >> -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
