Subject: [quicwg/base-drafts] Push promise history to detect conflicting header field values (#1864)

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 17 Oct 2018 06:43:32 -0700

draft-ietf-quic-http-15 has:

```
   []                           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_FRAME.

   Allowing duplicate references to the same Push ID is primarily to
   reduce duplication caused by concurrent requests.  A server SHOULD
   avoid reusing a Push ID over a long period.  Clients are likely to
   consume server push responses and not retain them for reuse over
   time.  Clients that see a PUSH_PROMISE that uses a Push ID that they
   have since consumed and discarded are forced to ignore the
   PUSH_PROMISE.
```

The two paragraphs contradict each other.  The former mandates that a client maintain a history of all push promises in order to detect possible header field conflicts.  The latter suggests that a client does not have to do that.  Which one is it?

The requirement to maintain a history of all push requests is unreasonable.  I suggest that the _MUST_ in the first paragraph above be replaced with a _MAY_.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1864

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 17 Oct 2018 13:55:14 +0000 (UTC)

I agree.

I've never considered this before but now I'm thinking that a client would need to store the non-compressed version of PUSH_PROMISE, in case an instruction elsewhere caused the dynamic table to be modified.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1864#issuecomment-430638016

---

From: Mike Bishop <[email-masked]>
Date: Wed, 17 Oct 2018 09:29:37 -0700

As in other places, the intent isn't to require historical tracking and verification forever, but to require the error if the condition is detected while acknowledging that it might be.  I think, more precisely, what we want is that the client:

- Maintains a list of active promises for which it is still willing to accept an additional reference to the promise, including the uncompressed headers for the promise (likely until the promise is fulfilled, possibly plus a timeout)
- Verifies that the headers match exactly when receiving an additional reference to one of these promises; MUST error if they don't.
- If a promise is received for an ID which has already been flushed from the list, the promise is ignored

This entails more text than just changing MUST to MAY, but is this a more precise description of what we're after?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1864#issuecomment-430697483

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 17 Oct 2018 16:44:17 +0000 (UTC)

With the way @MikeBishop puts it, perhaps it is useful to describe the problem that header field changes might cause, then provide the points on how a client might want to do things to detect and avoid them.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1864#issuecomment-430702446