On Mon, Mar 23, 2009 at 11:10 AM, Boyle Owen <Owen.Boyle@xxxxxxxxxxxxx> wrote: >> -----Original Message----- >> From: André Warnier [mailto:aw@xxxxxxxxxx] >> >> Would that not prevent browser-level caching of the javascript ? >> If yes, that would probably more than cancel any advantage of the >> "minification", no ? > > I don't know for certain the OP's motivation but it may not be just to save bandwidth... > > There is a security imperative for cleaning up JS - comments, and even variable names, can reveal details about your server's implementation that may assist an attacker. You can (should?) go the whole hog and obfuscate the code too (re-write variables to "a", "b", "c" etc, remove white-space, etc..) > > Rgds, > Owen Boyle > Disclaimer: Any disclaimer attached to this message may be ignored. > I don't really see how JavaScript could reveal anything about your server...it's client side, so it shouldn't have anything to do with your server. I mean, if you're writing things in your comments like "// Oh yeh, the password to my server is foobar", then that's a whole other matter, but you probably deserve what you get for that anyway. Other than that, I'm very curious to know what sort of security concerns you're thinking of, perhaps it's something I need to address in my own code. Anyway, for the OP and others, if your concern /is/ response time, one thing to keep in mind is balancing network traffic transmission time with minification processing. If you reduce transmission time from 1 second to half a second, but it takes 3 seconds to do the minification, you've gained nothing but freeing some bandwidth on the pipe (which is courteous of you, but probably not what you want). I think this of particular concern with some of the "better" (read, more thorough) minifiers which parse the entire script and rewrite it with small arbitrary variable names, etc., as opposed to just filtering it like JSMin does. These certainly lead to smaller scripts, but take a significant amount of extra time to run. I think a nice alternative is to use a filter that will run the minification as necessary but simultaneously pipe the output to a file on the server. For each additional request, it can just check to see if the minified file is out of date compared to original, and if not, it can read directly from that file. There will be an initial time penalty on the first request after modifying the original script, but from there on out, it /should/ (I think, I haven't actually tested this) be significantly faster than re-running the minifier while still getting the reduced size and making sure it's always up to date (as opposed to serving the minified content statically and having to remember to regenerate it yourself when you make changes to your original). As long as we're on this topic, I'd like to step up on my soap box for a minute and beseech my fellow web developers to use minification thoughtfully. Reducing network traffic and speeding up load time is definitely a worthwhile goal, but we should always bear in mind that the web should be an open place to exchange ideas and techniques. Few things about web developing are more frustrating than seeing something cool on a person's page, and viewing the source only to find it's been minified to the point of obfuscation. If there are legitimate security concerns, then obviously that's a separate matter, but if the purpose is just minification, I think it'd be a real nice touch to precede the minified content with a brief comment indicating the URL for the original (unminified) source. Okay, I'll stop preaching now. -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://pgp.mit.edu/ --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx