> Sounds reasonable. Though that still wouldn't help with standard static > file serving (i.e., when specifying "static" as the controller) because > web2py serves static files before hitting the app code at all (so no > opportunity for the app to set any headers). > >
Yes, that's true, but at least for app-managed files the modification to streamer would allow "internal" images to be served in a flexible way. A global setting for app, as for auth ones, for managing static file serving would allow even greater flexibility. That could afford rocket usage also for medium intranets, actually I think that static file serving through rocket is the "option" that make people decide to go for a "real webserver" when the number of users increase. For usual page serving with 5-10 files for css and images, also for very small sites, could mean the difference from serving, e.g., 4 users * 5 pages/minute * 7 files + 1*actual webpage = 160 requests/minute to 20. Static file serving is handled by web2py in every case, it's just in main.py that the static file is returned with response.stream without executing models/controllers/etc. We have options to minify,concat,inline css and js files, but that's an overoptimization (still doesn't properly work when you concat or minify files in different folders under static) if you can set cache headers for static files. An actual dream of mine, just to further "support" the whole "ideas we stole, ideas we had", is web2py "stealing" from rails, because apparently Rails automatically adds timestamps to all references to static files if you use the according helper methods (like stylesheet_link_tag, javascript_include_tag and image_tag). This means, that the URL of a static file is changed if the file’s timestamp is changed. This way, browsers automatically request the new file. So, maybe, we could implement a settings for serving application's static assets in this way: - no caching at all (just like now) - versioning with settings.static_assets_version = '1.2.3', rewriting the subfolder of static files dinamically in urls (e.g. /static/thisfile.css becomes /static/1.2.3/thisfile.css for the browser, no need to change css's references to images if set relative), setting a max-age of 31536000 (one year) When you develop, no cache at all, when you deploy, if you know you changed some javascript/css/image/whatever, set settings_static_assets_version to something else and voilà
