Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi all, With the name change from `ServerRequest` to `SapiRequest` (et al.), discussion appears to have waned again. I believe all relevant questions have been answered and recorded at this point. Please review the updated RFC and implementation, and present any more questions/comments/concern

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Mike & Rowan & all, > On Mar 16, 2020, at 13:35, Mike Schinkel wrote: > >> Does anyone besides Rowan long for a different property name here? What are >> your suggestions, if any? > > I don't think this is important anymore if we call it Sapi or CGI. It was > only an issue IMO if if we we

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Mar 16, 2020, at 12:04 PM, Paul M. Jones wrote: > > Turning it over in my mind, I wonder if maybe a `Sapi` prefix would be a > better alternative along this path, especially since these objects relate to > the "interface between web server and PHP." >

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi all, > On Mar 14, 2020, at 10:18, Rowan Tommins wrote: > >> On 13/03/2020 20:36, Larry Garfield wrote: >> >>> * The RFC by design is trying to take the super-globals and make them OOPy; >>> no more, no less. >>> * The super-globals are not based on HTTP. They're based on CGI, which is >>>

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Mon, 16 Mar 2020 at 15:01, Paul M. Jones wrote: > That escalated quickly. :-) I'm going to reply to the only request for > clarification I could identify in this exchange -- if I missed others, > please let me know. > Hi Paul, Did you see the naming suggestion from Larry of CgiRequest/CGIR

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi all, That escalated quickly. :-) I'm going to reply to the only request for clarification I could identify in this exchange -- if I missed others, please let me know. >> Is the proposal really suggesting that a developer would still need to do >> `if(!empty($request->server[‘HTTPS’]) && $r

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On 13/03/2020 20:36, Larry Garfield wrote: * The RFC by design is trying to take the super-globals and make them OOPy; no more, no less. * The super-globals are not based on HTTP. They're based on CGI, which is sort of but not quite an HTTP request. * So... call it CgiRequest/CGIRequest? (I a

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Mar 13, 2020, at 4:25 PM, Stephen Reay wrote: > >> >> On 14 Mar 2020, at 02:59, Mike Schinkel wrote: >> >>> On Mar 13, 2020, at 3:23 PM, Stephen Reay wrote: >>> >>> Hi Mike, >>> >>> (I realise some of these points are possibly more addressed to Paul than >>> yourself, this is just whe

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Fri, Mar 13, 2020, at 9:55 AM, Paul M. Jones wrote: > > As with anything any of us has written, I’m not 100% sold on > > ‘Current{Request,Response}` even after writing it, but I think it’s at > > least a little more specific about what they do, when the namespace is > > taken into account. >

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On 14 Mar 2020, at 02:59, Mike Schinkel wrote: > >> On Mar 13, 2020, at 3:23 PM, Stephen Reay wrote: >> >> Hi Mike, >> >> (I realise some of these points are possibly more addressed to Paul than >> yourself, this is just where my brain went when I dug into what you were >> mentioning) >

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Mar 13, 2020, at 3:23 PM, Stephen Reay wrote: > > Hi Mike, > > (I realise some of these points are possibly more addressed to Paul than > yourself, this is just where my brain went when I dug into what you were > mentioning) (after responding to your reply I think I was commenting on the

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On 14 Mar 2020, at 01:40, Mike Schinkel wrote: > > >> On Mar 13, 2020, at 10:55 AM, Paul M. Jones wrote: >> >> One other alternative John & I contemplated was >> `Web{Request,Response,ResponseSender}` -- do you think that might be a >> reasonable alternative to HTTP, one that is "adjace

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Mar 13, 2020, at 10:55 AM, Paul M. Jones wrote: > > One other alternative John & I contemplated was > `Web{Request,Response,ResponseSender}` -- do you think that might be a > reasonable alternative to HTTP, one that is "adjacent" but not > overly-specific? That would net us: > > - WebR

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Stephen, Good stuff. You have stepped through my & John's earlier thought-process in much the same way that led to the current naming. > On Mar 13, 2020, at 09:23, Stephen Reay wrote: > >> On 13 Mar 2020, at 20:39, Paul M. Jones wrote: >> >> Do you have alternative suggestions or prefere

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On 13 Mar 2020, at 20:39, Paul M. Jones wrote: > > Hi Stephen, > >> On Mar 13, 2020, at 02:41, Stephen Reay wrote: >> >> I realise this is just bike shedding - the naming seems quite odd to me. >> >> This extension and the classes it provides are inherently about HTTP >> requests made t

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Stephen, > On Mar 13, 2020, at 02:41, Stephen Reay wrote: > > I realise this is just bike shedding - the naming seems quite odd to me. > > This extension and the classes it provides are inherently about HTTP requests > made to a php ‘server’, and the response it sends back - and yet it’s ca

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On 11 Mar 2020, at 23:36, Paul M. Jones wrote: > > Hi all, > > Conversation on this RFC seems to have diminished. As far as I know, I have > answered all criticisms/concerns/complaints one way or another. > > So if there are no more questions, and there is no objection, I will plan to >

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi all, > On Mar 11, 2020, at 11:36, Paul M. Jones wrote: > > Conversation on this RFC seems to have diminished. As far as I know, I have > answered all criticisms/concerns/complaints one way or another. FWIW, I have updated the Q&A points based on new discussion over the past day or so. The

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Arvids, > On Mar 11, 2020, at 16:22, Arvids Godjuks wrote: > > I took a deeper look into the GitHub repo and it answered a few questions - > RFC just didn't give any examples of usage/instantiation and how you can > make a new object. I was thinking it was a read-only global type object > tha

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Sat, 7 Mar 2020 at 23:50, Paul M. Jones wrote: > Hi Arvids, > > > On Mar 5, 2020, at 05:19, Arvids Godjuks > wrote: > > > > one question I do have here is about how PHP-PM process manager will be > > able to interact with this layer? > > Cause right now it does rewrite the $_SERVER variable f

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi all, Conversation on this RFC seems to have diminished. As far as I know, I have answered all criticisms/concerns/complaints one way or another. So if there are no more questions, and there is no objection, I will plan to call the vote on this proposal some time tomorrow or Friday. Thanks t

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Arvids, > On Mar 5, 2020, at 05:19, Arvids Godjuks wrote: > > one question I do have here is about how PHP-PM process manager will be > able to interact with this layer? > Cause right now it does rewrite the $_SERVER variable for each incoming > request for its child processes that handle the

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Peter, Thanks for the detailed critique. I'm not sure I can remedy everything you've pointed out, but even so ... > On Mar 5, 2020, at 03:00, Peter Bowyer wrote: > > I expect to vote "no". My thoughts are: > > 1. The chosen API. We have an OO approach, but headers and query parameters > ar

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Rowan, > On Mar 4, 2020, at 17:13, Rowan Tommins wrote: > >> On 04/03/2020 20:01, Paul M. Jones wrote: >> >> This RFC, in contrast, does not attempt to model HTTP messages. It does not >> attempt to discard previous ways of working. Instead, it proposes a more >> object-oriented representa

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Fri, 28 Feb 2020 at 16:25, Paul M. Jones wrote: > Hi everyone, > > All outstanding issues on this RFC appear to be resolved one way or > another. With that in mind: > > Are there any members here who currently expect to vote "no", who have not > yet chimed in? I'd like to hear your criticisms

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Fri, 28 Feb 2020 at 15:25, Paul M. Jones wrote: > Are there any members here who currently expect to vote "no", who have not > yet chimed in? I'd like to hear your criticisms and objections, so I can at > least attempt to resolve your concerns. > I expect to vote "no". My thoughts are: 1. Th

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On 04/03/2020 20:01, Paul M. Jones wrote: This RFC, in contrast, does not attempt to model HTTP messages. It does not attempt to discard previous ways of working. Instead, it proposes a more object-oriented representation of functionality that already exists in PHP, honoring that previously-ex

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Dan, Thanks for taking the time to bring up your concerns. While I don't expect to change your mind (nice though that would be!) perhaps other readers here will find my counter-positions useful. > On Mar 3, 2020, at 16:58, Dan Ackroyd wrote: > > Paul M. Jones wrote: > >> Are there any m

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Tue, Mar 3, 2020, at 4:58 PM, Dan Ackroyd wrote: > Paul M. Jones wrote: > > > Are there any members here who currently expect to vote "no", > > The only reason for doing this as C code appears to be make it have > read-only properties. This is a hack that would confuse a lot of > developers,

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Paul M. Jones wrote: > Are there any members here who currently expect to vote "no", The only reason for doing this as C code appears to be make it have read-only properties. This is a hack that would confuse a lot of developers, and instantly be added to most lists of "how PHP is bad". I reall

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi everyone, All outstanding issues on this RFC appear to be resolved one way or another. With that in mind: Are there any members here who currently expect to vote "no", who have not yet chimed in? I'd like to hear your criticisms and objections, so I can at least attempt to resolve your conc

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Feb 27, 2020, at 12:52 PM, Paul M. Jones wrote: >> On Feb 27, 2020, at 11:27, Rowan Tommins wrote: >> On Thu, 27 Feb 2020 at 17:06, Paul M. Jones wrote: At the risk of being the messenger that gets shot, I feel like that horse is dead. And beating it more won't revive it, or make it any

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Rowan, > On Feb 27, 2020, at 11:27, Rowan Tommins wrote: > > On Thu, 27 Feb 2020 at 17:06, Paul M. Jones wrote: > >> We spoke of this before; quoting myself from >> ... >> >>> I don't *expect* anything from existing published library authors; h

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Thu, 27 Feb 2020 at 17:06, Paul M. Jones wrote: > Hi Rowan, > > > On Feb 27, 2020, at 10:57, Rowan Tommins > wrote: > > > > you seem to be happy to just put it out there and see > > Perhaps it was not your intent, but even so: please don't put words in my > mouth. We spoke of this before; quo

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Rowan, > On Feb 27, 2020, at 10:57, Rowan Tommins wrote: > > you seem to be happy to just put it out there and see Perhaps it was not your intent, but even so: please don't put words in my mouth. We spoke of this before; quoting myself from ...

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Thu, 27 Feb 2020 at 15:55, Paul M. Jones wrote: > > Why not hope that ReactPHP and others will want to use this object, > > precisely because it avoids them having to roll their own implementations > > of things? > > Like I said earlier: if React ends up wanting to use ext/request, with its >

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Rowan, > Why not hope that ReactPHP and others will want to use this object, > precisely because it avoids them having to roll their own implementations > of things? Like I said earlier: if React ends up wanting to use ext/request, with its tradeoffs, of course I would think that's great. Bu

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Thu, 27 Feb 2020 at 02:43, Paul M. Jones wrote: > > Recreating that functionality in userland is non-trivial, but is > essential for several use cases, e.g. an event-based server like ReactPHP, > or a test using a saved request body as a fixture. > > > > If both content types (application/x-ww

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Feb 26, 2020, at 14:12, Rowan Tommins wrote: > > On 26/02/2020 19:57, Paul M. Jones wrote: > >> Do you mean something like this in the ServerRequest constructor? >> >> ... > > That's the easy part, yes; the harder part is this: > > ... Yes, that would definitely be the harder part.

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Feb 26, 2020, at 1:55 PM, Rowan Tommins wrote: > > On Wed, 26 Feb 2020 at 16:42, Paul M. Jones wrote: > >> Your presumption is correct! And your point on trying for better names is >> well-taken -- though I think these are "expected" names, based on my >> research into existing implementat

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On 26/02/2020 19:57, Paul M. Jones wrote: I'm sorry, I'm still having trouble seeing what you're getting at. Do you mean something like this in the ServerRequest constructor? public function __construct(array $globals, ?string $content = null) { if ( ($globals['_

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Rowan, > On Feb 26, 2020, at 12:55, Rowan Tommins wrote: > > That's a reasonable justification. Just to check, are there other > implementations that have both of these names side by side, or do most > implementations have one or the other, but using this naming? My recollection is that they

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Wed, 26 Feb 2020 at 16:42, Paul M. Jones wrote: > Your presumption is correct! And your point on trying for better names is > well-taken -- though I think these are "expected" names, based on my > research into existing implementations. The most-common names are ... > > - the word "files" for

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Rowan, > On Feb 24, 2020, at 15:47, Rowan Tommins wrote: > > Hi Paul, > > I left this thread to settle a bit, because I felt we were going round in > circles a bit. I think there's some fundamental differences in outlook that > no amount of discussion is going to resolve, so I've trimmed t

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Paul, I left this thread to settle a bit, because I felt we were going round in circles a bit. I think there's some fundamental differences in outlook that no amount of discussion is going to resolve, so I've trimmed this reply to the more specific points. On 20/02/2020 14:56, Paul M. J

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Johannes, Thanks for continuing to evaluate the proposal. Am I correct in thinking that your primary objection to ServerRequest is that it is read-only? If so, do you have other objections beyond that? And if not, please correct me. Meanwhile, to respond to your comments ... * * * > On Fe

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Wed, 2020-02-12 at 10:54 -0600, Paul M. Jones wrote: > Hi Johannes, > > > > What indication is there that this will be more successfull than > > the > > filter API? > > Fair question. While I can't say how successful (or not) ext/filter > has been, I *can* say that the proposal does not prese

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi all, > On Feb 12, 2020, at 12:20, Niklas Keller wrote: > >> A: It supports async exactly as much as PHP itself does. > > Not really. PHP has built-in stream_select / non-blocking streams, so > supports the tools required for async out of the box. Per private conversation with Niklas, he not

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Feb 20, 2020, at 18:42, Mike Schinkel wrote: > >> On Feb 20, 2020, at 10:26 AM, Paul M. Jones wrote: >> >> One of the "open questions" on this RFC is: are the class names >> ServerRequest, ServerResponse, and ServerResponseSender "good enough" for >> our purposes, or are there names t

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi all, Off-list discussion with some vendors and consumers indicates that adoption and migration might be eased by the following changes to ServerResponseInterface: - Add the following methods: - `getHeader(string $label) : ?string` - `hasHeader(string $label) : bool` - `getCookie(

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Feb 20, 2020, at 10:26 AM, Paul M. Jones wrote: > > One of the "open questions" on this RFC is: are the class names > ServerRequest, ServerResponse, and ServerResponseSender "good enough" for our > purposes, or are there names that are "better" in some qualitative way? > > Having said tha

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi all, One of the "open questions" on this RFC is: are the class names ServerRequest, ServerResponse, and ServerResponseSender "good enough" for our purposes, or are there names that are "better" in some qualitative way? The original thought was Request and Response, but I thought it might be

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Rowan, > On Feb 19, 2020, at 16:43, Rowan Tommins wrote: > >>> - When working out the details, what code should we be picturing using the >>> new classes? >> >> Not to be flippant, but: request-reading and response-writing code? > > The reason I keep trying to pin you down on this is that

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On 19/02/2020 20:21, Paul M. Jones wrote: Sell it to me! :) I don't do sales; occasionally I can present a good narrative. Maybe the narrative below will help. Hah! Fair enough. :) - When working out the details, what code should we be picturing using the new classes? Not to be flippant

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Rowan, Again, thanks for your time and effort in evaluating this proposal. > On Feb 18, 2020, at 14:21, Rowan Tommins wrote: > > - What's the sales pitch - what do YOU think is great about these classes? > > ... > > Sell it to me! :) I don't do sales; occasionally I can present a good na

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi all, Per the past several days of discussion, John Boehr and I have modified the proposal: - ServerRequest - The `$env` property mapping to `$_ENV` has been removed - The `$requestedWith` property mapping to `$_SERVER['HTTP_X_REQUESTED_WITH']` has been removed - The supergloba

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On 17/02/2020 15:55, Paul M. Jones wrote: I apologize in advance for the length of this email. I hate reading walls-of-text, but the answers are necessarily long. I have tried to break it up into bullets where possible for easier reading. No, thank you for taking the time to respond. I've ch

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Feb 18, 2020, at 08:10, Côme Chilliet > wrote: > > to me that means we also need an addContent method. I can see why we'd think that; it's symmetrical, if nothing else. Even so, none of the researched implementations have a method like that. As far as I can recall, they call have setC

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Le mardi 18 février 2020, 07:33:37 CET Paul M. Jones a écrit : > ... the output would be "b\n". As you say, setContent() replaces whatever > content is already in the ServerResponse. While the comparison for a single > echo is accurate, the comparison for multiple echoes would be: > > $conte

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Côme, > On Feb 18, 2020, at 03:24, Côme Chilliet > wrote: > > Le jeudi 13 février 2020, 09:16:49 CET Paul M. Jones a écrit : > >> Yeah, naming is one of the hard problems. I considered $query as an >> alternative property name for $get, but in the end, the `$_GET => $get` >> symmetry was

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Le jeudi 13 février 2020, 09:16:49 CET Paul M. Jones a écrit : > Yeah, naming is one of the hard problems. I considered $query as an > alternative property name for $get, but in the end, the `$_GET => $get` > symmetry was too great to ignore. If others here feel that $query is a better > name fo

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Rowan, I apologize in advance for the length of this email. I hate reading walls-of-text, but the answers are necessarily long. I have tried to break it up into bullets where possible for easier reading. > On Feb 15, 2020, at 19:37, Rowan Tommins wrote: > > On 15 February 2020 20:10:30 GM

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On 17 February 2020 00:45:26 GMT+00:00, Mike Schinkel wrote: >I think your latter points are orthogonal to this. And that you are >taking my advocacy for adding filtering to apply too literally to only >the specific implementations in filter_input(). Firstly, I deliberately didn't say "the filt

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Feb 16, 2020, at 6:34 PM, Rowan Tommins wrote: > > On 13/02/2020 20:31, Mike Schinkel wrote: >> If I had a vote I would vote I would enthusiastically vote for the RFC if it >> includes filter_input() functionality. But I would vote against this RFC if >> it omits filter_input() function

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On 13/02/2020 20:31, Mike Schinkel wrote: If I had a vote I would vote I would enthusiastically vote for the RFC if it includes filter_input() functionality. But I would vote against this RFC if it omits filter_input() functionality because it would mean another subsystem in core that does not

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Feb 15, 2020, at 3:01 AM, Larry Garfield wrote: > > Data point: > > In PSR-7, the names used are: > > - queryParams: The query string values. > - parsedBody: The body of the message, converted to a meaningful value. If > the request type is a form, then it MUST be equivalent to $_POST. I

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On 15 February 2020 20:10:30 GMT+00:00, "Paul M. Jones" wrote: >Hi all, > >> On Feb 15, 2020, at 02:01, Larry Garfield >wrote: >> >> ... is this proposal intended to supplant HttpFoundation and PSR-7 >... ? > >This is question is answered in the RFC introduction You've cut Larry's question in

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi all, > On Feb 15, 2020, at 02:01, Larry Garfield wrote: > > ... is this proposal intended to supplant HttpFoundation and PSR-7 ... ? This is question is answered in the RFC introduction; quoting from there: The SQLite “about” page says, “Think of SQLite not as a replacement for Orac

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Fri, Feb 14, 2020, at 10:47 AM, Benjamin Morel wrote: > > > > What about $query and $body? That would be closer to the terminology > > used in HTTP RFCs. > > > > The problem is that $body is typically used to get the raw message body as > a string or stream. > I was thinking more something al

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi all, > On Feb 14, 2020, at 10:47, Benjamin Morel wrote: > >> >> What about $query and $body? That would be closer to the terminology >> used in HTTP RFCs. > > > The problem is that $body is typically used to get the raw message body as > a string or stream. > > I was thinking more somethi

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> > What about $query and $body? That would be closer to the terminology > used in HTTP RFCs. The problem is that $body is typically used to get the raw message body as a string or stream. I was thinking more something along the lines of $bodyParams, which is more verbose but leaves no ambiguity

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Fri, Feb 14, 2020 at 5:47 PM Paul M. Jones wrote: > > - rename $get to $query, populating it from `$globals['_GET']`, on the basis > stated above > - rename $post to $input, populating it from `$globals['_POST']`, on the > basis that it typically relates to the parsed form of php://input Wh

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> > Having said that, we are willing to revisit that naming decision if > there's support for doing so. Perhaps: > - rename $get to $query, populating it from `$globals['_GET']`, on the > basis stated above > - rename $post to $input, populating it from `$globals['_POST']`, on the > basis that it t

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Côme & Niklas, > On Feb 13, 2020, at 04:52, Côme Chilliet > wrote: > > Le mercredi 12 février 2020, 19:20:56 CET Niklas Keller a écrit : > >> Naming >> >> I think we shouldn't take over the naming of the super globals, e.g. >> $_GET really contains the query parameters and has nothing to d

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Feb 13, 2020, at 1:34 PM, Paul M. Jones wrote: > > Hi Mike, > > Thanks for your continued evaluation of the RFC. > >> Take a look at WordPress. It does a lot of "fixup" to $_SERVER` variables — >> to deal with badly implemented web servers — to ensure all known variables >> have a value

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Mike, Thanks for your continued evaluation of the RFC. > Take a look at WordPress. It does a lot of "fixup" to $_SERVER` variables — > to deal with badly implemented web servers — to ensure all known variables > have a value and that the format of the value is consistent. > > ... > > An

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Ruud, > On Feb 13, 2020, at 00:45, Ruud Boon wrote: > > Hi! > > I really like this RFC. Glad to hear it! > In the the RFC I see that $content will return php://input using > file_get_contents on the fly. Can we add the possibility to get a reference > to the stream as well? By "get

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Niklas, > On Feb 12, 2020, at 12:20, Niklas Keller wrote: > > I think the request / response API is entirely fine being solved in > userland instead of in php-src. However, since you already made such a > proposal, I want to give some feedback: Re: userland, I gave a counterargument in my re

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi all, > On February 13, 2020 1:52 PM Côme Chilliet > wrote: > > > Le mercredi 12 février 2020, 19:20:56 CET Niklas Keller a écrit : > > Naming > > > > I think we shouldn't take over the naming of the super globals, e.g. > > $_GET really contains the query parameters and has nothing to do w

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Le mercredi 12 février 2020, 19:20:56 CET Niklas Keller a écrit : > Naming > > I think we shouldn't take over the naming of the super globals, e.g. > $_GET really contains the query parameters and has nothing to do with > GET or POST, so $request->getQueryParameter(...) would be a better > name.

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi! I really like this RFC. > On 12 Feb 2020, at 23:46, Paul M. Jones wrote: > > Hi Allen & Robin, > > Allen, you asked: > >> On Feb 12, 2020, at 15:27, AllenJB wrote: >> >> This might be more a "future scope" thing, but I would like to see a way to >> access the raw request body as part of

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Ben, > On Feb 11, 2020, at 10:58, Ben Ramsey wrote: > > Regarding the array of arrays for $accept* and $forwarded, what are your > thoughts on using value objects with properties, rather than arrays with keys? It's a fair suggestion, but I am not keen to expand the number of new declarati

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Allen & Robin, Allen, you asked: > On Feb 12, 2020, at 15:27, AllenJB wrote: > > This might be more a "future scope" thing, but I would like to see a way to > access the raw request body as part of this. Currently (as far as I know) the > only way is to open/read php://input, which isn't p

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Albert, > On Feb 11, 2020, at 11:22, Albert Casademont > wrote: > >> Am 11.02.20 um 13:42 schrieb Albert Casademont: >> >>> This is very interesting, thanks! >>> >>> Would it make sense to also add an INI setting to disable superglobals >>> and response functions? >> >> no because changin

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On 12/02/2020 18:20, Niklas Keller wrote: Type Safety I think the API should be type safe. Currently $request->get['key'] can be null | string | string[] | ... Most parameters only appear a single time, so a method returning the first parameter value or null could be used instead. I may be mis

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

This might be more a "future scope" thing, but I would like to see a way to access the raw request body as part of this. Currently (as far as I know) the only way is to open/read php://input, which isn't particularly intuitive in my opinion. AllenJB On 10/02/2020 16:18, Paul M. Jones wrote:

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Jan, > I like this proposal a lot, since it provides a clear, concise interface to > these commonly uses, yet inconveniant to use, existing functions and > variables without having to always use a full-featured userland library. Glad to hear the RFC is hitting the right notes! > Speaking

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Feb 12, 2020, at 1:20 PM, Niklas Keller wrote: > I think the request / response API is entirely fine being solved in > userland instead of in php-src. I want to disagree in support of this RFC. While is *has* been solved in userland, but it has been solved 25+ times in 25+ different incom

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> Hi Internals, > > After a couple of years of incubation, I am happy to offer a second version > of this RFC: > > https://wiki.php.net/rfc/request_response > > It proposes an object-oriented approach around request and response > functionality already existing in PHP, in order to reduce the gl

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Feb 12, 2020, at 7:47 AM, Paul M. Jones wrote: > > That is essentially what it does now; the difference is that you mimic the > $GLOBALS array at construction time, and the instance locks automatically: > >$request = new ServerRequest([ >'_GET' => ['foo' => 'bar'], >'_C

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Johannes, > What indication is there that this will be more successfull than the > filter API? Fair question. While I can't say how successful (or not) ext/filter has been, I *can* say that the proposal does not present extraordinary or dramatically different ways of working than PHP does c

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Mike, > I like this, a lot. ... In general I think this would definitely be a nice > enhancement to PHP, IMO. Thanks for saying! > I do have questions about ServerResponse. It is not clear how that interacts > with existing echo, header(), setcookie(), etc? You say it creates a buffer;

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Mark, > On Feb 10, 2020, at 11:02, Mark Randall wrote: > > I suspect this is a similar sentinment to the previous version, but I can > personally see no major benefit to having this as a core extension. > > I think the reality is that discussing it "on its own merits" is to > completely ig

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

On Tue, Feb 11, 2020 at 1:59 PM Reindl Harald (privat) wrote: > > > Am 11.02.20 um 13:42 schrieb Albert Casademont: > > This is very interesting, thanks! > > > > Would it make sense to also add an INI setting to disable superglobals > and > > response functions? > > no because changing basic lang

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

> On Feb 10, 2020, at 10:18, Paul M. Jones wrote: > > Hi Internals, > > After a couple of years of incubation, I am happy to offer a second version > of this RFC: > > https://wiki.php.net/rfc/request_response > > It proposes an object-oriented approach around request and response > function

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi Michał, Good to hear from you! (While writing this, I realized I made a couple of mistakes in the RFC examples related to CONTENT_LENGTH and CONTENT_TYPE that might have caused confusion; I have now fixed them.) > On Feb 10, 2020, at 10:46, Michał Brzuchalski > wrote: > > Hi Paul, > >

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Am 11.02.20 um 13:42 schrieb Albert Casademont: > This is very interesting, thanks! > > Would it make sense to also add an INI setting to disable superglobals and > response functions? no because changing basic language behavior that way is not helpful for code meant to run everywhere and not

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

This is very interesting, thanks! Would it make sense to also add an INI setting to disable superglobals and response functions? On Tue, Feb 11, 2020 at 10:34 AM Jan Schneider wrote: > > Zitat von Paul M. Jones : > > > Hi Internals, > > > > After a couple of years of incubation, I am happy to

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Zitat von Paul M. Jones : Hi Internals, After a couple of years of incubation, I am happy to offer a second version of this RFC: https://wiki.php.net/rfc/request_response It proposes an object-oriented approach around request and response functionality already existing in PHP, in ord

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

Hi, On Mon, 2020-02-10 at 10:18 -0600, Paul M. Jones wrote: > After a couple of years of incubation, I am happy to offer a second > version of this RFC: > > https://wiki.php.net/rfc/request_response What indication is there that this will be more successfull than the filter API? The filter API

  1   2   >