- From: Barry Leiba <barryleiba@computer.org>
- Date: Tue, 12 Apr 2016 19:14:19 -0400
- To: Alexey Melnikov <aamelnikov@fastmail.fm>
- Cc: "d.stussy@yahoo.com" <d.stussy@yahoo.com>, Mike Bishop <Michael.Bishop@microsoft.com>, RFC Errata System <rfc-editor@rfc-editor.org>, Mark Nottingham <mnot@mnot.net>, Mike Belshe <mike@belshe.com>, Roberto Peon <fenix@google.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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 <Michael.Bishop@microsoft.com> wrote: > 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: d.stussy@yahoo.com [mailto:d.stussy@yahoo.com] > Sent: Tuesday, April 12, 2016 2:11 PM > To: Barry Leiba <barryleiba@computer.org>; Mike Bishop <Michael.Bishop@microsoft.com> > Cc: RFC Errata System <rfc-editor@rfc-editor.org>; Mark Nottingham <mnot@mnot.net>; Mike Belshe <mike@belshe.com>; Roberto Peon <fenix@google.com>; Martin Thomson <martin.thomson@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org> > 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 <Michael.Bishop@microsoft.com> wrote: > > Subject: RE: [Technical Errata Reported] RFC7540 (4663) > To: "Barry Leiba" <barryleiba@computer.org>, "d.stussy@yahoo.com" <d.stussy@yahoo.com> > Cc: "RFC Errata System" <rfc-editor@rfc-editor.org>, "Mark Nottingham" <mnot@mnot.net>, "Mike Belshe" <mike@belshe.com>, "Roberto Peon" <fenix@google.com>, "Martin Thomson" <martin.thomson@gmail.com>, "HTTP Working Group" <ietf-http-wg@w3.org> > 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: barryleiba@gmail.com > [mailto:barryleiba@gmail.com] > On Behalf Of Barry Leiba > Sent: Tuesday, > April 12, 2016 10:47 AM > To: d.stussy@yahoo.com > Cc: RFC Errata System <rfc-editor@rfc-editor.org>; Mark Nottingham <mnot@mnot.net>; Mike Belshe <mike@belshe.com>; Roberto Peon <fenix@google.com>; Martin Thomson <martin.thomson@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org> > 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, <d.stussy@yahoo.com> > 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 <mnot@mnot.net> > wrote: > > > > Subject: > Re: [Technical Errata Reported] RFC7540 (4663) > To: "RFC Errata System" <rfc-editor@rfc-editor.org> > Cc: "Mike Belshe" <mike@belshe.com>, fenix@google.com, "Martin > Thomson" <martin.thomson@gmail.com>, barryleiba@computer.org, > > > d.stussy@yahoo.com, > ietf-http-wg@w3.org > > 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 > > > <rfc-editor@rfc-editor.org> > > 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 > > <d.stussy@yahoo.com> > > > > > > > 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/ > > > > > > >
Received on Tuesday, 12 April 2016 23:14:47 UTC