Closed theoryfate closed 5 years ago
Can you explain when exactly you would use that? You normally identify a HTTP/2 connection through its ALPN protocol, no status line sniffing required.
You are right, but you are referring to the case of using TLS. If it is h2c (HTTP/2 Cleartext), you cannot use ALPN. In this case, you need to analyze HTTP/2 Connection Preface. @bnoordhuis
I'm aware of the theoretical existence of h2c but I didn't think anyone actually uses it. Can you explain what you're using it for?
The reason I ask is that retrofitting support for the connection preface may introduce some thorny backwards compatibility issues, so I'd rather only tackle that when there's a legitimate use case.
Yes, now all browsers are forced to use HTTP2 over TLS, I just saw the h2c described in the RFC so I want to support it on my own server. If this will have a bad effect on the library, then forget it. @bnoordhuis
Okay, given that I'll close the issue for now. If you or anyone else has a real world use case let me know and we can reconsider.
This is a good example how to use issue tracker in a wrong way.
User @theoryfate provided a reasonable question. Universal HTTP 1.1 parser should understand HTTP 2.0 connection preface. Nodejs developers just maintains this c library, they can't provide a stable solution without library redesign.
Than nodejs developers started a new universal library llhttp and just forgot about that question.
FYI, I have a PR open that addresses this. See notejs/llhttp#80
The content of the HTTP/2 Connection Preface specified in RFC 7540 is "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n",Also known as Magic Code, it allows us to identify HTTP/1.1 or h2c for subsequent protocol processing.
Now I use your http-parse library to parse HTTP/1.1. It works very well, but does not support the "PRI" HTTP METHOD. I can't use it to parse the HTTP/2 Connection Preface, which makes it impossible to switch subsequent protocol processing logic.
So please add the handling of the HTTP/2 Connection Preface, which is the HTTP/1.1 format. The HTTP/1.1 parsing library adds support for it, which is very reasonable.
Please support the "PRI" HTTP METHOD, or add a similar "parser->upgrade" mechanism to remind developers to switch the functionality of subsequent protocol processing.