Unambiguously requested but impossible to fulfil options should error out

[pajod]

I suggest that --http-protocols=h2 without requisites (including --certfile) just stops and tells the user they requested something unsupported (in their environment, or in the latter case: intentionally).
The user clearly expressed that wanted h2 only. And yet they get a server running that has no HTTP/2 functionality, yet responds to HTTP/1.x requests? That does not seem right!

(I think there are more cases. From the older options, I remember --reload-extra-files has such "silent" dependency on --reload, and some --bind and LISTEN_FDS usage is silently conflicting. But those cases actually need work, whereas the case above is not a bug to be fixed but will likely forever be considered plain wrong cmdline/config.)

[benoitc]

i think it's expected however that a server should downgrade from h2 to h1 if the client doesn't support?

[pajod]

Certainly --http-protocols=h2,h1 will be more commonly used - and in that case, yes, the client gets to decide. Possibly based on a Alt-Svc: h2=":443" header.

But when --http-protocols=h2 is set, then Gunicorn was very explicitly instructed not to offer 1.x. If it cannot do any of the requested protocols, it should stop - not do the opposite of what was requested.