Subject: [Technical Errata Reported] RFC7540 (4663)

From: RFC Errata System <[email-masked]>
Date: Tue, 12 Apr 2016 00:19:03 -0700 (PDT)

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 12 Apr 2016 17:31:29 +1000

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

--
Mark Nottingham   https://www.mnot.net/

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Apr 2016 08:47:50 -0400

> REJECT; HTTP is not defined by the CGI specification, and the WG made
> a conscious choice to omit the minor version number.

Indeed.

> Updating the CGI specification is more appropriate (although an errata may
> not be the best way to do it for that spec either).

Not "may not be": is not -- RFC 3875 was correct about this at the
time it was written.  It might be that 7540 should have updated 3875
with this, but it didn't, and I don't think that fits into an errata
report either.  We could consider writing a quick draft that updates
3875, if we think that's appropriate.

This stuff is still going to me, and not to Alexey; I'm adding Alexey
to this, and he can handle rejecting the errata report.

Barry

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Apr 2016 16:26:26 +0000

RFC 3875 is also Informational, which I interpret as saying that it describes what existing implementations already do, rather than normatively describing an interoperable protocol.  A draft updating it should also comment on what existing implementations do.

IIRC, we opted to continue pushing "HTTP/1.1" in the manifested request line string for app-compat reasons, and added an explicit request version field that indicates 1.1 or 2 for server apps that have been updated to check it (if they care).

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

Indeed.

> Updating the CGI specification is more appropriate (although an errata 
> may not be the best way to do it for that spec either).

Not "may not be": is not -- RFC 3875 was correct about this at the time it was written.  It might be that 7540 should have updated 3875 with this, but it didn't, and I don't think that fits into an errata report either.  We could consider writing a quick draft that updates 3875, if we think that's appropriate.

This stuff is still going to me, and not to Alexey; I'm adding Alexey to this, and he can handle rejecting the errata report.

Barry

>> 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
>> -----
>> 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:
>> -------------
>> 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.
>>

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 13 Apr 2016 09:53:01 +0200

As the implementor in Apache httpd (this behavior has nothing to do with nghttp2), I can say: httpd exposes the http protocol for the request as part of the request record and that string is send to CGI as SERVER_PROTOCOL as well.

A bug was opened for this at https://bz.apache.org/bugzilla/show_bug.cgi?id=59313

There are two layers to this: 
1. How the working group(s) sort out who defines what.
2. Backward compatible configurations and fixes in Apache httpd implementation

For 2., discussion should happen at the bug report mentioned.

For 1., depending on the outcome, I will adjust my implementation. As I understand the specs, httpd currently exposes the HTTP protocol in the SERVER_PROTOCOL as defined in RFC 7540. I read the format definition in RFC 3875 as advisory and being outdated now (in my opinion never a good idea to define the format there - hindsight wisdom).

Should the consensus become that SERVER_PROTOCOL needs to expose "HTTP/2.0", I will adapt our implementation. However in all other places httpd will continue to advertise "HTTP/2".

-Stefan

> Am 12.04.2016 um 18:26 schrieb Mike Bishop <[email-masked]>:
>