New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP Message Proposal (take 2) #244

merged 33 commits into from Jan 28, 2014
Jump to file or symbol
Failed to load files and symbols.
+719 −0
Diff settings


Just for now

@@ -0,0 +1,72 @@
HTTP Message Meta Document
1. Summary
The purpose of this proposal is to provide a set of common interfaces for HTTP
messages as described in [RFC 2616](
2. Why Bother?
This proposal presents an API for describing HTTP messages in PHP in a way
that is as simple as possible and does not limit functionality.
HTTP messages are used in a wide number of PHP projects-- both clients and
servers. PHP applications often can rely on specific packages and do not
require a means for utilizing arbitrary HTTP messages. Projects that need to
utilize HTTP messages but do not necessarily have a hard requirement on any
particular library often take one of the following approaches:
1. Create a very minimal implementation from scratch.
2. Force developers to use a specific HTTP client/server library that provides
HTTP message interfaces.
3. Create adapters for common HTTP message implementations.
While these are all valid approaches, this can lead to projects unnecessarily
bloating a their dependencies or projects needing to create redundant
[adapters for common libraries.](
It should be noted that the goal of this proposal is not to obsolete the
current interfaces utilized by existing PHP libraries. This proposal is aimed
at interoperability between PHP packages for the purpose of describing HTTP
3. Scope
## 3.1 Goals
* Provide the interfaces needed for describing HTTP messages.
* Keep the interfaces as minimal as possible.
* Ensure that the API does not impose arbitrary limits on HTTP messages. For
example, some HTTP message bodies can be too large to store in memory, so we
must account for this.
## 3.2 Non-Goals
* This proposal does not expect all HTTP client libraries or server side
frameworks to change their interfaces to conform. It is strictly meant for
* While everyone's perception of what is and is not an implementation detail
varies, this proposal should not impose implementation details. However,
because RFC 2616 does not force any particular implementation, there will be
a certain amount of invention needed to describe HTTP message interfaces in
5. People
### 5.1 Editor(s)
* Michael Dowling
### 5.2 Sponsors
* Phil Sturgeon (coordinator)
* Beau Simensen
### 5.3 Contributors
* Chris Wilkinson
Oops, something went wrong.
ProTip! Use n and p to navigate between commits in a pull request.