Downgrade HTTP/2 to HTTP1 over HTTP(non-TLS)

[nwtgck]

Hi, developers. Thank you very much for your wonderful project! I've been using Node.js a lot.

I have a question about HTTP/2 support. Does http2.createServer() allow downgrade HTTP/2 to HTTP/1 when clients access by HTTP/1 with non-TLS? ({allowHTTP1: true} is specified)

Here is a simple script to test my question above.

• Server: HTTP/2 (http2.createServer({allowHTTP1: true}))
• Client1: HTTP/2 GET
• Client2: HTTP/1 GET

// [This is a portable .js file containing server and client.]

const http2 = require("http2");
const http = require("http");

const port = 3000;
const options = {
  // HTTP/2 will be downgraded to HTTP/1.x 
  allowHTTP1: true,
};
const server = http2.createServer(options);

server.on('stream', (stream, headers) => {
  stream.respond({
    'content-type': 'text/plain',
    ':status': 200
  });
  stream.end('hello, world from server!');
});

server.listen(port, ()=>{
  // server is ready
  console.log(`Server listening on ${port}!`);

  // Choose true/false!
  const useHTTP2 = true;

  if (useHTTP2) {
    // HTTP/2 GET
    http2.connect(`http://localhost:${port}`)
      .request({":path": "/"})
      // Print body
      .pipe(process.stdout)
  } else {
    // HTTP/1 GET
    http.get(`http://localhost:${port}`, (res)=>{
      // Print body
      res.pipe(process.stdout);
    });
  }
});

HTTP/2 client is OK

When const useHTTP2 = true in the code above, the output is as follows without error.

Server listening on 3000!
hello, world from server!

HTTP/1 client has error

When const useHTTP2 = false, the output has error as follows.

Server listening on 3000!
events.js:167
      throw er; // Unhandled 'error' event
      ^

Error: Parse Error
    at Socket.socketOnData (_http_client.js:442:20)
    at Socket.emit (events.js:182:13)
    at addChunk (_stream_readable.js:283:12)
    at readableAddChunk (_stream_readable.js:264:11)
    at Socket.Readable.push (_stream_readable.js:219:10)
    at TCP.onStreamRead (internal/stream_base_commons.js:94:17)
Emitted 'error' event at:
    at Socket.socketOnData (_http_client.js:448:9)
    at Socket.emit (events.js:182:13)
    [... lines matching original stack trace ...]
    at TCP.onStreamRead (internal/stream_base_commons.js:94:17)

Could you tell me whether HTTP/1 client is allowed?

node version

Here is my node version.

$ node -v
v10.15.0

[chux0519]

I checked out the documentation; it seems the option allowHTTP1 is for the method http2.createSecureServer, not http2.createServer. see ALPN negotiation

[bnoordhuis]

@chux0519 is exactly right. Downgrades work at the TLS level (ALPN is a TLS extension), not at the HTTP/2 level. allowHTTP1 is only meaningful for secure servers.

[nwtgck]

Thank you very much for your replies, @chux0519, @bnoordhuis!

I was wondering if it's possible to allow HTTP clients to use HTTP/1.1 in case of using http2.createServer in Node.js.

As an actual example, nghttpx, HTTP/2 reverse proxy in nghttp2 allows HTTP clients to use both HTTP/1.1 and HTTP/2 in the same port without TLS. This feature is very useful because it's highly compatible with conventional HTTP/1.1 clients.

[sam-github]

Are you sure its useful? No major browser vendor has agreed to implement HTTP/2 without TLS, so even if nginx supports it, that doesn't mean there will ever be a client.

EDIT: Found the link. Uencrypted H2 is unused on the web, it is defined in the standards because IoT and other embedded vendors pointed out that requiring TLS on small devices is unreasonable, but no browsers are going to implement it.

See

• https://nodejs.org/dist/latest-v10.x/docs/api/http2.html#http2_server_side_example
• https://http2.github.io/faq/#does-http2-require-encryption

Given this, its not likely that node will go through a lot of effort to enable it, but if you are using node for IoT or something, and want it, I guess you could PR it.

[nwtgck]

@sam-github Thank you for your comment!

Are you sure its useful? No major browser vendor has agreed to implement HTTP/2 without TLS, so even if nginx supports it, that doesn't mean there will ever be a client.

I think Node.js has already supported HTTP/2 server without TLS. As you see the example above, http2.connect(`http://localhost:${port}`)... was successful, which doesn't use TLS.

What I'd like to say was that I hope http2.createServer({allowHTTP1: true}) to allow HTTP/1 connection as well as HTTP/2.

[sam-github]

I think Node.js has already supported HTTP/2 server without TLS

It does, but given that not a single browser supports that, the client has to be not a browser. Given the uncommon nature of that use-case, its not likely to happen anytime soon.

You could PR the feature, though, if its of interest to you. I don't think it would be declined.

You may also be able to implement it yourself, by sniffing the first bytes off the wire, and pushing the incoming stream to the right kind of server. test/parallel/test-tls-ticket.js has some code in it that might give you some ideas as to how.

[nwtgck]

@sam-github Thank you very much.

if its of interest to you

Yes. I'm very interested in the feature because coexistence of HTTP/1 and HTTP/2 is more compatible with conventional HTTP connection over non-TLS not only TLS.

You could PR the feature, though, if its of interest to you. I don't think it would be declined.

I'm not familiar with a contribution to Node.js itself, I'm just a user of Node.js. So, I hope someone skilled people implemented the feature. But, for my learning, I'm reading the code of Node.js related to http2.

[patoi]

@sam-github

Given the uncommon nature of that use-case, ...

Actually, we have a problem with this functionality.

Legacy Client App (calls an API endpoint w HTTP/1 over TLS) -> Load Balancer with SSL termination (calls an API endpoint w HTTP/1.1 wo TLS) -> API Endpoint with Node.js node:http2 createServer , called with HTTP/1.1 wo TLS throws an error

As you can see, node:http is not interchangeable with node:http2. This is a serious problem, because an architectural modification is required (changing place of SSL termination), or the old code must be kept alongside the new one.

@mcollina What do you think?