> I guess e.g. Nginx could also insert an artificial header to mark requests received as 0-RTT, and frameworks like Django could use that header to require views be explicitly marked with a decorator to indicate support, or something like that
There is an Internet Draft for that [1]. It is co-authored by Willy Tarreau of haproxy and implemented within haproxy 1.8 [2].
That would certainly require a lot of coupling from proxy to code, though. The nicest thing about TLS is that it's just a transparent dumb pipe that provides confidentiality and integrity (and less often, client authentication).
Having to write your app to understand that TLS 1.3 was used, and 0RTT was used, seems like a really really bad idea. The longer I'm in engineering, the more I realize that the number of people who understand the ramifications here is much smaller than the number who can throw together a TLS 1.3 listening HTTP server by following some dude's tutorial.
Framework support is not going to be enough. This seems like a bad, bad move.
Eh, it doesn't sound too bad. There's already a myriad of meta data (HTTP request headers) you need to process today if you want to be a good HTTP citizen, such as acknowledging Accept-Encoding, HTTP byte ranges, If-Modified-Since, X-Forwarded-For, X-Forwarded-Proto, etc; and sending correct response headers such as Cache-Control, Vary, and so on.
Having to write your app to understand that TLS 1.3 was used, and 0RTT was used, seems like a really really bad idea. The longer I'm in engineering, the more I realize that the number of people who understand the ramifications here is much smaller than the number who can throw together a TLS 1.3 listening HTTP server by following some dude's tutorial.
Framework support is not going to be enough. This seems like a bad, bad move.