Hi,

On Tue, Apr 12, 2016 at 10:11 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> Hey @tatsuhiro-t!
>
> (The lack of HTTP/2 tests in our test suite is really bugging me!)
>
> I'm considering adopting nghttpx as a test server in curl's test suite, so
> that it'll proxy HTTP requests to/from our regular HTTP/1 test server. We
> want HTTP/1.1 Upgrade support, but also support for TLS based and ideally
> "prior knowledge". Do you think that's a decent approach?
>
> I've run some basic initial tests with HTTP/1 Upgrade and it seems to work
> pretty good.
>
>
​Yes, nghttpx supports all kind of HTTP/2 initiation, it even supports HTTP
Upgrade with POST ;).

> I've hesitated to adopt an entire HTTP/2 server souce code into our test
> suite simply because it is a pretty decent amount of complicated code and
> if nghttpx can do this for us, I think we'll benefit a lot from sharing
> code with others.
>
> nghttpx does not do everything we need right now (unless I've missed
> things in the docs):
>
> Primarily, I'd like it to be able to store incoming HTTP requests in a
> separate log file (probably decoded in the HTTP/2 case) so that we in our
> test cases can make sure that the request arrived as intended.
>
>
​nghttpx has several debug options, specifically, -o and
--frontend-http2-dump-request-header options.
The former outputs the same format as we see in nghttp -v. Which is good
for human, but hard to parse for machine.
The latter outputs request header fields in HTTP/1.1 manner, but it is
limited to header fields, and no request body is included.

nghttpx also supports mruby extension, and you probably write to a file
with incoming request header fields if suitable mrbgem is compiled in. But
still no request body support here.​

> Further down the road, it might be interesting to add a way to control the
> server to misbehave or otherwise mess up the protocol in specified ways so
> that we can make sure that curl still does the right thing in such
> situations. That would be the primary reason why cloning the entire code
> base into the curl repo could still be future move. I'm still interested to
> know if you think that would be possible @tatsuhiro-t, if done correctly
> and with your guidance?
>
>
​This is the hardest part with nghttpx. We make it rather production proxy
server, not debugging ​purpose one. Adding these things are interesting,
but it obviously adds more complexities, which I have to say is hard to
maintain.

As for HTTP/2, nghttp2 library sends always "correct" output. Currently,
nghttp2 passes buffer to the application per frame except for DATA frame
payload. Although this is not guaranteed in the future versions (we never
say this in API reference), we can do some fuzzing there.

Best regards,
Tatsuhiro Tsujikawa

> If you or someone else have other or better ideas or suggestions, please
> let me know!
>
> --
>
> / daniel.haxx.se
>

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-04-12