RE: [Moderator Action] [Technical Errata Reported] RFC7540 (4663)

[<[e-mail]>]

Rebuttal:
1)  The CGI interface variable is supposed to report the protocol version used between server and client.  Per RFC 3875, it has a specified format.  RFC 7540 did NOT change that format.  "HTTP/2.0" is the required generated string from the ABNF.  Addressing the RFC 1796 comment, RFC 7540 simply contained no authority or directive to change the string, whether [future] standard or informational.

2)  Although HTTP/2 does NOT communicate its version number between server and client in any header using its binary format (by design), there is still the HTTP/1.1 direct upgrade mechanism mentioned in RFC 7540, section 3.5, that clearly has a "HTTP/2.0" substring in the "client connection preface" string.  If things were as you say, shouldn't the ".0" part have been omitted?

RFC 2616, aka "HTTP 1.1", is an Internet standard (after 26 years, it certainly has been promoted from "draft").  I fully expect RFC 7540 to follow that path, especially as it is a "standards track" class RFC document.  A standard, by definition, is enforceable.  RFC 7230, updating 2616, in section 2.6, still defines the http-version string with the same ABNF as RFC 3875, thus no meaningful update.  Although not used in the actual client/server exchange as it was in HTTP 1.1 and earlier, it's still in use in the logs and the CGI interface WITHOUT any syntax change.

Other:
In searching the source code for both Apache (2.4.18) and the nghttp2 library (1.9.2), I note that Apache got it wrong and the nghttp2 library got it correct.  The latter specifically uses a "HTTP/2.0" string as it should for the CGI protocol identifier string.  Bug 59313 was opened at the Apache site for the problem.  Feel free to comment there too.  It is this confusion that caused me to raise the issue.


The fact remains:  RFC 7540 did not change the format of the HTTP version CGI string, yet the authors of the most popularly used software somehow read this document to think that it had.  That is a problem.  My errata suggestion clarifies the issue.

--------------------------------------------
On Tue, 4/12/16, Mike Bishop <[e-mail]> wrote:

Subject: RE: [Technical Errata Reported] RFC7540 (4663)
To: "Barry Leiba" <[e-mail]>, "[e-mail]" <[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]>
Date: Tuesday, April 12, 2016, 1:19 PM

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/
> 
> 
>