sabre/http 3.0.0 release

We just released sabre/http 3.0.0.

We introduced several API breaking changes, so a major version change was warranted.

In particular, we modified the API to be closer to the draft version of psr/http.

psr/http is an upcoming standard for PHP development that should unify how we represent HTTP requests and responses in PHP.

There were several good ideas in this spec, in particular how HTTP headers are treated, especially when there are multiple headers with the same name, which is something sabre/http dealt poorly with (not at all).


  • Switched to a PSR-4 directory structure in lib/. This means all classes are now in lib/ instead of lib/Sabre/HTTP. This should not change a thing if you use the composer autoloader.
  • ::setHeaders() used to delete all previous http headers. This is no longer the case, new headers will simply be added to the existing ones.
  • Added ::getHeaderAsArray(). This method returns a single http header. If multiple headers with the same name were specified, each value will be an item in this array.
  • If you use ::getHeader(), and there were more than 1 http header with that name, we now concatenate all these headers with a comma (,).
  • ::addHeader() is new, and will preserve any existing header with that name. Instead, a second header will be added with the same name and a new value.
  • ::getHeaders() will now return each header value as an array.
  • The Client class now only follows redirects to HTTP and HTTPS urls.
  • Util::negotiate is deprecated, use Util::negotiateContentType instead.
  • The Client class can now follow redirects, even if the open_basedir setting is turned on.


If you are using sabre/http solely through sabredav, don't upgrade yet unless you are using the latest development version. If you use sabre/http independently, ensure that the relevant line in your composer.json looks like this:

"require" : {
    "sabre/http" : "~3.0.0"

And run composer update sabre/http afterwards.

No full psr/http compliance

I've matched the Request and Response to behave closer to the draft psr-http draft, but I didn't go all the way!

I strongly disapprove of how message bodies are represented. The PSR introduces an object to wrap PHP streams, that has severely less features, and due to its design it's incompatible with regular PHP streams and doesn't cover all our use cases. All under the pretense that PHP streams are hard to use.

Unless that's fixed, we'll not be fully supporting the specification, but it's still a draft, and there's still time.

Full changelog can be found on Github

Tags: http, release