Research on two HTTP libraries

Me and Dave Hall (@skwashd) spent part of our weekends looking through the HTTP request handling code in both the Zend and Symfony frameworks. We may have been little bit biased by the good help from Lukas Smith (@lsmith77) of the Symfony community, but we've tried to be fair in the comparison of the 2 projects. We encourage feedback on our findings.

Assessment Criteria

We were guided by the assessment criteria discussed at the WSCCI meeting on 2 August 2011. The criteria was as follows:

• Dependencies
• Security
• Handling of request variables
• Handling and parsing of headers
• Handling of the request body
• Licensing and contribution terms

Secure by Default

Neither of the frameworks are “secure by default” as they take no extra steps to sanitize data. We don’t feel that this is a problem as we are dealing with the HTTP requests. The implementation of security controls should be done where security is a problem, such as the storage or presentation layers.

Concepts

Zend framework seems to be very big with an crazy array of different tools. But their HTTP Request component (links earlier in this thread is to their HTTP client) seems very simple in comparison (which might not be a good thing). All their component are loosly coupled, but as the Controller component is one of the foundations of their MVC architecture, it relies on it heavily,which we'll explore further down.

Symfony on the other hand, has a smaller array of tools, but has a richer HTTP Foundation. In fact, their whole framework seems very HTTP centric, all the way from HTTP Kernel and up. They've put a lot of effort into separating their components. They aren't loosely coupled, they are decoupled. All their components are in separate repositories and they are presenting and promoting them as stand-alone products. On top of this they have a community and culture of building distributions and other independent frameworks on top of their decoupled components. See Silex and the Content Management Framework initiative.

Zend

Code weight is around 50 KB. The Zend framework's HTTP component is fairly small and simple relatively to the rest of the framework.

Dependencies

Like most Zend classes the Http class depends on the Zend Config class to provide basic configuration information. Zend Uri is required for URL parsing.

In Zend's AbstractRequest class which the Http class extends, there are some MVC-related code which should concern us when it comes to being cleanly extensible. But from what we could tell it's not a hard dependency though. So it should still be possible to extend.

Request Variables

Zend provides (raw) access to GET, POST, COOKIE and SERVER.

Headers

Zend doesn't do any useful parsing of headers like Accept or Language, other than just returning the desired key [ref]. Interestingly it seems to only parse HTTP_* headers, and forgetting about CONTENT_TYPE, CONTENT_LENGTH, AUTHORIZATION etc. if Apache aren't used.

Zend only provides simple key retrieval for COOKIEs.

Body

Provides access to the content body as a string [ref].

Others

The Request component doesn't handle SESSION or FILES. These are handled by separate components [ref, ref].

HTTP client

A quite solid HTTP client is provided as a separate component [ref].

Licensing and Contribution Terms

Zend Framework is licensed under the terms of the new BSD license. All contributors to the ZF project are required to sign a Contributor Licensing Agreement, even for trivial patches. This could make it difficult for the Drupal community to contribute back to Zend.

Symfony

Code weight is around 180 KB. Symfony has better methods for mocking requests [ref, ref]. Essentially, they can easily do sub requests to other controllers in the system [example]. This is their internal ESI system! We found this very interesting.

Dependencies

The HTTP Foundation makes the assumption that you use its built in session handling. If we decide not to use it, we could work around it by extending the class and add a Drupal specific session handler.

Request variables

Symfony provides (raw) access to GET, POST, COOKIE and SERVER.

Headers

Symfony provides parsing of complex headers like Language and Accept [ref, ref]. It doesn't forget about CONTENT_TYPE, CONTENT_LENGTH and ATHORIZATION [ref], as opposed to Zend.

Symfony provides some extra parsing of COOKIE headers too [ref].

Body

Provides access to the content body, both as a string or as a file resource [ref].

Others

Symfony provides a really neat SESSION handling interface [ref], with a PDO implementation [ref].

Symfony provides some simple functionality to deal with FILE transfer. Nothing around multipart though, from what we found.

HTTP client

Symfony doesn't provide any type of HTTP client.

Licensing and Contribution Terms

Symfony is licensed under the terms of the MIT license. Some methods have been taken from Zend Framework, but this is clearly documented. The project appears to have an open contribution policy which allows any one to freely contribute to the code base. It’s done via pull requests on GitHub, like this: https://github.com/symfony/symfony/pull/1386

Conclusion

Both HTTP components seems to do the job quite well. But the Symfony HTTP Foundation is more self contained and provides a bit richer tools for parsing headers and such. Also, Symfony provides handling of SESSION and FILES as part of their HTTP Foundation. That could be interesting to think about while we're at it.

Here is the drupal.org issue on the matter: http://drupal.org/node/1178246