Re: [Editorial Errata Reported] RFC7230 (4205)

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 <barryleiba@computer.org>:
>> 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
>

Received on Wednesday, 14 January 2015 08:12:29 UTC