From 665cb782f3c6f9abdeb9bd8323a1a83c0140da9a Mon Sep 17 00:00:00 2001 From: Lucas Pardue Date: Fri, 29 Jun 2018 21:20:59 +0100 Subject: [PATCH 1/5] Server push tidy up Removed a bit of duplication. Reordered text to match ordering of server push (PUSH_PROMISE and then push stream). --- draft-ietf-quic-http.md | 77 +++++++++++++++++++---------------------- 1 file changed, 36 insertions(+), 41 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 6386b1e94b..1908604336 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -506,7 +506,7 @@ the peer's discretion (see {{errors}}). ### Control Streams The control stream is indicated by a stream type of `0x43` (ASCII 'C'). Data on -this stream consists of HTTP frames, as defined in {{frames}}. +this stream consists of HTTP/QUIC frames, as defined in {{frames}}. Each side MUST initiate a single control stream at the beginning of the connection and send its SETTINGS frame as the first frame on this stream. Only @@ -522,16 +522,32 @@ able to send stream data first after the cryptographic handshake completes. ### Server Push -HTTP/QUIC server push is similar to what is described in {{!RFC7540}}, but uses -different mechanisms. During connection establishment, the client enables server -push by sending a MAX_PUSH_ID frame (see {{frame-max-push-id}}). A server cannot -use server push until it receives a MAX_PUSH_ID frame. Only servers can push; -if a server receives a client-initiated push stream, this MUST be treated as a -stream error of type HTTP_WRONG_STREAM_DIRECTION. +HTTP/QUIC server push is similar to what is described in HTTP/2 {{!RFC7540}}, +but uses different mechanisms. + +The PUSH_PROMISE frame ({{frame-push-promise}}) is sent on the client-initiated +bidirectional stream that carried the request that generated the push. This +allows the server push to be associated with a request. Ordering of a PUSH_PROMISE +in relation to certain parts of the response is important (see Section 8.2.1 of +{{!RFC7540}}). + +The PUSH_PROMISE frame does not reference a stream; it contains a Push ID that +uniquely identifies a server push. This allows a server to fulfill promises in +the order that best suits its needs. The same Push ID can be used in multiple +PUSH_PROMISE frames (see {{frame-push-promise}}). When a server later fulfills +a promise, the server push response is conveyed on a push stream. A push stream is indicated by a stream type of `0x50` (ASCII 'P'), followed by the Push ID of the promise that it fulfills, encoded as a variable-length -integer. +integer. The remaining data on this stream consists of HTTP/QUIC frames, as defined +in {{frames}}, and carries the response side of an HTTP message exchange as +described in {{request-response}}. The request headers of the exchange are +carried by a PUSH_PROMISE frame (see {{frame-push-promise}}) on the request +stream which generated the push. Promised requests MUST conform to the +requirements in Section 8.2 of {{!RFC7540}}. + +Only servers can push; if a server receives a client-initiated push stream, this +MUST be treated as a stream error of type HTTP_WRONG_STREAM_DIRECTION. ~~~~~~~~~~ drawing 0 1 2 3 @@ -542,45 +558,24 @@ integer. ~~~~~~~~~~ {: #fig-push-stream-header title="Push Stream Header"} -Unlike HTTP/2, the PUSH_PROMISE does not reference a stream; it contains a Push -ID. The Push ID uniquely identifies a server push. This allows a server to -fulfill promises in the order that best suits its needs. When a server later -fulfills a promise, the server push response is conveyed on a push stream. +Server push is only enabled on a connection when a client sends a MAX_PUSH_ID +frame (see {{frame-max-push-id}}). A server cannot use server push +until it receives a MAX_PUSH_ID frame. A client sends additional MAX_PUSH_ID +frames to control the number of pushes that a server can promise. A server SHOULD +use Push IDs sequentially, starting at 0. A client MUST treat receipt of a push +stream with a Push ID that is greater than the maximum Push ID as a connection +error of type HTTP_PUSH_LIMIT_EXCEEDED. -A server SHOULD use Push IDs sequentially, starting at 0. A client uses the -MAX_PUSH_ID frame ({{frame-max-push-id}}) to limit the number of pushes that a -server can promise. A client MUST treat receipt of a push stream with a Push ID -that is greater than the maximum Push ID as a connection error of type -HTTP_PUSH_LIMIT_EXCEEDED. - -The remaining data on this stream consists of HTTP frames, as defined in -{{frames}}, and carries the response side of an HTTP message exchange as -described in {{request-response}}. The request headers of the exchange are -carried by a PUSH_PROMISE frame (see {{frame-push-promise}}) on the request -stream which generated the push. Promised requests MUST conform to the -requirements in Section 8.2 of {{!RFC7540}}. - -The PUSH_PROMISE frame is sent on the client-initiated bidirectional stream -that carried the request that generated the push. This allows the server push -to be associated with a request. Ordering of a PUSH_PROMISE in relation to -certain parts of the response is important (see Section 8.2.1 of {{!RFC7540}}). +Each Push ID MUST only be used once in a push stream header. If a push stream header +includes a Push ID that was used in another push stream header, the client MUST +treat this as a connection error of type HTTP_DUPLICATE_PUSH. If a promised server push is not needed by the client, the client SHOULD send a -CANCEL_PUSH frame; if the push stream is already open, a QUIC STOP_SENDING frame +CANCEL_PUSH frame. If the push stream is already open, a QUIC STOP_SENDING frame with an appropriate error code can be used instead (e.g., HTTP_PUSH_REFUSED, -HTTP_PUSH_ALREADY_IN_CACHE; see {{errors}}). This asks the server not to +HTTP_PUSH_ALREADY_IN_CACHE; see {{errors}}). This asks the server not to transfer the data and indicates that it will be discarded upon receipt. -Push streams always begin with a header containing the Push ID. Each Push ID -MUST only be used once in a push stream header. If a push stream header -includes a Push ID that was used in another push stream header, the client MUST -treat this as a connection error of type HTTP_DUPLICATE_PUSH. The same Push ID -can be used in multiple PUSH_PROMISE frames (see {{frame-push-promise}}). - -After the header, a push stream contains a response ({{request-response}}), -with response headers, a response body (if any) carried by DATA frames, then -trailers (if any) carried by HEADERS frames. - # HTTP Framing Layer {#http-framing-layer} From c4dba3b4419b8fbc0b35be626cd0b2aeb0d0934e Mon Sep 17 00:00:00 2001 From: Lucas Pardue Date: Fri, 29 Jun 2018 21:28:05 +0100 Subject: [PATCH 2/5] My kingdom for an --- draft-ietf-quic-http.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 1908604336..48ce97d395 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -535,7 +535,7 @@ The PUSH_PROMISE frame does not reference a stream; it contains a Push ID that uniquely identifies a server push. This allows a server to fulfill promises in the order that best suits its needs. The same Push ID can be used in multiple PUSH_PROMISE frames (see {{frame-push-promise}}). When a server later fulfills -a promise, the server push response is conveyed on a push stream. +a promise, the server push response is conveyed on a push stream. A push stream is indicated by a stream type of `0x50` (ASCII 'P'), followed by the Push ID of the promise that it fulfills, encoded as a variable-length From c4bc704a01e99870e06ddda222540a409a460604 Mon Sep 17 00:00:00 2001 From: Lucas Pardue Date: Fri, 29 Jun 2018 21:30:39 +0100 Subject: [PATCH 3/5] an online editor that doesn't suck --- draft-ietf-quic-http.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 48ce97d395..870ad4d288 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -566,9 +566,9 @@ use Push IDs sequentially, starting at 0. A client MUST treat receipt of a push stream with a Push ID that is greater than the maximum Push ID as a connection error of type HTTP_PUSH_LIMIT_EXCEEDED. -Each Push ID MUST only be used once in a push stream header. If a push stream header -includes a Push ID that was used in another push stream header, the client MUST -treat this as a connection error of type HTTP_DUPLICATE_PUSH. +Each Push ID MUST only be used once in a push stream header. If a push stream +header includes a Push ID that was used in another push stream header, the client +MUST treat this as a connection error of type HTTP_DUPLICATE_PUSH. If a promised server push is not needed by the client, the client SHOULD send a CANCEL_PUSH frame. If the push stream is already open, a QUIC STOP_SENDING frame From 59a94215be8d02cb8f378a0286132a10d281329f Mon Sep 17 00:00:00 2001 From: Lucas Pardue Date: Fri, 29 Jun 2018 21:35:45 +0100 Subject: [PATCH 4/5] 80 wasn't enough for me --- draft-ietf-quic-http.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 870ad4d288..8fa19d7b64 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -527,9 +527,9 @@ but uses different mechanisms. The PUSH_PROMISE frame ({{frame-push-promise}}) is sent on the client-initiated bidirectional stream that carried the request that generated the push. This -allows the server push to be associated with a request. Ordering of a PUSH_PROMISE -in relation to certain parts of the response is important (see Section 8.2.1 of -{{!RFC7540}}). +allows the server push to be associated with a request. Ordering of a +PUSH_PROMISE in relation to certain parts of the response is important (see +Section 8.2.1 of {{!RFC7540}}). The PUSH_PROMISE frame does not reference a stream; it contains a Push ID that uniquely identifies a server push. This allows a server to fulfill promises in @@ -539,12 +539,12 @@ a promise, the server push response is conveyed on a push stream. A push stream is indicated by a stream type of `0x50` (ASCII 'P'), followed by the Push ID of the promise that it fulfills, encoded as a variable-length -integer. The remaining data on this stream consists of HTTP/QUIC frames, as defined -in {{frames}}, and carries the response side of an HTTP message exchange as -described in {{request-response}}. The request headers of the exchange are -carried by a PUSH_PROMISE frame (see {{frame-push-promise}}) on the request -stream which generated the push. Promised requests MUST conform to the -requirements in Section 8.2 of {{!RFC7540}}. +integer. The remaining data on this stream consists of HTTP/QUIC frames, as +defined in {{frames}}, and carries the response side of an HTTP message +exchange asdescribed in {{request-response}}. The request headers of the +exchange are carried by a PUSH_PROMISE frame (see {{frame-push-promise}}) +on the request stream which generated the push. Promised requests MUST +conform to the requirements in Section 8.2 of {{!RFC7540}}. Only servers can push; if a server receives a client-initiated push stream, this MUST be treated as a stream error of type HTTP_WRONG_STREAM_DIRECTION. @@ -561,14 +561,14 @@ MUST be treated as a stream error of type HTTP_WRONG_STREAM_DIRECTION. Server push is only enabled on a connection when a client sends a MAX_PUSH_ID frame (see {{frame-max-push-id}}). A server cannot use server push until it receives a MAX_PUSH_ID frame. A client sends additional MAX_PUSH_ID -frames to control the number of pushes that a server can promise. A server SHOULD -use Push IDs sequentially, starting at 0. A client MUST treat receipt of a push -stream with a Push ID that is greater than the maximum Push ID as a connection -error of type HTTP_PUSH_LIMIT_EXCEEDED. +frames to control the number of pushes that a server can promise. A server +SHOULD use Push IDs sequentially, starting at 0. A client MUST treat receipt +of a pushstream with a Push ID that is greater than the maximum Push ID as a +connection error of type HTTP_PUSH_LIMIT_EXCEEDED. Each Push ID MUST only be used once in a push stream header. If a push stream -header includes a Push ID that was used in another push stream header, the client -MUST treat this as a connection error of type HTTP_DUPLICATE_PUSH. +header includes a Push ID that was used in another push stream header, the +client MUST treat this as a connection error of type HTTP_DUPLICATE_PUSH. If a promised server push is not needed by the client, the client SHOULD send a CANCEL_PUSH frame. If the push stream is already open, a QUIC STOP_SENDING frame From 61c5c55aa5bccb1c617c4ed28f2897941bcd19a6 Mon Sep 17 00:00:00 2001 From: Lucas Pardue Date: Fri, 29 Jun 2018 21:37:58 +0100 Subject: [PATCH 5/5] trailing trash --- draft-ietf-quic-http.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 8fa19d7b64..42f4c89ec6 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -527,7 +527,7 @@ but uses different mechanisms. The PUSH_PROMISE frame ({{frame-push-promise}}) is sent on the client-initiated bidirectional stream that carried the request that generated the push. This -allows the server push to be associated with a request. Ordering of a +allows the server push to be associated with a request. Ordering of a PUSH_PROMISE in relation to certain parts of the response is important (see Section 8.2.1 of {{!RFC7540}}). @@ -546,8 +546,8 @@ exchange are carried by a PUSH_PROMISE frame (see {{frame-push-promise}}) on the request stream which generated the push. Promised requests MUST conform to the requirements in Section 8.2 of {{!RFC7540}}. -Only servers can push; if a server receives a client-initiated push stream, this -MUST be treated as a stream error of type HTTP_WRONG_STREAM_DIRECTION. +Only servers can push; if a server receives a client-initiated push stream, +this MUST be treated as a stream error of type HTTP_WRONG_STREAM_DIRECTION. ~~~~~~~~~~ drawing 0 1 2 3