Define a Push ID

draft-ietf-quic-http.md

@@ -475,13 +475,13 @@ The PRIORITY frame payload has the following fields:
 
   Prioritized Request:
   : A 32-bit identifier for a request.  This contains the stream ID of a request
-    stream when the PUSH_PRIORITIZED flag is clear, or a push ID when the PUSH
+    stream when the PUSH_PRIORITIZED flag is clear, or a Push ID when the PUSH
     flag is set.
 
   Stream Dependency:
   : A 32-bit stream identifier for a dependent request.  This contains the
     stream ID of a request stream when the PUSH_DEPENDENT flag is clear, or a
-    push ID when the PUSH_DEPENDENT flag is set.  A request stream ID of 0
+    Push ID when the PUSH_DEPENDENT flag is set.  A request stream ID of 0
     indicates a dependency on the root stream. For details of dependencies,
     see {{priority}} and {!RFC7540}}, Section 5.3).
 
@@ -670,7 +670,7 @@ the defaults above on the next connection.
 ### PUSH_PROMISE {#frame-push-promise}
 
 The PUSH_PROMISE frame (type=0x05) is used to carry a request header set from
-server to client, as in HTTP/2.  It defines no flags.
+server to client, as in HTTP/2.  The PUSH_PROMISE frame defines no flags.
 
 ~~~~~~~~~~  drawing
     0                   1                   2                   3
@@ -694,12 +694,19 @@ Push ID:
 Header Block:
 : HPACK-compressed request headers for the promised response.
 
-A server MAY use the same push ID in multiple PUSH_PROMISE frames.  This allows
+A server MAY use the same Push ID in multiple PUSH_PROMISE frames.  This allows
 the server to use the same server push in response to multiple concurrent
 requests.  Referencing the same server push ensures that a PUSH_PROMISE can be
 made in relation to every response in which server push might be needed without
 causing duplicating pushes.
 
+A server that uses the same Push ID in multiple PUSH_PROMISE frames MUST include
+the same header fields each time.  The octets of the header block MAY be
+different due to differing encoding, but the header fields and their values MUST
+be identical.  Note that ordering of header fields is significant.  A client
+MUST treat receipt of a PUSH_PROMISE with conflicting header field values for
+the same Push ID as a connection error of type HTTP_MALFORMED_PUSH_PROMISE.
+
 A server SHOULD avoid sending a PUSH_PROMISE that includes a Push ID that was
 fulfilled prior to the request being made.  Though a client needs to handle
 receiving a promised response prior to it being promised due to reordering of