Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78510
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
Message-ID: <5453B114.6050400@gmail.com>
Date: Fri, 31 Oct 2014 15:56:04 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>	<5452B87B.5040009@garfieldtech.com>	<CAL+t6cHqQL-TaurfG887qxeyeVZPCxQcnY_BrtD-oHCS196HQw@mail.gmail.com>	<0B797CE3-7AFA-4330-9A98-D3CAFC6D6072@ajf.me> <CAL+t6cGanxv3dJONcECupw6Cfzup4s6At6tEcK_=Qagn67RNjw@mail.gmail.com>
In-Reply-To: <CAL+t6cGanxv3dJONcECupw6Cfzup4s6At6tEcK_=Qagn67RNjw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: rowan.collins@gmail.com (Rowan Collins)

Sherif Ramadan wrote on 31/10/2014 14:30:
> On Fri, Oct 31, 2014 at 5:25 AM, Andrea Faulds <ajf@ajf.me> wrote:
>
>>
>> This is no less of a backwards-compatibility headache. This still breaks
>> every PHP app I have ever written.
>>
>>
> To be perfectly clear, the default behavior would remain the same, so no
> PHP app you have ever written would break. The difference is, you would now
> be able to override any part of the default behavior by extending the
> HttpRequest class in your own code.
>
>
>>
>> No no, I'm not concerned about the contents of the interface. I'm
>> wondering what, exactly, this "interface" does? I don't see how a mere
>> interface would replace the superglobals, unless you want a superglobal
>> request object that anyone can swap out, which sounds like a bad idea.
>>
>>
> The interfaces do exactly what you see here. They specified which methods
> the HttpRequest and HttpResponse objects must implement.
>
> If you bothered to invest nearly as much time in reading the updates to the
> RFC as you did to making blanket statements and objections, you might
> actually find less reason to respond with objections so abruptly. The
> HttpRequest and HttpResponse classes are intended to provide a central
> place for message handling behaviors and their properties can be used to
> describe these behaviors.
>
> So, if you wanted to support a $_PUT superglobal, rather than adding one to
> the language, you can simply add the behavior to do the processing of PUT
> requests in your HttpRequest class, by extending HttpRequest and defining
> how PUT variables are handled there.

I think the piece that's missing is how exactly these interfaces would 
interact with core, or rather with the SAPIs which handle the actual 
transfer of HTTP requests and responses.

Say I write a class "AwesomeHTTPReceive implements HttpMessageReceive", 
what do I then do with this class in order for it to perform any actions?

Presumably there will need to be some mechanism where I can register 
this so that it is passed the actual data from the PHP SAPI?

In order to actually replace the default behaviour, this would need to 
be an ini setting, since no PHP code can run before the default 
superglobal behaviour occurs. Alternatively, it could be repeatable, by 
having some global function like populate_http_message_object( new 
AwesomeHTTPReceive  );

Similarly, there would need to be some mechanism for tying up the 
response object to the HTTP response to be issued by the SAPI, with some 
way for existing functions such as header() to interact with it 
appropriately.
-- 
Rowan Collins
[IMSoP]