Grant wrote: >> >> As I understand it, the reason why you wish the whitespace to be >> reduced >> >> is so you look at the source within your browser, and that you >> plan to >> >> use mod_deflate later ro reduce bandwidth (which is surely not too >> much >> >> of a problem - it's probably equivalent to resampling a few of your >> >> images by 5% here and there, or optimising your caching!), but you >> can't >> >> reduce the whitespace inside your application logic (which is >> where the >> >> problem should be fixed) because you don't have control over the >> code. >> >> >> >> You have 3 (1,2,4) really good (performance neutral) options not >> >> mentioned so far, >> >> 1) use a whitespace stripping http proxy you run on your LAN >> >> 2) use mod security, removewhitespace in response body >> >> 3) use a rewrite rule to a reg exp based whitespace server-side >> script >> >> which serves each page of your application. >> >> 4) similar to (3) use an autoprepend rule to serve your white space >> >> laden pages through a reg exp based whitespace stripping script. >> >> >> >> I would probably go for 1,3 or 4, because they are so easy. > > Hi Matt, > > It doesn't sound like there's a simple solution to my blank line > problem. I wonder what kind of nasty side effects I might run into > from the handoff you described. I need to give your 4 points some > more thought. I can see that this has the status of a hack, however essentially you are just buffering the output stream and performing a reg exp on it, so if you are running php as a module its fast and painless. This technique works well with compression and so I use it for serving documents which I want to "depersonalise" and for large >10MB xml files. It doesn't seem to stress my poor little 700MHz P2 which hovers at 1% > >> >> (2) carries a performance hit, but use of mod security is highly >> >> regarded and I would say is an esssential part of protecting an >> >> application such as yours - one for which you do not own and cannot >> >> change the code. > > Have you used mod_security yourself? yes I can say that the code is extremely well written, and that the project as a whole has gained critical acclaim. If you are _not_ using it, do - it's very useful. The idea is to gain control over a problematic and complex application/codebase by modifying the IO stream to prevent many threats such as XSS, code release, SQL injection etc.. Well worth a look, it is as complex as the collective understanding of threats is, and allows you to react "intelligently" to new threats you (or it) sees in your logs. The "Cool Rules" project which has a recording out at the moment. http://www.modsecurity.org/projects/coolRules/index.html > >> AddOutputFilter DEFLATE pl > > I did add this to httpd.conf. How can I tell if it's working and are > there any drawbacks to using it? Well this just adds the additional step of allowing Apache to implement compression. Often resulting in as much as 90% drop in markup bytes, so include file extensions that contain markup, such as css and js. I have also used compression by default for 4 years with not issues. If the browser sends Accept-Encoding: gzip,deflate header then Apache will respond in kind. Your browser will uncompress the output so you won't notice anything different about your source code but if you run a proxy, this will report the stream a gzip or whatever, so you will only be able to read the markup in the proxy logs/packet sniffer if it has been decompressed. As for telling it is working the response headers will contain Vary: User-Agent,Accept-Encoding Content-Encoding: gzip most likely, and the bytes served will be much smaller than you are used to. > > - Grant > > --------------------------------------------------------------------- > 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 > > -- Matthew Farey --------------------------------------------------------------------- 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
|