Instruct Cloudflare not to serve HTTP/3?

judahgabriel · June 9, 2021, 11:59pm

Hi there!

I work on a developer tool called PWABuilder, which helps developers build Progressive Web Apps (PWAs).

Cloudflare’s HTTP/3 support has been giving me many headaches lately.

Specifically, I use various backend services to fetch website content (manifests, service workers, images, and more). But most HTTP APIs – including those in Node, .NET, and Java – don’t currently support HTTP/3, as it’s still an experimental protocol.

What ends up happening is developers open issues asking why their sites aren’t working with my developer tools. I investigate, only to find that their sites are being served via Cloudflare’s experimental HTTP/3 support, often unknowingly.

Is there a way during my HTTP fetch calls to tell Cloudflare not to serve HTTP/3 requests? Request headers perhaps or some other way? I assume that Cloudflare can gracefully handle cases where HTTP/3 isn’t supported and fallback to HTTP/2 or 1.1. But I don’t see a way to advertise that to Cloudflare while making my programmatic HTTP fetch calls.

LucasCF · June 8, 2021, 11:32pm

Hi @judahgabriel,

Thanks for writing to the community forums, PWAs are cool!

I’m an engineer on the Cloudflare team responsible for QUIC and HTTP/3. As you might have seen on the blog recently, QUIC version 1 was published as RFC 9000 and it is now enabled fully on our edge. The HTTP/3 drafts are very close to being published as RFCs too, and the version that User Agents and the Cloudflare edge talk is as close as can be to the RFC version. For these reasons, HTTP/3 support is not classed as experimental.

I’m sorry that you and your are developers hitting issues. But given the status of HTTP/3, we’d really like to understand more about the problems that you seem to be encountering.

Can you explain a bit more about how PWABuilder works?

If you’re using the Fetch API, there is no way to control the connection-oriented aspects like HTTP version (this is by design, due to web security models).

I appreciate that having issues raised on your repo isn’t great, and requiring your users to turn off HTTP/3 for their Cloudflare zones isn’t so good either. It would be awesome if you could help us debug this a bit further to understand what is happening here to cause people to see 5xx errors.

Feel free to respond on this issue, or DM me.

judahgabriel · June 9, 2021, 11:55pm

Hey Lucas. Thanks for the reply.

I didn’t know HTTP/3 was standardized the other week. Thanks for the heads up. Amazing how fast the web evolves! I love it.

What I’m doing: using standard HTTP APIs (from Node, .NET, Java, etc.) to fetch resources from a developer’s PWA. A developer puts in “https://webboard.app” into PWABuilder, and PWABuilder web service analyzes their site, find their web manifest (e.g. manifest.json) and app icons listed in their web manifest.

The problem is that HTTP APIs in all the mainstream programming frameworks – Node, .NET, Java, Python, etc. – are unable to work with HTTP/3. Ditto for the myriads of tools built on top of these APIs, including PWABuilder. I love that Cloudflare is on the cutting edge with HTTP/3, but Clouldflare should provide a graceful fallback for HTTP clients that don’t support HTTP/3, no?

That’s what I’m asking for. Allow me to say in my HTTP request, “Hey, I only support HTTP/1.1” and Cloudflare should honor that.

Does that make sense?

LucasCF · June 10, 2021, 12:25am

Thanks for the added colour @judahgabriel .

So by default, when someone enables HTTP/3 on a Cloudflare zone, we listen on TCP for HTTP/1.1 and HTTP/2, and on UDP for HTTP/3. The client is the one in the driving seat to decide which port it opens and tries to speak to us on. To put it another way, the fallback is already there.

So the thing that confuses me here is that I would expect a framework to by default handle all of this for you without errors. Although the protocols are basically standard, it will take some time for support to filter down to stable frameworks. A framework that has no notion of HTTP/3 would just continue on with try HTTP/1.1 or HTTP/2. For a framework to try HTTP/3 without being configured to is a bit surprising (but possible maybe?). However, for it to fail with an application-level error like an HTTP status code or a malformed payload is really strange and should not happen - and that’s why I’m keen to find out if there is something untoward.

An alternative possibility is that your client code is struggling to speak to Cloudflare for some other reason unrelated to HTTP/3. For instance, maybe it’s hitting ratelimiting or DDoS prevention measures etc.

To really make progress on troubleshooting this, it would help to share with us the exact client details and the request/responses that it got. If this were a browser, I’d suggest sharing a HAR file for us to look at. But in this case framework client logs would probably suffice.