Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100448
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain cubiclesoft.com designates 149.56.142.28 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>, internals@lists.php.net
References: <8C.6B.10715.4A4A0B95@pb1.pair.com>
Message-ID: <17df512e-ea9a-cb0b-758e-61b2fbcd9619@cubiclesoft.com>
Date: Thu, 7 Sep 2017 08:22:15 -0700
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327
 Thunderbird/11.0.1
MIME-Version: 1.0
In-Reply-To: <8C.6B.10715.4A4A0B95@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Consider only ignoring newlines for final ?> in a file
From: thruska@cubiclesoft.com (Thomas Hruska)

On 9/6/2017 6:45 PM, Andrea Faulds wrote:
> Hi everyone,
> 
> This is the tiniest of issues, but it's bugged me for a long time and 
> makes the HTML produced by PHP code less readable than it out to be. 
> Specifically, PHP ignores a newline immediately following a ?> tag. The 
> reason for this is, from what I recall, to prevent issues where 
> whitespace at the end of a PHP file is echoed before headers can be 
> sent. On UNIX in particular, all text files (should) end in a newline, 
> so this is a reasonable and necessary feature.
> 
> However, for ?> tags anywhere that aren't right at the end of the file, 
> this is just a nuisance that makes for messy output. For example, HTML 
> output that should look like:
> 
> <table>
>      <tr>
>         <td>foo</td>
>         <td>bar</td>
>      </tr>
> </table>
> 
> May instead end up looking something like:
> 
> <table>    <tr>
>         <td>foo</td>       <td>bar</td>
>      </tr></table>
> 
> Of course, HTML doesn't matter so much, it'll render the same to the 
> end-user. However, for outputting e.g. plain text, newlines can be 
> significant, and so you have to insert an ugly and surprising extra 
> newline following a tag.
> 
> Would anyone object to me changing how PHP handles this so that only the 
> final ?> tag consumes its following newline, and only at the end of the 
> file?
> 
> Thanks!

I've noticed that over the years.  When I care, I'll either press enter 
an extra time or, more frequently, switch over to using pure echo 
statements for precise output control.  I don't think of this as a 
particularly significant issue.*

Alternatively, for the HTML case, it is possible to stream an output 
buffer and manipulate newlines through the TagFilterStream class:

https://github.com/cubiclesoft/ultimate-web-scraper

That particular class can process HTML at a rate of up to 1MB/sec even 
when using callbacks via its very efficient stream-based state engine. 
The extra overhead is minimal for prettifying HTML output.


* I'd personally rather see a suitable fix for Bug #73535 at this point. 
  It's been an open issue with a CVE assigned for almost 10 months.  It 
would be nice to see it triaged properly (e.g. the suggested fix 
applied) so that I can finally close that browser tab.  If you have the 
spare time for newline output adjustments, I'd love to see that extra 
energy sunk into fixing existing security vulnerabilities, especially 
those with CVEs and suggested solutions.  Just sayin'.  But you guys do 
whatever you want to do.

-- 
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/