Spurious ^M characters

According to most of the protocol RFCs (e.g., for SMTP, POP, HTTP, ...), lines of text are always sent on-the-wire terminated by the CR-LF sequence, i.e., ASCII decimal 13 then ASCII deicmal 10. Each machine will store text files in its native format, and convert to and from the on-the-wire format.

I think there is some confusion within MODx as to how lines of text should be sent. It appears that sometimes MODx sends lines terminated correctly (i.e., CR-LF), and at other times, it sends an extra LF (i.e., CR-LF-LF).

I do not know if MODx is actually sending CR-LF-LF, or if it might be sending something else. But the final result is that after PHP and Apache have done their work, what is received by the web browser from its http session is lines sometimes containing an extra LF at the end.

Modern browsers are programmed to ignore these spurious LFs.. But I can see the spurious LF if I look at the source of the web page with a viewer such as gvim that understands multiple end-of-line conventoins and is able to explicitly shows the extra LF.

These LFs are sporadic, i.e., they don’t occur at the end of every line, but only at the ends of some lines.

Whether or not you the reader considers this a bug will depend on your point of view. Is it a bug if the author of the web browser anticipated it and included a work-around ahead of time?

Rahul

I don’t think this has anything to do with MODx. If it does, I can’t see it on any MODx site I have deployed. Some more details about your specific content being rendered via MODx, custom snippets, etc., and/or some investigation at the web server level might reveal some solutions for you.

To eliminate any of my snippets, etc., from the equation, I did an experiment.

I typed the folowing commands on a Linux system:



Both the Apache Foundation and the World Wide Consortium are big on
standards. The output files from their top pages, as viewed with vim
above, included no CR characters.

The output file from www.modxcms.com had a CR at the end of most lines.
But two "meta" lines in the head, and a couple of "script" lines in the
body, did not contain any CR.

Plenty of web sites send spurious CR characters. These do no harm, other
than taking up some bandwidth. So this bug, if we call it a bug, is
relatively harmless. This extra bandwidth would be of consequence only
on a very busy web site -- like that of Google.

Not only did I see no CR characters from www.google.com, but also all of
the output was squeezed into three line lines. So Google is saving not
only on the spurious CR, but on the required CR-LF as well, by sending
fewer lines.

Yahoo is not quite as frugal. It sent me 179 lines (but no CR).

Rahul

P.S. I am editing this to make the following correction: The spurious
characters are CR, not LF. In my initial posting, I incorrectly wrote LF
instead of CR. Although spurious LF could also occur, I would not see
it as LF, since on my Linux systems an extra LF would just cause an
empty line. It’s possible that people on Microsoft-oriented systems
would notice spurious LFs if they occurred. But i did not see any
extra empty lines in my experiments above.