ok so i've looked into this, and on a postmill instance that uses cloudflare + nginx, i cannot reproduce the issue, it seems to work fine. i can only imagine it's a problem between caddy and whatever http client newsblur uses.
but rereading the spec, you're supposed to send a 505 in the representation used by the major version requested by the client
GET / HTTP/2.0 is parsed with http/1 semantics, so i think it makes sense to give any >= 2.x version the HTTP/1.1 505 treatment.
An HTTP/2 request can be sent without negotiation; this is how h2c (HTTP/2 over cleartext) reliably works for me (for some reason I couldn't get Upgrade from http/1.1 to h2c working). It's called "prior knowledge", and curl supports this.
yeah, but as the name implies, you somehow know in advance that the server's gonna accept HTTP/2 if you send those. i suppose 505 here would make sense, if the HTTP/2 support was ever removed. as i understand it, this mode is never going to happen under normal browsing, though.
No, 505 wouldn't be useful because an HTTP/2 request to an HTTP/1-only server would only result in the client just closing the connection itself. You can see this by using nghttp or curl --http2-prior-knowledge against a server that only supports HTTP/1
An HTTP/2-only client (which those two commands earlier are) would not bother to process an HTTP/1 response (if it even gets one) whether that'd be a 505 or 200.
i meant a hypothetical http/2 that's more http/1-like, not the actual http/2 that came into existence which made it very hard to accidentally use the wrong protocol.
I mean the same applies if an HTTP/1 response is a 505, right..?
no, since http/1 requests are sent preemptively without knowing if the server accepts them. http/2+ requests are sent after negotiation, at which point it's established they are accepted. this obsoletes the need for a 505.
505 would have been useful for a future where http/2 requests might be preemptively sent to http/1-only servers. if i send GET / HTTP/2.0 (or any non-1.x version) to nginx, it indeed responds with that status code. but as things turned out, the negotiation mechanism in http/2+ just sidesteps this problem altogether, so 505 ends up being little more than a relic from a time when people didn't know what the future of http held.
since you very much have to opt in for http/2+, incompatibilities with it can be resolved by just not enabling it, and the use cases where one would want partial http/2 support on any given host are extremely contrived, i would argue it's a good thing that support for it is declared on the connection level. it's one less special case for clients to deal with.
if a server is able to serve an http response as http/2 and/or http/3, then by definition it supports http/2 and/or http/3, despite the status code's claim of the contrary.
emma wrote
Reply to Watching Youtube Shorts with Momoka by devtesla
thank you, i was looking for something new to watch