Hey all,
In the PR for adding HTTP/2 Server Push support to curl, Julien raises the
question of adding tests for this feature [1].
This is currently very difficult.
While we have the cli-server, it currently only supports HTTP/1.x. This
means we need another httpd to test against that supports both HTTP/2 and
server push — currently that means something like a node script using
node-http2, or nghttpd (both of which have been what I tested the patch
against).
While I have a docker container for testing, this obviously doesn't fit
well into make tests
. The simplest solution along those lines is to check
for node
and run a node daemon, but it doesn't scale well to lots of use
cases, and is purely for testing.
However, Rasmus raised the possibility of adding HTTP/2 support to the
cli-server [2], and (someone? @php-pulls) suggested we pull in a third
party lib to do the heavy lifting [3].
My recommendation would be to use libnghttp2 [4] which curl also uses —
however, as this adds a new dependency, I think it should be optional (e.g.
--with-nghttp2-dir=[PATH]), with it falling back to the current HTTP/1.x
implementation.
We could also add a flag (e.g. --[no-]http2) on the CLI for
enabling/disabling it — this would be helpful for testing HTTP/2 client
fallback when it's not supported.
This is a much more useful tool than relying on node for make tests, and
allows us to test adding HTTP/2 support to ext/curl, the HTTP stream (which
could also use libnghttp2…), userland HTTP/2 clients, pecl_http (if that's
still a thing), etc.
Now, I don't think I have the ability to achieve this, but I'm willing to
give it a go.
At the very least, I'm more than happy to write up the RFC and work with
someone on this.
Thoughts?
- Davey
[1] https://github.com/php/php-src/pull/1692#issuecomment-166935246
[2] https://github.com/php/php-src/pull/1692#issuecomment-166972540
[3] https://github.com/php/php-src/pull/1692#issuecomment-166997465
[4] https://nghttp2.org
Hey all,
In the PR for adding HTTP/2 Server Push support to curl, Julien raises the
question of adding tests for this feature [1].This is currently very difficult.
While we have the cli-server, it currently only supports HTTP/1.x. This
means we need another httpd to test against that supports both HTTP/2 and
server push — currently that means something like a node script using
node-http2, or nghttpd (both of which have been what I tested the patch
against).While I have a docker container for testing, this obviously doesn't fit
well intomake tests
. The simplest solution along those lines is to
check
fornode
and run a node daemon, but it doesn't scale well to lots of use
cases, and is purely for testing.However, Rasmus raised the possibility of adding HTTP/2 support to the
cli-server [2], and (someone? @php-pulls) suggested we pull in a third
party lib to do the heavy lifting [3].My recommendation would be to use libnghttp2 [4] which curl also uses —
however, as this adds a new dependency, I think it should be optional
(e.g.
--with-nghttp2-dir=[PATH]), with it falling back to the current HTTP/1.x
implementation.We could also add a flag (e.g. --[no-]http2) on the CLI for
enabling/disabling it — this would be helpful for testing HTTP/2 client
fallback when it's not supported.
I would prefer the second as http2 will be the standard to come. I'm not
even sure disabling it is worth it, but as you mention some may not want
the external library.
This is a much more useful tool than relying on node for make tests, and
allows us to test adding HTTP/2 support to ext/curl, the HTTP stream
(which
could also use libnghttp2…), userland HTTP/2 clients, pecl_http (if that's
still a thing), etc.
Agreed.
Now, I don't think I have the ability to achieve this, but I'm willing to
give it a go.At the very least, I'm more than happy to write up the RFC and work with
someone on this.Thoughts?
- Davey
[1] https://github.com/php/php-src/pull/1692#issuecomment-166935246
[2] https://github.com/php/php-src/pull/1692#issuecomment-166972540
[3] https://github.com/php/php-src/pull/1692#issuecomment-166997465
[4] https://nghttp2.org
Hi Davey,
Davey Shafik wrote:
However, Rasmus raised the possibility of adding HTTP/2 support to the
cli-server [2], and (someone? @php-pulls) suggested we pull in a third
party lib to do the heavy lifting [3].My recommendation would be to use libnghttp2 [4] which curl also uses —
however, as this adds a new dependency, I think it should be optional (e.g.
--with-nghttp2-dir=[PATH]), with it falling back to the current HTTP/1.x
implementation.We could also add a flag (e.g. --[no-]http2) on the CLI for
enabling/disabling it — this would be helpful for testing HTTP/2 client
fallback when it's not supported.
Hmm, this would mean a new dependency, and more potential complexity.
I'm not sure if HTTP/2 justifies it.
Also, don't all the major client implementations of HTTP/2 require TLS?
Or is localhost given a free pass?
This is a much more useful tool than relying on node for make tests, and
allows us to test adding HTTP/2 support to ext/curl, the HTTP stream (which
could also use libnghttp2…), userland HTTP/2 clients, pecl_http (if that's
still a thing), etc.
If added, I suppose it would be useful for PHP developers testing HTTP/2
features like Server Push, assuming the CLI server supported it.
Thanks.
--
Andrea Faulds
https://ajf.me/
Hi Andrea
Hi Davey,
Davey Shafik wrote
[snip]
We could also add a flag (e.g. --[no-]http2) on the CLI for
enabling/disabling it — this would be helpful for testing HTTP/2 client
fallback when it's not supported.Hmm, this would mean a new dependency, and more potential complexity. I'm
not sure if HTTP/2 justifies it.
This is the main reason I think it should be optional. But I do think
HTTP/2 justifies it none-the-less. HTTP/2 has the potential to completely
disrupt our HTTP architecture — it removes the need for things like JS/CSS
inlining, JS/CSS minifying, CSS image sprites, domain sharding, and more.
Also, don't all the major client implementations of HTTP/2 require TLS? Or
is localhost given a free pass?
All browser implementations do require TLS, most other clients do not.
Given that cli-server is intended for development only so shipping some
"self" signed certs might be fine. I'd suggest integrating with letsencrypt
but they can't issue certs for localhost (no public CA can).
This is a much more useful tool than relying on node for make tests, and
allows us to test adding HTTP/2 support to ext/curl, the HTTP stream
(which
could also use libnghttp2…), userland HTTP/2 clients, pecl_http (if that's
still a thing), etc.If added, I suppose it would be useful for PHP developers testing HTTP/2
features like Server Push, assuming the CLI server supported it.
If we use nghttp2 it should.
Thanks,
- Davey
Hi Andrea,
Hi Davey,
Davey Shafik wrote:
However, Rasmus raised the possibility of adding HTTP/2 support to the
cli-server [2], and (someone? @php-pulls) suggested we pull in a third
party lib to do the heavy lifting [3].My recommendation would be to use libnghttp2 [4] which curl also uses —
however, as this adds a new dependency, I think it should be optional
(e.g.
--with-nghttp2-dir=[PATH]), with it falling back to the current HTTP/1.x
implementation.We could also add a flag (e.g. --[no-]http2) on the CLI for
enabling/disabling it — this would be helpful for testing HTTP/2 client
fallback when it's not supported.Hmm, this would mean a new dependency, and more potential complexity. I'm
not sure if HTTP/2 justifies it.Also, don't all the major client implementations of HTTP/2 require TLS?
Or is localhost given a free pass?
To me it would be a huge and hard work to reinvent the wheel by manually
implement http2 support.
This library is widely used and well maintained. It provides all we need
(easy api for frames, push and co, hpack etc.). It is an acceptable trade
off to add one dep to have a compliant http2 support.
This is a much more useful tool than relying on node for make tests, and
allows us to test adding HTTP/2 support to ext/curl, the HTTP stream
(which
could also use libnghttp2…), userland HTTP/2 clients, pecl_http (if
that's
still a thing), etc.If added, I suppose it would be useful for PHP developers testing HTTP/2
features like Server Push, assuming the CLI server supported it.Thanks.
--
Andrea Faulds
https://ajf.me/
Hi Pierre,
Pierre Joye wrote:
Hi Andrea,
Hmm, this would mean a new dependency, and more potential complexity. I'm
not sure if HTTP/2 justifies it.Also, don't all the major client implementations of HTTP/2 require TLS?
Or is localhost given a free pass?To me it would be a huge and hard work to reinvent the wheel by manually
implement http2 support.This library is widely used and well maintained. It provides all we need
(easy api for frames, push and co, hpack etc.). It is an acceptable trade
off to add one dep to have a compliant http2 support.
Ah, don't get me wrong, I didn't think we should reimplement HTTP/2
ourselves! I just worried about the complexity.
But yeah, since it's a library, I probably shouldn't worry too much. :)
Thanks.
Andrea Faulds
https://ajf.me/