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

On 07/10/2013 18:19, Daniel Lowrey wrote:

You can't efficiently model an HTTP request with associative

arrays. Period. The fact is that for 99% of use cases, yes you can, and developers happily do so. Leaky abstraction is leaky. If this is truly an efficient model of the HTTP request then why do we fragment it out into $_SERVER and $_COOKIES and $_FILES and $_POST and $_GET and php://input? I don't know what your definition of "efficiently model" is, but it must be different from mine. Array Oriented Programming !== design.

Ah, OK, I was only really talking about $_POST and $_GET, since they were the topic of this thread. I'm not quite sure why breaking different aspects of the HTTP request into different interfaces is fundamentally a problem, but I agree that you can't model /all/ aspects of an HTTP request as associative arrays. To go through the relevant superglobals in turn: $_GET: The param=value&... format for query strings is so universal, whether or not generated by a form, that it can largely be taken for granted. Within that format, the only thing that can't be handled as a hash is a repeated key; PHP takes the approach that foo[]=bar always creates an array, and foo=bar never does, with later values "winning". This covers 99% of what people need to do with query strings. The mutability and globalness aren't great, but any method ->getQueryStringParam('foo') would be indistinguishable from ->getQueryStringHash()['foo'] $_POST: Deals with the two generally accepted form encodings for POST requests, in a way that matches $_GET, but while allowing programmers to distinguish the two rather than clobbering thm into one array. $_COOKIE: Again, the structure of the Cookie: header in PHP is fundamentally a set of name=value pairs, making a hash a perfectly reasonable structure. The asymmetry with set_cookie() is unfortunate, although some asymmetry is inevitable given the underlying headers. At least it's better than the abomination that is document.cookie :P $_REQUEST: This is an unnecessary bit of redundancy, although it reminds me that if you do want to merge query string and posted data, having them as hashes is very handy. $_FILES: A bit awkward. I can guess the argument for splitting it from $_POST, but it's crying out for a more OO representation of the individual entries. They're still name-value pairs though. $_SERVER: This is the only one that really doesn't work at all. I was going to mention it earlier, but didn't want to drift off-topic in my earlier messages. It's an awful jumble of HTTP headers, PHP-specific data, and arbitrary environment variables which happen to have come through from the SAPI. It contains the requested URL in various parts with inconsistent names, and I refuse to go near it without a sane wrapper class. HTTP headers are fundamentally key-value pairs, although they can repeat, so more like key -> array of values. Environment variables are key-value too. The rest of it, along with file_get_contents('php://input'), is odds and ends that need a separate abstraction. Well, that's the way I see it anyway. The superglobals themselves aren't great, but outside of APIs (which will generally involve a bit of framework-y-ness anyway) the associative array interface is what most people will end up wanting anyway. Regards, -- Rowan Collins [IMSoP]