[RFC] ServerRequest and ServerResponse objects

8 years ago by Paul Jones — view source

unread

Hi all,

I have prepared an RFC on server-side request and response objects:

wiki.php.net/rfc/request_response

This extension provides server-side request and response objects for PHP. These are not HTTP message objects proper. They are more like wrappers for existing global PHP variables and functions, with some limited additional convenience functionality.

This extension defines two classes in the global namespace:

ServerRequest, composed of read-only copies of PHP superglobals and some other commonly-used values, with methods for adding application-specific request information in immutable fashion.
ServerResponse, essentially a wrapper around (and buffer for) response-related PHP functions, with some additional convenience methods, and self-sending capability.

The extension is available as a PECL package for installation and testing at:

pecl.php.net/package/request

I want to point out that I am not the author of the C code for this extension; John Boehr has done the work there, and I appreciate it a great deal.

When I originally raised this topic in September, there were some questions left unanswered from Rowan Collins; I'll try to address them below.

Rowan asked why this would need to be implemented to as an extension or built into core: "Does it provide functionality that is hard to implement in a userland library?"

It does. Among other things, making public read-only properties is difficult and hackish in userland. Making them remain read-only when a parent class is extended is (as far as I can tell) impossible. Both of those aspects figure prominently in ServerRequest.

Rowan also asked: "You mention that it is not just an HTTP wrapper, but although you mention researching other frameworks, I can't see any reference to PSR-7. What do you see as the relationship between your proposal and that standardisation effort?"

While PSR-7 is not a framework, I get your point. ;-) For what it's worth, I was a sponsor on that proposal, so I'm relatively familiar with its history and purpose.

I see the relationship as complementary. Those who want something that matches a formal HTTP model more closely can use one of the two popular PSR-7 implementations, or write their own. Or they can use pecl_http, for that matter, which I think PSR-7 ends up mimicking in significant ways.

Those who want something that more closely matches core PHP functionality, or the way-of-working presented by many extant frameworks and libraries, might find this extension more in line with their needs. I certainly do.

Finally, Rowan brought this up: "Why is [ServerRequest] property-only, but [ServerResponse] method-only? The asymmetry feels awkward to me."

I get why that would be. It's really an outgrowth of the asymmetry that already exists in PHP: $_GET, $_POST, et al. are properties representing the request, whereas header(), setcookie(), et al. are all functions for sending a response.

Having said that, practical use of ServerRequest the intervening time has given rise to some methods for application-related convenience. The methods withUrl(), withInput(), and the various withParams() methods allow changing of immutable public properties on a clone of ServerRequest.

(As a side note, immutability here is relatively strict. ServerRequest allows only null, scalar, and array values in these cases, and recursively checks that arrays themselves have only null, scalar, and array values.)

I know it's a busy time of year for everyone, so I expect this discussion to go on longer than two weeks.

This is not a language change; my understanding is that means a simple majority vote is needed to pass.

Thanks in advance for your comments and criticism.

-- pmj

8 years ago by Andrea Faulds — view source

unread

Hi,

