Subject: Re: [Editorial Errata Reported] RFC7230 (4205)

From: Semyon Kholodnov <[email-masked]>
Date: Tue, 23 Dec 2014 19:07:43 +0000

Probably I am wrong, but the preceding paragraphs do not talk about
request-response pairs:

   HTTP/1.1 defaults to the use of "persistent connections", allowing
   multiple requests and responses to be carried over a single
   connection.  The "close" connection option is used to signal that a
   connection will not persist after the current request/response.  HTTP
   implementations SHOULD support persistent connections.

   A recipient determines whether a connection is persistent or not
   based on the most recently received message's protocol version and
   Connection header field (if any)

Perhaps I am just getting the wrong impression, but "current
request/response" without word "pair", the usage of "recipient
determines" and "most recently received message's ..." heavily imply,
in my opinion, that the connection's persistence is updated on
per-message basis instead of per-request-and-response-pair basis.

And the recepient of the HTTP/1.0-response ("The terms "sender" and
"recipient" refer to any implementation that sends or receives a given
message, respectively") is the proxy that initiated the request. So
when it receives this response, it has to close the connection, since
this response is the "most recently received message" and it falls
under the third bullet. Because the recipient of the response is the
proxy. If the response had "Connection: close" header, it would fall
under the first bullet, not the fouth one.

Though I agree that maybe I just read words in the way incompatible
with most of other implementers, and I too would like hear someone
else on the matter.

2014-12-23 20:21 GMT+03:00, Barry Leiba <[email-masked]>:
>> that the rules prohibit the following scenario: an HTTP/1.1 proxy
>> sends an HTTP/1.1-request to an HTTP/1.0-server (the proxy knows  by
>> some means that the server is an origin server of HTTP/1.0 version)
>> with "Connection: keep-alive" header, the server sends an
>> HTTP/1.0-response with "Connection: keep-alive" header in it.
>>
>> This response is current, and the bullets mandate that the connection
>> will close after receiving it: the first bullet doesn't apply since
>> the "close" option is not present, second bullet doesn't apply because
>> the received protocol is HTTP/1.0, the third bullet does not apply
>> since the recipient *is* a proxy, and thus the final bullet "The
>> connection will close after the current response" applies.
>
> I think you're wrong, and I was trying to convey that before.  The
> third bullet does apply, because the recipient is not a proxy: it's a
> server.  The initiator is a proxy; the recipient is not.  These
> bullets are talking about request/response transactions, not about
> individual response messages.  I think that's made clear in the
> paragraphs that precede the bullets.
>
> Roy and Julian should, of course, weigh in on this, though.
>
> Barry
>

---

From: Semyon Kholodnov <[email-masked]>
Date: Tue, 23 Dec 2014 17:15:19 +0000

I was not talking about the danger of an HTTP/1.1-proxy sending the
request and then immediately closing the connection. I was talking
that the rules prohibit the following scenario: an HTTP/1.1 proxy
sends an HTTP/1.1-request to an HTTP/1.0-server (the proxy knows  by
some means that the server is an origin server of HTTP/1.0 version)
with "Connection: keep-alive" header, the server sends an
HTTP/1.0-response with "Connection: keep-alive" header in it.

2014-12-23 18:39 GMT+03:00, Barry Leiba <[email-masked]>:
> I don't see the problem here.  You do have to read the paragraphs
> before the bullet list, which clearly talk about the request/response
> pair -- there's no danger of reading this to mean that a connection
> will be closed between the two.  Apart from that, no, this bullet is
> not meant to introduce the later "MUST NOT"; these bullets clearly
> state the conditions under which connections remain persistent,
> independent of other advice about how to make that happen.
>
> Roy or Julian, do you see a need for any change here?
>
> Barry
>
> On Tue, Dec 23, 2014 at 9:16 AM, RFC Errata System
> <[email-masked]> wrote:
>> The following errata report has been submitted for RFC7230,
>> "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=7230&eid=4205
>>
>> --------------------------------------
>> Type: Editorial
>> Reported by: Semyon Kholodnov <[email-masked]>
>>
>> Section: 6.3
>>
>> Original Text
>> -------------
>>    o  If the received protocol is HTTP/1.0, the "keep-alive" connection
>>       option is present, the recipient is not a proxy, and the recipient
>>       wishes to honor the HTTP/1.0 "keep-alive" mechanism, the
>>       connection will persist after the current response; otherwise,
>>
>> Corrected Text
>> --------------
>>    o  If the received protocol is HTTP/1.0, the "keep-alive" connection
>>       option is present, either the recipient is not a proxy or the
>>       message is a response, and the recipient wishes to honor the
>>       HTTP/1.0 "keep-alive" mechanism, the connection will persist after
>>       the current response; otherwise,
>>
>> Notes
>> -----
>> This bullet is clearly intended to be there to introduce "A proxy server
>> MUST NOT maintain a persistent connection with an HTTP/1.0 client"
>> requirement later in the text; however, as it's worded, it technically
>> also prohibits HTTP/1.1-proxies to maintain a persistent connection with
>> an HTTP/1.0 *server*.
>>
>> 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.
>>
>> --------------------------------------
>> RFC7230 (draft-ietf-httpbis-p1-messaging-26)
>> --------------------------------------
>> Title               : Hypertext Transfer Protocol (HTTP/1.1): Message
>> Syntax and Routing
>> Publication Date    : June 2014
>> Author(s)           : R. Fielding, Ed., J. Reschke, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : Hypertext Transfer Protocol Bis
>> Area                : Applications
>> Stream              : IETF
>> Verifying Party     : IESG
>>
>