Re: HTTP supergloblas and request body/query (was: Parsing PUT data)

On 10/7/13 10:03 AM, Rowan Collins wrote:

Hi All, Johannes Schlüter wrote (on 07/10/2013):

Why replace something? Are there flaws which can't be fixed? Adding too many ways to do the same thing is confusing for everybody. If you want it "object oriented" or such frameworks do great things. The language should offer a good foundation. (It is my strong believe that we should move as many "high level" things as possible in libraries)

I think this is a strong point: PHP as it is now is a long way from being usable as a modern framework in its own right, and building a framework-like API for this kind of functionality may open a bigger can of worms than was intended. Zend, Symfony, et al have a massive head-start on any kind of "PHP native framework". Rather than trying to build the framework logic into the core, how about exposing the functionality currently in core to user-space so that frameworks can wrap it more efficiently? Looking around, we currently have the slightly awkward parse_str for query strings and application/x-www-form-urlencoded bodies; I imagine there's something in pecl_http for multi-part/form-data, but I'm not familiar with that extension, and it's not part of core. If the internal implementations were decoupled from the population of $_POST as a consistent set of functions, frameworks could simply wrap them alongside custom parsers such as JSON (with appropriate options) or XML (restricted to some framework-defined schema). This also allows for simulated requests, unit testing, etc, and passing in file_get_contents('php://input') should allow parsing any request body. If this was done as some consistent "serialization/deserialization" module, it could expose the session serialization formats as well, replacing the horrible environment-clobbering of session_decode(). Regards,

The Framework Interoperability Group has been discussing a unified request/response spec on and off for a while. There's definite interest in having one, especially if it can support HTTP clients (Guzzle and Buzz, etc.) with the same interface as the main PHP process. I'd actually recommend those who are interested work on it over there, let it happen in PHP user space, and then later backport it to C code if it seems to work out well. --Larry Garfield