Since the $get, $post etc. properties are the same as $_GET and $_POST,
does that mean they retain the same name mangling scheme? (See "https
colon slash slash wiki dot php dot net slash rfc slash
on_demand_name_mangling"* for details of that.)

It would be nice to fix that eventually, and this would be a place where
we could do so without breaking backwards-compatibility.

*Sorry about spelling it out like that. Apparently, the mail server
thinks this link is spam.

--
Andrea Faulds
https://ajf.me/

8 years ago by Paul M.Jones — view source

unread

On 2016-12-23 21:43:56 +0000, Andrea Faulds said:

Hi,

Since the $get, $post etc. properties are the same as $_GET and $_POST,
does that mean they retain the same name mangling scheme? (See "https
colon slash slash wiki dot php dot net slash rfc slash
on_demand_name_mangling"* for details of that.)

It would be nice to fix that eventually, and this would be a place
where we could do so without breaking backwards-compatibility.

*Sorry about spelling it out like that. Apparently, the mail server
thinks this link is spam.

(I'm trying to post via Usenet, since mailing list messages on this
thread have not come through to me. This is a copy of an email I sent
to Andrea directly.)

I presume the answer is "yes" because the properties are populated
directly from $_GET and $_POST.

If there is some patch that might be applied to un-mangle things, and
you think this is the place to do it, I cannot imagine John Boehr or I
would refuse a patch.

-- pmj

8 years ago by Paul Jones — view source

unread

Hi all,

Today marks two weeks since this RFC was introduced. As I said at the start, it's the holidays, so I expect to keep the discussion period open for longer than two weeks, but I am surprised at how little discussion there has been.

I find it hard to imagine that all criticisms have been raised, and that the remainder of the RFC is otherwise unobjectionable. So, if there are further questions, please let me know!

--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

8 years ago by Adam Baratz — view source

unread

Today marks two weeks since this RFC was introduced. As I said at the
start, it's the holidays, so I expect to keep the discussion period open
for longer than two weeks, but I am surprised at how little discussion
there has been.

The email introducing the RFC missed my inbox somehow. I don't see it in
the archive either, even though it's in the newsgroup. I'm wondering if
there was a glitch somewhere.

I was able to find your blog post introducing the RFC:
http://paul-m-jones.com/archives/6494

For anyone else that missed the original message, the post has a link to
the original message:
http://news.php.net/php.internals/97461

One request: could you update the RFC list[1] so this one is in the "under
discussion" section? Makes discovery easier. There's an RFC howto[2] that
should cover this.

Looking forward to taking a look at this one. This is definitely a topic of
interest with the engineers I work with.

Thanks,
Adam

[1] https://wiki.php.net/rfc
[2] https://wiki.php.net/rfc/howto

8 years ago by Paul Jones — view source

unread

One request: could you update the RFC list[1] so this one is in the "under discussion" section? Makes discovery easier. There's an RFC howto[2] that should cover this.

Thanks for pointing that out. Done!

--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

8 years ago by Marco Pivetta — view source

unread

Hi Paul,

Hi all,

Today marks two weeks since this RFC was introduced. As I said at the
start, it's the holidays, so I expect to keep the discussion period open
for longer than two weeks, but I am surprised at how little discussion
there has been.

I find it hard to imagine that all criticisms have been raised, and that
the remainder of the RFC is otherwise unobjectionable. So, if there are
further questions, please let me know!

As mentioned before, the fact that the RFC proposes yet another (XKCD

request/response API simply increases fragmentation within the
ecosystem.

This is not useful, especially now that a common interoperability interface
for request and response that works quite decently and is getting traction
(PSR-7) exists.

Bundling the interface is no biggie, so I suggest steering away and going
that way, or else you are just adding API that everyone would just need to
build wasteful adapters for.

There are several technical issues too:

A magic constructor that fetches data from global state: add a factory
for that, leave the constructor open for modifications or new instantiation
ways, or make it private.
Magic read-only properties that go against the language semantics: make
'em accessors, or do whatever you want, but don't invent new language
semantics just for your own extension.
A series of non-exhaustive properties that give some "helper" API to see
if it's XHR or not, violating basic SRP. Are you abstracting a request or
what you want to do with the request? You can define separate utility
functions for that. Yes, functions.
As per current API, I'd expect the ctor to throw an exception when used
outside the web SAPI context
You use the with prefix for setting values, while you know exactly
that with was used to differentiate from a mutable and a non-mutable API
in the existing request abstractions: this makes things confusing again
There's no interface for these classes, and they are not marked as
final, as far as I can see. This means that users will extend them (unwise
choice), and with that they will have a class with reflection bits in the
extension (extremely bad idea!). An interface and final are needed here.

Anyway, this is just a partial review of what I got to read with a few
minutes of time, yet loads of issues are evident.

I am obviously defensive and biased here, but if something new is being
designed for inclusion in php-src, and it has to reach millions of
developers, it better be reeeeeealli good. The issues above are just the
tip of the iceberg, and many developers obviously didn't use nor try this
extension so far.

IMO needs another few design iterations, and a lot more adoption, in order
to become interesting. Orrrrr you provide us with a factory for an
implementation of these concepts that already has adoption, traction and
extremely careful design behind it.

Greets,

Marco Pivetta

8 years ago by Joe Watkins — view source

unread

Afternoon Paul,

Indeed there was a huge glitch ... everywhere ... Leap seconds, and goblins
are worth considering, but also, the mail server recently switched software.

Since there seems to be links getting through now, I think we are through
the storm ... although nobody has directly told me that.

It would be safe to assume the only people that recv'd comms have replied
already.

It may be that you need to leave it two weeks from about now, to be on the
safe side. I'm sure that's not too different from what you were planning
anyway.

Cheers
Joe

[tag:ignore] http://news.php.net <- this is nonsense - me testing if this
will be delivered. [tag:ignore]

Hi Paul,

Hi all,

Today marks two weeks since this RFC was introduced. As I said at the
start, it's the holidays, so I expect to keep the discussion period open
for longer than two weeks, but I am surprised at how little discussion
there has been.

I find it hard to imagine that all criticisms have been raised, and that
the remainder of the RFC is otherwise unobjectionable. So, if there are
further questions, please let me know!

As mentioned before, the fact that the RFC proposes yet another (XKCD

request/response API simply increases fragmentation within the
ecosystem.

This is not useful, especially now that a common interoperability interface
for request and response that works quite decently and is getting traction
(PSR-7) exists.

Bundling the interface is no biggie, so I suggest steering away and going
that way, or else you are just adding API that everyone would just need to
build wasteful adapters for.

There are several technical issues too:

A magic constructor that fetches data from global state: add a factory
for that, leave the constructor open for modifications or new instantiation
ways, or make it private.

Magic read-only properties that go against the language semantics: make
'em accessors, or do whatever you want, but don't invent new language
semantics just for your own extension.

A series of non-exhaustive properties that give some "helper" API to see
if it's XHR or not, violating basic SRP. Are you abstracting a request or
what you want to do with the request? You can define separate utility
functions for that. Yes, functions.

As per current API, I'd expect the ctor to throw an exception when used
outside the web SAPI context

You use the with prefix for setting values, while you know exactly
that with was used to differentiate from a mutable and a non-mutable API
in the existing request abstractions: this makes things confusing again

There's no interface for these classes, and they are not marked as
final, as far as I can see. This means that users will extend them (unwise
choice), and with that they will have a class with reflection bits in the
extension (extremely bad idea!). An interface and final are needed here.

Anyway, this is just a partial review of what I got to read with a few
minutes of time, yet loads of issues are evident.

I am obviously defensive and biased here, but if something new is being
designed for inclusion in php-src, and it has to reach millions of
developers, it better be reeeeeealli good. The issues above are just the
tip of the iceberg, and many developers obviously didn't use nor try this
extension so far.

IMO needs another few design iterations, and a lot more adoption, in order
to become interesting. Orrrrr you provide us with a factory for an
implementation of these concepts that already has adoption, traction and
extremely careful design behind it.

Greets,

Marco Pivetta

8 years ago by Paul Jones — view source

unread

Hi Joe,

It may be that you need to leave it two weeks from about now, to be on the safe side. I'm sure that's not too different from what you were planning anyway.

I am totally fine with that; I'm not in any particular hurry. :-)

--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

8 years ago by Pierre Joye — view source

unread

On 2016-12-23 21:43:56 +0000, Andrea Faulds said:

Hi,

Since the $get, $post etc. properties are the same as $_GET and $_POST,
does that mean they retain the same name mangling scheme? (See "https colon
slash slash wiki dot php dot net slash rfc slash on_demand_name_mangling"*
for details of that.)

It would be nice to fix that eventually, and this would be a place where
we could do so without breaking backwards-compatibility.

*Sorry about spelling it out like that. Apparently, the mail server thinks
this link is spam.

(I'm trying to post via Usenet, since mailing list messages on this thread
have not come through to me. This is a copy of an email I sent to Andrea
directly.

Same here, not even the initial post. Could you post it again for the
record pls?

8 years ago by Paul Jones — view source

unread

On 2016-12-23 21:43:56 +0000, Andrea Faulds said:

Hi,

Since the $get, $post etc. properties are the same as $_GET and $_POST, does that mean they retain the same name mangling scheme? (See "https colon slash slash wiki dot php dot net slash rfc slash on_demand_name_mangling"* for details of that.)

It would be nice to fix that eventually, and this would be a place where we could do so without breaking backwards-compatibility.

*Sorry about spelling it out like that. Apparently, the mail server thinks this link is spam.

(I'm trying to post via Usenet, since mailing list messages on this thread have not come through to me. This is a copy of an email I sent to Andrea directly.

Same here, not even the initial post. Could you post it again for the record pls?

Can do. In fact, I'll resend the original under a slightly modified subject, and we can start the whole thing over. Sorry for the hassle.

--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

8 years ago by Joe Watkins — view source

unread

Sorry about the noise ... silly mail server ...

---------- Forwarded message ----------
From: Joe Watkins pthreads@pthreads.org
Date: Thu, Jan 5, 2017 at 7:55 AM
Subject: Re: [PHP-DEV] Re: [RFC] ServerRequest and ServerResponse objects
To: "Paul M. Jones" pmjones88@gmail.com
Cc: PHP internals internals@lists.php.net

Morning Paul,

Just to note that this does require a super majority.

It is the consensus of core maintainers that language change means anything
we have to continue to maintain if it's voted in, and this very much falls
into that category so a simple majority is not good enough.

Cheers
Joe

On 2016-12-23 21:43:56 +0000, Andrea Faulds said:

Hi,

Since the $get, $post etc. properties are the same as $_GET and $_POST,
does that mean they retain the same name mangling scheme? (See "https colon
slash slash wiki dot php dot net slash rfc slash on_demand_name_mangling"*
for details of that.)

It would be nice to fix that eventually, and this would be a place where
we could do so without breaking backwards-compatibility.

*Sorry about spelling it out like that. Apparently, the mail server
thinks this link is spam.

(I'm trying to post via Usenet, since mailing list messages on this thread
have not come through to me. This is a copy of an email I sent to Andrea
directly.)

I presume the answer is "yes" because the properties are populated
directly from $_GET and $_POST.

If there is some patch that might be applied to un-mangle things, and you
think this is the place to do it, I cannot imagine John Boehr or I would
refuse a patch.

-- pmj

--

To unsubscribe, visit:

8 years ago by Paul Jones — view source

unread

Morning Paul,

Just to note that this does require a super majority.

It is the consensus of core maintainers that language change means anything we have to continue to maintain if it's voted in, and this very much falls into that category so a simple majority is not good enough.

Understood, and thanks for the correction; I'll update the RFC (and my expectations) accordingly.

--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php