Subject: [quicwg/base-drafts] It's annoying that one can't send push in 0.5RTT (#2227)

From: ekr <[email-masked]>
Date: Thu, 20 Dec 2018 15:07:10 -0800

S 5.4.

```
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.
```

This seems not ideal. Could we put a default in transport parameters
or the like.

-- 
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/2227

---

From: afrind <[email-masked]>
Date: Thu, 20 Dec 2018 16:19:22 -0800

As push is currently designed, a server can't push until it receives a request.  The MAX_PUSH_ID frame can arrive in the same flight as the request.

-- 
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/2227#issuecomment-449185180

---

From: ekr <[email-masked]>
Date: Thu, 20 Dec 2018 16:24:13 -0800

This seems like something we should remove, given that it's worth a full RT.

-- 
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/2227#issuecomment-449186062

---

From: afrind <[email-masked]>
Date: Thu, 20 Dec 2018 16:43:40 -0800

@ekr I'm not sure what you are asking be removed.  Are you suggesting the server should be able to send a push without a request, or something else?  

-- 
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/2227#issuecomment-449189507

---

From: ekr <[email-masked]>
Date: Thu, 20 Dec 2018 16:45:08 -0800

On Thu, Dec 20, 2018 at 4:43 PM afrind <[email-masked]> wrote:

> @ekr <https://github.com/ekr> I'm not sure what you are asking be
> removed. Are you suggesting the server should be able to send a push
> without a request,
>

Yes

or something else?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/2227#issuecomment-449189507>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1of1pAy0pjHnpunLxdnqVak6D4NLuks5u7C66gaJpZM4ZdDxb>
> .
>

-- 
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/2227#issuecomment-449189947

---

From: afrind <[email-masked]>
Date: Thu, 20 Dec 2018 16:48:39 -0800

That's not part of the HTTP/2 push design.  I agree that it would be a nice feature, but perhaps it's out of charter/scope for v1?

-- 
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/2227#issuecomment-449191304

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 20 Dec 2018 16:48:53 -0800

While I understand the concern, I would prefer to not change the semantics of push at this point (especially considering the fact that the design comes from H2).

@ekr 
> Could we put a default in transport parameters or the like.

Looking at #436, it seems like we concluded to not? I remember myself arguing for exchanging HTTP-level settings using Transport Parameters, but people preferred the other way.

-- 
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/2227#issuecomment-449191385

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Dec 2018 20:07:00 -0800

We discussed pushes without a request as context in h2, and concluded that they were very difficult.  Using the request as context is what made it possible to support push at all in cases where there are multiple users of the same connection (a common occurrence).

I can see how using 0.5 RTT for pushing some content is appealing, such as origin policy, favicons, or other such common resources.  However, I see that as an entirely new feature.

-- 
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/2227#issuecomment-449238933

---

From: MikkelFJ <[email-masked]>
Date: Fri, 21 Dec 2018 01:52:15 -0800

Doesn't push risk pushing a lot of data that is already client cached?

-- 
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/2227#issuecomment-449337783

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 21 Dec 2018 14:25:14 -0800

I prototyped request-less push based on the design described here https://tools.ietf.org/html/draft-pardue-quic-http-unbound-server-push-01. Just allow PUSH_PROMISE on a new type of unidirectional stream. Since that was a semantic extension, it needs a SETTING, so you're still stuffed. If it was in the core docs, the story is different.

While its something we can do more easily in QUIC, I'm not convinced if we should.

-- 
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/2227#issuecomment-449513454

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Dec 2018 22:13:56 -0800

Yeah, settings doesn't cut it here.  You need a new version.

-- 
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/2227#issuecomment-449690996