- From: Semyon Kholodnov <joker.vd@gmail.com>
- Date: Tue, 23 Dec 2014 17:15:19 +0000
- To: Barry Leiba <barryleiba@computer.org>
- Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Roy Fielding <fielding@gbiv.com>, Julian Reschke <julian.reschke@greenbytes.de>, Pete Resnick <presnick@qti.qualcomm.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
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. 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. 2014-12-23 18:39 GMT+03:00, Barry Leiba <barryleiba@computer.org>: > 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 > <rfc-editor@rfc-editor.org> 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 <joker.vd@gmail.com> >> >> 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 >> >
Received on Wednesday, 14 January 2015 08:12:26 UTC