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

From: Mike Bishop <[email-masked]>
Date: Thu, 29 Nov 2018 11:37:17 -0800

I kind of wish the pushed request headers only got sent once so that this conflict could never occur.  What if we instead had a DUPLICATE_PUSH frame that just includes the Push ID and means "same thing here"? If it arrives before the corresponding PUSH_PROMISE, you have to wait to find out the request headers, but they're hopefully coming soon.

-- 
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-442965141

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 29 Nov 2018 12:15:21 -0800

I like it.

-- 
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-442977756

---

From: Martin Thomson <[email-masked]>
Date: Thu, 29 Nov 2018 14:49:01 -0800

Seems reasonable.

-- 
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-443023134

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 30 Nov 2018 16:16:42 -0800

Consider the sequence of arrival at the client: DUPLICATE_PUSH, response
body with a reference to pushed resource, PUSH_PROMISE. At the time the
client encounters the reference to the pushed resource it will attempt to
request that resource. But since the client does not yet know that a push
promise for that URL is impending, what should it do? It seems like it must
chose between either letting all requests go to the network until the
corresponding PUSH_PROMISE arrives or block all requests from hitting the
network until the PUSH_PROMISE arrives. Neither option seems terribly
satisfying. Is there another option for the client in this situation?

On Thu, Nov 29, 2018 at 2:49 PM Martin Thomson <[email-masked]>
wrote:

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1864#issuecomment-443023134>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ASp6yrwthGBFEO0xZVxa23jImlh6qKkrks5u0GRdgaJpZM4Xj9By>
> .
>

-- 
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-443378680

---

From: Mike Bishop <[email-masked]>
Date: Sat, 01 Dec 2018 00:38:48 +0000 (UTC)

No, it's a trade-off and that's the down-side.  The fact that it's got a DUPLICATE_PUSH *could* cause it to briefly delay requests for URLs it discovers in hopes that the PUSH_PROMISE arrives soon, or perhaps it issues requests and then cancels them when the PUSH_PROMISE arrives.  I'd love to have some first-order hint, like the resource URI, but that's painfully cross-layer.

Of course, the same situation exists today, albeit with lower odds.  If the PUSH_PROMISE headers are blocked in the QPACK encoder, but you choose to buffer the frame so you can keep reading the response, what do you do currently?  If you block reading on the response, that's even worse than failing to send requests to the network....

-- 
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-443381631

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 30 Nov 2018 16:46:53 -0800

On Fri, Nov 30, 2018 at 4:38 PM Mike Bishop <[email-masked]>
wrote:

> No, it's a trade-off and that's the down-side. The fact that it's got a
> DUPLICATE_PUSH *could* cause it to briefly delay requests for URLs it
> discovers in hopes that the PUSH_PROMISE arrives soon, or perhaps it issues
> requests and then cancels them when the PUSH_PROMISE arrives. I'd love to
> have some first-order hint, like the resource URI, but that's painfully
> cross-layer.
>
Fair point. It'd be worth mentioning the client's options in PR#2072, I
think?

> Of course, the same situation exists today, albeit with lower odds. If the
> PUSH_PROMISE headers are blocked in the QPACK encoder, but you choose to
> buffer the frame so you can keep reading the response, what do you do
> currently? If you block reading on the response, that's even worse than
> failing to send requests to the network....
>
We're working feverishly to implement QPACK and wire it up, so we don't
have this problem yet :)

-- 
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-443382600