Support for query strings

[huitema]

In a comment to PR #1729 @hfstco observes that h3zero does not currently support query strings. It actually does, but only for POST and CONNECT commands, for which we have an extension mechanism. It would be possible to use the same extension mechanism for GET commands: recognize that the path-abempty component of the URL, compare against the table of registered components currently used for POST and CONNECT, and treat a GET to a recognized value pretty much the same way we treat POST.

The challenge is to do that while keeping the spirit of h3zero: as small as possible, as simple as possible...

[huitema]

A good practical use case might be a static web site built with jekyll.

I am however a bit concerned that there is a slippery slope here. If the goal is really "interop with Chrome", we need a couple of other works:

• Run on UDP port 443, which requires either running as root (scary) or starting as root and then reducing the process rights to a limited user.
• maybe support for TCP/HTTP port 80 and TCP/TLS/HTTP port 443, if only to add a redirect to QUIC.
• if we support HTTP, maybe support for HTTP2 -- but HTTP2 and HTTP3 differ in many ways, and I would rather not have to do that...

[huitema]

And then we have to consider support for let's encrypt/ACME.

[hfstco]

It actually does, but only for POST and CONNECT commands, for which we have an extension mechanism.

Ok, I haven't looked into the POST & CONNECT part yet. But I think everything we need to handle query strings, is already implemented in h3zero_uri.c. 👍

It would be possible to use the same extension mechanism for GET commands: recognize that the path-abempty component of the URL, compare against the table of registered components currently used for POST and CONNECT, and treat a GET to a recognized value pretty much the same way we treat POST.

In my case, I process the query string only on the client side. For me, it would be enough to recognize & skip the query string part for GET requests. I don't want to work with the query string on the server side. But the h3zero_server_parse_path() function fails to find the requested file with the query string at the end of the path. https://github.com/hfstco/picoquic/blob/9f513d0dcde8cccd05e865a25737dd2c64b0f5fb/picohttp/h3zero_server.c#L137

Of course, we can also put more effort into this.

The challenge is to do that while keeping the spirit of h3zero: as small as possible, as simple as possible... I am however a bit concerned that there is a slippery slope here. If the goal is really "interop with Chrome", we need a couple of other works

Yes, I don't want to implement a fully fledged web server. I think there is a lot of work to do so. In our project, we want to compare "real-world" applications with different QUIC implementations. I think HTTP3 is a good choice here. And with Chrome you can demonstrate this even better than with curl terminal output.

Currently it works fine to start Chrome with the --origin-to-force-quic-on option to skip the redirect to QUIC. My goal was simply for h3zero to be able to deliver simple websites. (content type, query string, ...)

maybe support for TCP/HTTP port 80 and TCP/TLS/HTTP port 443, if only to add a redirect to QUIC.

Maybe it would be an idea to start a separate process on port 80/443 to simply say: "Hey, there's a QUIC website. (alt-svc)". And then redirect to it. However, I don't have much experience with how this HTTP -> HTTP3 upgrade process works in different browsers.

And then we have to consider support for let's encrypt/ACME.

You are talking about the HTTP-01 challenge, right? The HTTP-01 challenge requires you to open port 80. Which brings us back to run as root. The DNS-01 challenge with certbot works fine for me.

This whole discussion tends to: "Shall we make a fully-fledged web server out of h3zero?" Unfortunately, I don't know what the intention behind h3zero was. But I don't think it should be a production-ready web server.