I’ve been seeing this behavior where suppressing whitespace in Mura CMS would left-justify the response from Lucee, including HTML content inside
tags. Is whitespace suppression an all or nothing proposition or should it be able to distinguish between “bad” whitespace and intentional whitespace? I turned off whitespace suppression since I can compress responses with gzip in Nginx, but this seems like a bug. Thoughts?
Distinguishing between “good” and “bad” whitespace is difficult to get
right. I’ve found I can only strip whitespace reliably using cfsavecontent
and one or more replace or rereplace statements, focusing selectively on
chunks of code that generate significant amounts of it while avoiding
chunks of code that cause issues. One problem I’ve had in the past is that
while refactoring an app, I introduced new code javascript code that broke
because of whitespace stripping already in place and was completely baffled
for a time why it wasn’t working.
So I’d be on the fence whether any generic approach to suppressing
whitespace is a bug (and one worth fixing at that).
Gzip in Nginx sounds like a much better solution to me. I’d be interested
to see how you’ve configured it.
Aria Media Sagl
+41 (0)76 303 4477 cell
skype: ariamediaOn Sun, Apr 24, 2016 at 9:53 PM, Robert Munn <@Robert_Munn> wrote:
I’ve been seeing this behavior where suppressing whitespace in Mura CMS
would left-justify the response from Lucee, including HTML content inside
tags. Is whitespace suppression an all or nothing proposition or
should it be able to distinguish between “bad” whitespace and intentional
whitespace? I turned off whitespace suppression since I can compress
responses with gzip in Nginx, but this seems like a bug. Thoughts?
--
Love Lucee? Become a supporter and be part of the Lucee project today! -
http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups
"Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/DA5FE959-3A3E-4A8F-85A8-53EC84A5B4FE%40gmail.com
.
For more options, visit https://groups.google.com/d/optout.
We have two types of “Whitespace Management” in Lucee (found in the
Admin under Settings > Output):
Simple – every subsequent whitespace character is removed
Smart – every subsequent whitespace character is removed, unless it
is inside one of the tags: ,
, or
It looks to me like choosing the second option above would have resolved
your issue, since it would have preserved whitespace within
...
tags (the "good" whitespace to use Nando's terminology), no?
As for GZip compression – if you use a web server like nginx, you will
likely get better performance from it, and have more control. The
built-in GZipping that Lucee offers is usually good when you do not
front Lucee with a web server.
Distinguishing between “good” and “bad” whitespace is difficult to get
right. I’ve found I can only strip whitespace reliably using
cfsavecontent and one or more replace or rereplace statements,
focusing selectively on chunks of code that generate significant
amounts of it while avoiding chunks of code that cause issues. One
problem I’ve had in the past is that while refactoring an app, I
introduced new code javascript code that broke because of whitespace
stripping already in place and was completely baffled for a time why
it wasn’t working.
So I’d be on the fence whether any generic approach to suppressing
whitespace is a bug (and one worth fixing at that).
Gzip in Nginx sounds like a much better solution to me. I’d be
interested to see how you’ve configured it.
On Sun, Apr 24, 2016 at 9:53 PM, Robert Munn <@Robert_Munn mailto:Robert_Munn> wrote:
I’ve been seeing this behavior where suppressing whitespace in
Mura CMS would left-justify the response from Lucee, including
HTML content inside <pre> tags. Is whitespace suppression an all
or nothing proposition or should it be able to distinguish between
“bad” whitespace and intentional whitespace? I turned off
whitespace suppression since I can compress responses with gzip in
Nginx, but this seems like a bug. Thoughts?
--
Love Lucee? Become a supporter and be part of the Lucee project
today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google
Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to lucee+unsubscribe@googlegroups.com
<mailto:lucee%2Bunsubscribe@googlegroups.com>.
To post to this group, send email to lucee@googlegroups.com
<mailto:lucee@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/DA5FE959-3A3E-4A8F-85A8-53EC84A5B4FE%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
–
Love Lucee? Become a supporter and be part of the Lucee project today!
Short of having the whitespace function in Lucee parse the response on the fly and avoid
tags, there is nothing to be done about it, I suppose. And it doesn’t seem like it would be worth the trouble and expense of parsing the response for what it would gain. I still sort of regard it as a bug because content by definition should not be modified, but I don’t know if it’s worth fixing.
The gzip stuff is easy. Here is how I configure it, in the server block of my host:
In my Bonny Doon Media site, it compresses plain text responses by 60-80 % or more- especially valuable for sites that make heavy use of JavaScript and CSS.
There is also a gzip static module for Nginx that will serve pre-compressed versions of your static content instead of compressing them on the fly. Very cool for saving CPU cycles:
If you have an automated build process in place for your code, you can easily gzip your static content during the build process and deploy .gz files along with (or in place of) your js/css/html. Just add:
gzip_static on;
to your server directives.
The gzip_static module isn’t built by default you have to enable it with:
–with-http_gzip_static_module
when you build Nginx from source.
I wrote a guide on building Nginx from source, just follow the recipe and add that parameter to the configure command to build the module:
Robert> On Apr 25, 2016, at 3:22 AM, Nando Breiter <@Nando_Breiter> wrote:
Distinguishing between “good” and “bad” whitespace is difficult to get right. I’ve found I can only strip whitespace reliably using cfsavecontent and one or more replace or rereplace statements, focusing selectively on chunks of code that generate significant amounts of it while avoiding chunks of code that cause issues. One problem I’ve had in the past is that while refactoring an app, I introduced new code javascript code that broke because of whitespace stripping already in place and was completely baffled for a time why it wasn’t working.
So I’d be on the fence whether any generic approach to suppressing whitespace is a bug (and one worth fixing at that).
Gzip in Nginx sounds like a much better solution to me. I’d be interested to see how you’ve configured it.
On Sun, Apr 24, 2016 at 9:53 PM, Robert Munn <@Robert_Munn mailto:Robert_Munn> wrote:
I’ve been seeing this behavior where suppressing whitespace in Mura CMS would left-justify the response from Lucee, including HTML content inside
tags. Is whitespace suppression an all or nothing proposition or should it be able to distinguish between “bad” whitespace and intentional whitespace? I turned off whitespace suppression since I can compress responses with gzip in Nginx, but this seems like a bug. Thoughts?