[
https://issues.apache.org/jira/browse/MESOS-9189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16596923#comment-16596923
]
Benjamin Mahler commented on MESOS-9189:
----------------------------------------
{quote}
'Connection: close' set by a server is an indicator for the client to close the
connection after receiving the complete response
{quote}
Perhaps this is the root of the confusion, as that's not quite what it means.
See the following from RFC 7230:
In RFC 7230 section 6.1 ("sender" instead of "client" is intentional here, and
in this case of this ticket, the "sender" is the server):
{quote}
The "close" connection option is defined for a sender to signal that
this connection will be closed after completion of the response. For
example,
Connection: close
in either the request or the response header fields indicates that
the sender is going to close the connection after the current
request/response is complete (Section 6.6).
{quote}
In RFC 7230 section 6.6:
{quote}
A server that sends a "close" connection option MUST initiate a close
of the connection (see below) after it sends the response containing
"close". The server MUST NOT process any further requests received
on that connection.
A client that receives a "close" connection option MUST cease sending
requests on that connection and close the connection after reading
the response message containing the "close"; if additional pipelined
requests had been sent on the connection, the client SHOULD NOT
assume that they will be processed by the server.
{quote}
Let's ignore pipelining for now in this discussion as most intermediaries avoid
it as far as I'm aware.
{quote}
Is the hope here is that some middlemen peek into the 'Connection' header and
based on it decide whether to close the connection themselves when their client
disconnects even though the response might not be completed?
{quote}
Yes, in this ticket we're assuming the intermediary does not try to read the
full response before forwarding it. If it did, the streaming API would not work
at all through such an intermediary since the response is infinite. In
addition, intermediaries MUST perform certain actions with the headers before
forwarding the response (e.g. the spec requires intermediaries to look at
'Connection' header before forwarding, see RFC 7230 section 6.1).
In terns of how sending 'Connection: close' will help: an intermediary that
sees this knows that the server MUST initiate a close of the connection upon
finishing sending the response. If the intermediary was planning to re-use the
connection, it knows that cannot when it sees the header (because both the
server MUST close it, and the intermediary MUST cease sending requests on that
connection). If it knows this and it sees the end-client disconnect, its best
choice is to close the connection to the server at that point in time.
> Include 'Connection: close' header in streaming API responses.
> --------------------------------------------------------------
>
> Key: MESOS-9189
> URL: https://issues.apache.org/jira/browse/MESOS-9189
> Project: Mesos
> Issue Type: Improvement
> Components: HTTP API
> Reporter: Benjamin Mahler
> Assignee: Benjamin Mahler
> Priority: Major
>
> We've seen some HTTP intermediaries (e.g. ELB) decide to re-use connections
> to mesos as an optimization to avoid re-connection overhead. As a result,
> when the end-client of the streaming API disconnects from the intermediary,
> the intermediary leaves the connection to mesos open in an attempt to re-use
> the connection for another request once the response completes. Mesos then
> thinks that the subscriber never disconnected and the intermediary happily
> continues to read the streaming events even though there's no end-client.
> To help indicate to intermediaries that the connection SHOULD NOT be re-used,
> we can set the 'Connection: close' header for streaming API responses. It may
> not be respected (since the language seems to be SHOULD NOT), but some
> intermediaries may respect it and close the connection if the end-client
> disconnects.
> Note that libprocess' http server currently doesn't close the the connection
> based on a handler setting this header, but it doesn't matter here since the
> streaming API responses are infinite.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
