I wrote this issue following this article by seanmonstar and in my infinite wisdom (/s) think I misinterpreted what he meant by

We’re so close to having it work! With hundreds of tests working, there’s only a dozen or so tests left to fix. I’ve inlined the test number and brief description here, but the actual file will be more up-to-date.

I see that 1800 was not included in this list... and what was meant is probably that in the future there will be even less on that list. I'll try and get around to actually helping soon, but I apologize in advance if this problem was already known!

I think Sean's list was cut off early? The full list I made is in the hyper wiki page and does include 1800 (and the file DISABLED in git has it disabled, which gives it away too). I think your conclusion about what's lacking there is correct and matches my thinking.

I presume hyper has some way to help us get the HTTP2-Settings: header made?

@seanmonstar can correct me if I'm wrong, but I'm assuming that the fact that 1800 wasn't on the list in his article indicates that they already know the root cause of this problem. I think (but am not 100% sure) that there isn't currently logic to create the HTTP2-Settings header from hyper (should I make an issue for hyper?).

That being said, if there is a way to get the HTTP2-Settings with hyper (or when there is a way), perhaps we could add something like the following after all of the current header logic in Curl_http (forgive me for my lack of knowledge in C):

if(!h2 && (data->state.httpwant == CURL_HTTP_VERSION_2_0)) {
  result = Curl_hyper_header(data, headers,
                             "Connection: Upgrade, HTTP2-Settings");
  if(result)
    goto error;

  result = Curl_hyper_header(data, headers, "Upgrade: h2c");
  if(result)
    goto error;

  /* Eventual callback to some HTTP2-Settings Header Generation? */
  if(result)
    goto error;
}

I didn't include it in the list because this one we do know the root cause of: hyper doesn't have http1-to-http2 upgrade support. Specifically, it's h2 internal dependency doesn't know how to start a stream with just the response side being http2.

I didn't know that...

Steps forward for this are likely:

1. document this as another known restriction when using hyper for HTTP.
2. libcurl needs to return a suitable error for h2 enabled when using plain http with hyper
3. test case 1800 (and some of the 17xx ones ?) need to be disabled in the test case itself. We should probably make them require feature h2c and make runtests.pl set the feature depending on what backend it detects is in use

Would this also pose a problem for tests 358 and 359 (which are on the list of unknown root causes)? I'm not sure if it's necessarily the root cause (I don't know too much about alternative services/if & how hyper deals with them), but both tests have commands that set the --http2 option and expect output that indicates a protocol switch with h2c, which hyper doesn't support.

Would this also pose a problem for tests 358 and 359

Yes. Even if those tests are strictly speaking for testing alt-svc, they do check for an eventual upgrade to h2 with --http2 and thus this won't work with hyper as it works now. It is unfortunate to disable the alt-svc tests for hyper builds, but it will take a larger fix to work around that test setup - like by providing a "real" h2 HTTPS server to the curl test quite that would agree to h2 with alpn. We currently use stunnel for all the HTTPS'ing there and it doesn't do alpn.