From 31fea62feac40712165efe8fce03cc0f149e4ac6 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Fri, 3 Feb 2017 11:28:42 +1100 Subject: [PATCH] add operational considerations --- draft-ietf-httpbis-origin-frame.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 5da6eb7a8..422ff5a12 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -229,3 +229,24 @@ The certificate presented by the server is valid for a host if it passes the che would perform when forming a new TLS connection to the origin. This includes verifying that the host matches a `dNSName` value from the certificate `subjectAltName` field (using the wildcard rules defined in {{!RFC2818}}). + + +# Operational Considerations for Servers {#server-ops} + +The ORIGIN frame allows a server to indicate what for origins a given connection ought be used. + +For example, it can be used to inform the client that the connection is to only be used for the +SNI-based origin, by sending an empty ORIGIN frame. Or, a larger number of origins can be indicated +by including a payload. + +Generally, this information is most useful to send before sending any part of a response that might +initiate a new connection; for example, `Link` headers {{?RFC5988}} in a response HEADERS, or links +in the response body. + +Therefore, the ORIGIN frame ought be sent as soon as possible on a connection, ideally before any +HEADERS or PUSH_PROMISE frames. + +However, if it's desirable to associate a large number of origins with a connection, doing so might +introduce end-user perceived latency, due to their size. As a result, it might be necessary to +select a "core" set of origins to send initially, expanding the set of origins the connection is +used for with subsequent ORIGIN frames later (e.g., when the connection is idle).