Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106261
To: internals@lists.php.net
References: <CAFPFaMLpZ=okschrpeH77AhZTHcvFBuPf1S1bXH6psxmvABK7g@mail.gmail.com>
 <28a9ccf7-f5be-eb1e-999a-06170beeed4b@gmail.com>
Message-ID: <f01bfbeb-01dc-f7c1-9d27-c7ed89e6bbf4@gmail.com>
Date: Tue, 23 Jul 2019 21:44:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <28a9ccf7-f5be-eb1e-999a-06170beeed4b@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
From: rowan.collins@gmail.com (Rowan Collins)

On 23/07/2019 21:22, Stanislav Malyshev wrote:
> Worse than that, code using short open tags deployed on a server using
> short_open_tag=0 will leak application code, because short open tags are
> silently ignored.


That's precisely what this RFC is intended to prevent.

By deprecating *and simply removing* the functionality, as implied by 
the previous RFC and initially implemented 
[https://github.com/php/php-src/pull/3975/], we would make such code 
immediately visible in PHP 8.0. This RFC removes that danger by amending 
the 8.0 behaviour to *explicitly detecting the tags* and throwing a 
ParseError.


> I am not sure how it is supposed to be an argument for making such
> behavior the default.


This RFC does not make anything the default that is not already; 
instead, it keeps the INI option as it was before, but changes its 
behaviour:

* In 7.4, the first use of "<?" with short_open_tag enabled raises a 
deprecation notice, but no other behaviour changes (as appropriate for a 
minor version)
* In 8.0, any use of "<?" with short_open_tag enabled throws a ParseError


Arguably, this could be considered a new implementation of the previous 
RFC, but it seems prudent to put it through the RFC process a second 
time to to avoid claims that it has bypassed the process in some way. 
Presumably if it doesn't achieve consensus, the previous plan would 
remain in effect.


Regards,

-- 
Rowan Collins
[IMSoP]