RE: [Technical Errata Reported] RFC7540 (4663)

[Mike Bishop <[e-mail]>]

Intent:  The explicit change from 2.0 to 2 between drafts -09 and -10.  Yes, there was a deliberate choice to make the change throughout the document.  Was this described in detail in the final document, along with reasoning?  No.  Perhaps it would have been worth a mention, but it wasn't.  It's still an explicit change.  The connection preamble is intended to look somewhat like HTTP/1.1 with a new version number, but not be valid, so that inspecting servers will fail quickly if they're going to.  The PRI method is reserved in HTTP/1.1 for the same reason, to ensure that the preamble will never look like a valid HTTP/1.1 request.

Did we think about the fact that an Informational RFC had taken a dependency on how things were in HTTP/1.1?  We discussed the possibility that software out there would have, but not that RFC specifically.  HTTP/2 needs to be compatible with prior Standards, but see RFC 1796.

But while we're talking about RFC 3875, it says "Here, 'protocol' defines the syntax of some of the information passing between the server and the script (the 'protocol-specific' features)." and "This MAY differ from the protocol version used by the server in its communication with the client."  So unless the *script* supports a newer version of HTTP (and therefore will understand whatever string is used to express it), it might be most cautious for the server and the script to continue communicating over HTTP/1.1 regardless of the version being used to communicate with the client.  However, that's a decision for individual implementations, not a standards document decision. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Barry Leiba
Sent: Tuesday, April 12, 2016 10:47 AM
To: [e-mail]
Cc: RFC Errata System <[e-mail]>; Mark Nottingham <[e-mail]>; Mike Belshe <[e-mail]>; Roberto Peon <[e-mail]>; Martin Thomson <[e-mail]>; HTTP Working Group <[e-mail]>
Subject: Re: [Technical Errata Reported] RFC7540 (4663)

I don't understand how it breaks anything: when you use HTTP/1.1, you have the minor version.  When you use HTTP/2, you're using a server that understands HTTP/2 and knows what to expect.  Please explain where the problem occurs.

Barry

On Tue, Apr 12, 2016 at 1:11 PM,  <[e-mail]> wrote:
> If there were a deliberate choice to omit the "minor" version number, such needs to be stated in the RFC.  Such a choice is actually omitted, and thus I see no such intent.  What results at best is a conflict between two RFC's, and at least, an implementation error by the group which authored the HTTP/2 library I cited, which is in turn adopted by Apache, the most common HTTP server software used on the Internet (per the Netcraft survey).  I raised this as an error because I do not believe that it was the intent of this RFC to break an earlier RFC with which it claims backward compatibility in the majority of HTTP servers on the Internet.
>
> --------------------------------------------
> On Tue, 4/12/16, Mark Nottingham <[e-mail]> wrote:
>
>  Subject: Re: [Technical Errata Reported] RFC7540 (4663)
>  To: "RFC Errata System" <[e-mail]>
>  Cc: "Mike Belshe" <[e-mail]>, [e-mail], "Martin 
> Thomson" <[e-mail]>, [e-mail], 
> [e-mail], [e-mail]
>  Date: Tuesday, April 12, 2016, 12:31 AM
>
>  REJECT; HTTP is not
>  defined by the CGI specification, and the WG made a  conscious choice 
> to omit the minor version number.
>
>  Updating the CGI specification
>  is more appropriate (although an errata may not be the best  way to 
> do it for that spec either).
>
>  Cheers,
>
>
>  >
>  On 12 Apr 2016, at 5:19 PM, RFC Errata System 
> <[e-mail]>
>  wrote:
>  >
>  > The
>  following errata report has been submitted for RFC7540,  > "Hypertext 
> Transfer Protocol Version
>  2 (HTTP/2)".
>  >
>  >
>  --------------------------------------
>  >
>  You may review the report below and at:
>  >
>  http://www.rfc-editor.org/errata_search.php?rfc=7540&eid=4663
>  >
>  >
>  --------------------------------------
>  >
>  Type: Technical
>  > Reported by: D. Stussy
>  <[e-mail]>
>  >
>  > Section: 8 omits
>  >
>  > Original Text
>  > -------------
>  >
>  [Note:  RFC 3875, section 4.1.16, defines the protocol  version as:
>  >
>  >
>  HTTP-Version = "HTTP" "/" 1*digit
>  "." 1*digit
>  >
>  > Nothing in RFC 7540 redefines this.]  >  > Corrected Text  > 
> --------------  > Add  paragraph at end of section 8 (before 8.1) -
>  Clarification:
>  >
>  >
>  HTTP/2 preserves the format of the SERVER_PROTOCOL CGI  variable,  > 
> both in the CGI interface and  for any server logging purposes.  Where  
> > a version string is necessary, it is  "HTTP/2.0" as defined by RFC 
> 3875.
>  >
>  > Notes
>  > -----
>  > Compatibility
>  is required with a prior published RFC, or a specific change  
> superseding the prior RFC need be explicitly stated.  This  RFC states 
> in its abstract:
>  >
>  > "This specification is an alternative  to, but does not obsolete, 
> the HTTP/1.1 message syntax.
>  HTTP's existing semantics remain unchanged"
>  >
>  > RFC 7540, section
>  3.5's connection preface string containing  "HTTP/2.0" implies that 
> the RFC authors should  have forseen this issue, and added a paragraph 
> to section 8  to explicitly state no change in the CGI interface 
> variable  SERVER_PROTOCOL was desired.  At least one implementation  
> is using a version string of "HTTP/2", not  "HTTP/2.0", because of how 
> it is referred in this  RFC. ("nghttp2.org" has incorrectly 
> implemented  this in its library routines.)  >  > Instructions:
>  >
>  -------------
>  > This erratum is currently
>  posted as "Reported". If necessary, please  > use "Reply All" to 
> discuss  whether it should be verified or  >  rejected. When a 
> decision is reached, the verifying party
>  (IESG)
>  > can log in to change the status
>  and edit the report, if necessary.
>  >
>  > --------------------------------------
>  > RFC7540 (draft-ietf-httpbis-http2-17)  > 
> --------------------------------------
>  > Title               :
>  Hypertext Transfer Protocol Version 2 (HTTP/2)
>  > Publication Date    : May 2015
>  > Author(s)           : M.
>  Belshe, R. Peon, M. Thomson, Ed.
>  >
>  Category            : PROPOSED STANDARD
>  > Source              : Hypertext
>  Transfer Protocol Bis APP
>  > Area
>            : Applications
>  > Stream
>              : IETF
>  > Verifying
>  Party     : IESG
>  >
>
>  --
>  Mark
>  Nottingham   https://www.mnot.net/
>
>
>