We want to actually, you know, use the full HTTP spec. That's kinda important for doing anything with web services, sending or receiving, although right now we're focused on receiving for the Web Services initiative. We also want to avoid lots and lots of globals and superglobals, since those make testing, debugging, and mocking difficult to impossible.
Doing that in a sane way takes a lot of work to build a wrapper library. We don't want to spend that kind of time.
Based on the research and discussion here, we are going to integrate the Symfony2 HttpFoundation library. That is, we're going to just bundle it with core, along with the Symfony2 autoload routines to make the code available. In practice it will almost always be accessed via the Context object, but that's for a later patch.
There's a number of follow-up issues that could benefit from this move:
#335411: Switch to Symfony2-based session handling (Use HttpFoundation's session handling, at least in part)
#1260864: Convert global $user to a context key (The user object is tightly coupled to the session handling, which is arguably itself a problem...)
#1260918: Convert language globals to contexts (HttpFoundation offers nice HTTP language negotiation capabilities)
#1279942: Create Http context handler (Offer much more robust Http information to core code via context)
#1279944: Eliminate arg() in favor of context (We can kill arg()!!!!)
User interface changes
None, this is an API/framework addition only.
For the moment, none. We still need to build the context integration atop it. Eventually, though, any use of $_GET, $_POST, etc. will be considered a bug, and all HTTP information will be accessed via context.
Original report by Crell
As previously discussed, it would be nice to have a more robust HTTP library available to us than the superglobals. Really, those suck. It would be great if it were incoming and outgoing, but at minimum we want a good, ext/filter-using library for the incoming HTTP request.
nihiliad and I had discussed using the PECL HTTP library in the past. While that would be an unpleasant dependency, if we could port it to user space that would be a great way to have our cake and eat it too. Just drop in the PECL module instead of the PHP-space version and poof, more of Drupal is in C code.
However, on further investigation that port would be considerably more work than we thought. Enough that it's probably not worth the effort. So we should investigate other possible user-space libraries we can employ so that we do not need to write it from scratch.
Zend 2 apparently has an HTTP library that doesn't suck and is worth looking into, but others may exist. If we use the Zend one it's likely we'd need to tweak it a little to remove any dependencies, and get a license exemption since it's essentially BSD-licensed.