You can clone with
We need some magic that clearly indicates that HTTP/2 is being spoken on the wire. It should fast fail when sent to a reasonable set of HTTP/1.1 servers.
Changing magic (#25) based on latest string.
In the draft, so closing (although we might tweak the string as time goes on).
If the goal of the connection header magic string is to emulate a HTTP/1.x request in a way that is both as transparent as possible (can be parsed as HTTP/1.x) and unambiguously differentiated (could NOT be understood as HTTP/1.x), I understand the criteria to be:
When interpreted as a HTTP/1.x request:
To fit in a 24-byte structure, using the given pattern, we would have to use either a three-byte Method and a two-byte entity (before the final "\r\n\r\n"), or a four-byte Method and a one-byte entity. I think 3-2 is better, aesthetically.
I also think it's better to avoid encoding a metasyntactic variable into the standard. "FOO" is universally used as a placeholder for user-supplied data, and it may be confusing for the spec to require implementers to send or expect the literal value "FOO". Additionally there is a legitimate chance that there are implementations in the wild that actually use "FOO" as a method, e.g. for developmental purposes.
I propose "CON" and "go" as the Method and message entity parts. I.e. 434f4e202a20485454502f322e300d0a0d0a676f0d0a0d0a or "CON * HTTP/2.0\r\n\r\ngo\r\n\r\n"
"CON * HTTP/2.0\r\n\r\ngo\r\n\r\n"
Hmm. "CON" is a prefix of "CONNECT"; not saying that implementations will be matching prefixes, but I get a bit worried.
On-list I proposed "STA" and "RT".
STA works for me; I can't think of any reasons it might go wrong.
(I would die happy if it were "HELO" and ".")
Merge pull request #25 from martinthomson/codedesc
Adding just in time descriptions for different opcodes