Subject: RE: [Technical Errata Reported] RFC7540 (4663)

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Apr 2016 22:01:19 +0000

On #1, as I stated before, I believe you're incorrect.  RFC 3875 explicitly states that this is the protocol used between the server and the script, which need not be that used between the client and the server.  Your #2, while irrelevant, is also incorrect -- Upgrade in HTTP/2 uses the token "h2c", not "HTTP/2.0".  RFC 7540 section 3.5 defines the connection preface, which is sent for any form of HTTP/2 connection, and does not have any semantic value.

You're welcome to continue to have your own opinion, and I've stated mine, as have others.  I believe at this point the Area Directors have enough information to judge the status of the erratum, so I'm going to leave the discussion here.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, April 12, 2016 2:11 PM
To: Barry Leiba <[email-masked]>; Mike Bishop <[email-masked]>
Cc: RFC Errata System <[email-masked]>; Mark Nottingham <[email-masked]>; Mike Belshe <[email-masked]>; Roberto Peon <[email-masked]>; Martin Thomson <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: RE: [Technical Errata Reported] RFC7540 (4663)

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 <[email-masked]> wrote:

 Subject: RE: [Technical Errata Reported] RFC7540 (4663)
 To: "Barry Leiba" <[email-masked]>, "[email-masked]" <[email-masked]>
 Cc: "RFC Errata System" <[email-masked]>, "Mark Nottingham" <[email-masked]>, "Mike Belshe" <[email-masked]>, "Roberto Peon" <[email-masked]>, "Martin Thomson" <[email-masked]>, "HTTP Working Group" <[email-masked]>
 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: [email-masked]
 [mailto:[email-masked]]
 On Behalf Of Barry Leiba
 Sent: Tuesday,
 April 12, 2016 10:47 AM
 To: [email-masked]
 Cc: RFC Errata System <[email-masked]>;  Mark Nottingham <[email-masked]>; Mike  Belshe <[email-masked]>;  Roberto Peon <[email-masked]>;  Martin Thomson <[email-masked]>;  HTTP Working Group <[email-masked]>
 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,  <[email-masked]>
 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 <[email-masked]>
 wrote:
 >  Subject:
 Re: [Technical Errata Reported] RFC7540 (4663)  >  To: "RFC Errata System" <[email-masked]>  >  Cc: "Mike Belshe" <[email-masked]>,  [email-masked],  "Martin  > Thomson" <[email-masked]>,  [email-masked],
 
 > [email-masked],
 [email-masked]
 >  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
 <[email-masked]>
 >  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
 >  <[email-masked]>
 >  >
 >  >
 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/

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Apr 2016 19:14:19 -0400

Alexey did not get all of these messages, so I've forwarded the whole
thread to him.  Please be sure to have him in the distribution list
for any further discussion: he is now the AD responsible for this, not
me.

Barry

On Tue, Apr 12, 2016 at 6:01 PM, Mike Bishop
<[email-masked]> wrote:
>  >  > The
>  >  > Reported by: D.
>  >  > Original Text
>  >  > Notes
>  >  > Compatibility
>  >  > "This specification is
>  >  > RFC 7540, section
>  >  > This erratum is
>  >  > RFC7540
>  >  > Title
>  >  > Area
>  >  > Verifying

---

From: <[email-masked]>
Date: Tue, 12 Apr 2016 21:14:39 +0000

Rebuttal:

Other:

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: [email-masked]
[mailto:[email-masked]]
On Behalf Of Barry Leiba
Sent: Tuesday,
April 12, 2016 10:47 AM
To: [email-masked]
Cc: RFC Errata System <[email-masked]>;
Mark Nottingham <[email-masked]>; Mike
Belshe <[email-masked]>;
Roberto Peon <[email-masked]>;
Martin Thomson <[email-masked]>;
HTTP Working Group <[email-masked]>
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

> 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.
>   Subject:
Re: [Technical Errata Reported] RFC7540 (4663)
>   To: "RFC Errata System" <[email-masked]>
>   Cc: "Mike Belshe" <[email-masked]>,
[email-masked],
"Martin 
> Thomson" <[email-masked]>,
[email-masked],

[email-masked]
>   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
>   > The
following errata report has been submitted for RFC7540, 
> "Hypertext 
> Transfer Protocol
Version
>   2 (HTTP/2)".
Technical
Stussy
Section: 8 omits
"/" 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 

-----
>   > 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:
an alternative  to, but does not obsolete, 
> the HTTP/1.1 message syntax.
unchanged"
> 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.
routines.)  >  > Instructions:
-------------
currently
>   posted as
"Reported". If necessary, please  > use
"Reply All" to 
> discuss 
whether it should be verified or  >  rejected. When a

party
Author(s)           : M.
          : PROPOSED STANDARD
      : Applications
Stream
Party     : IESG

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Apr 2016 08:13:06 +0200

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

FWIW, RFC 2616 is a "draft" standard, and it was obsoleted by RFC723*, 
currently "proposed". I agree that at some point, the HTTP specs should 
be full internet standards, but right now, they are not.

> ...

Best regards, Julian