Subject: [#193] Request payloads and push

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Aug 2013 20:01:36 +0100

There's been something of a long thread on github about this topic,
that Will was unsuccessful in moving over here.  Let me try again.

https://github.com/http2/http2-spec/issues/193

Julian summarized the issue quite cogently as:
> [...] HTTP/1.1 allows safe methods with payload, so if we decide that
> in HTTP/2.0 we want to allow PUSH for safe methods, we shouldn't
> rule out that they could have payloads.

I'm just going to throw out the obvious counter argument here, namely:

HTTP/2.0 doesn't allow push for safe methods, it allows push for safe
methods that do not have request bodies.

And then we see what happens.  Commence!

---

From: Roberto Peon <[email-masked]>
Date: Mon, 12 Aug 2013 12:42:20 -0700

Sounds fine by me.

As currently spec'd, PUSH_PROMISE must be followed by HEADERS on the
reserved stream. This requirement allows for a potential future
modification whereby DATA frames on the reserved stream, received before a
HEADERS frame could be interpreted as the body of the request payload. This
"smells" ugly to me.

If we decide to deploy on something like SCTP, and this mapping is
difficult (perhaps because we wish to continue to use a compressor that
requires in-order processing, as most would), then instead a flag
indicating that the data frames are part of the request payload would be
reasonable. This also "smells" ugly to me.

Another potential method of making this work is that PUSH_PROMISE has a
flag, which if set, indicates that a request body is present, which also
changes the size of the PUSH_PROMISE to indicate another stream-id, which
is the reserved-stream for the request-body. Also ugly, but at least it is
more up-front about the ugly.

In any case, any of the potential changes above feel like significant
increases in complexity.
Do we have use-cases for pushing-a-request-body that would show improvement
in some dimension commensurate with the complexity?
I can't think of any, but I'm not as well versed in such esoteric methods...

-=R

---

From: James M Snell <[email-masked]>
Date: Mon, 12 Aug 2013 12:49:01 -0700

FWIW, had a thread on this already on list...

  http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/0624.html

My POV: push streams ought to be limited strictly to GET or HEAD. Period.

- James

---

From: James M Snell <[email-masked]>
Date: Mon, 12 Aug 2013 12:52:36 -0700

On Mon, Aug 12, 2013 at 12:42 PM, Roberto Peon <[email-masked]> wrote:
> [snip]
>[snip]

One example given in the previous thread on this topic was pushing a
WebDAV PROPFIND, which is a safe/idempotent request that bears a
payload. I personally don't find this case interesting at all,
however, and it certainly isn't compelling enough to justify the
additional complexity.

- James

> -=R
>
>
> On Mon, Aug 12, 2013 at 12:01 PM, Martin Thomson <[email-masked]>
> wrote:
>>

---

From: Mike Belshe <[email-masked]>
Date: Mon, 12 Aug 2013 19:00:59 -0700

I agree with James, except I'd limit this to GET only.

Every method we support creates one more little caveat for implementors.
 And when we have zero use cases defined it just doesn't make sense to me.
  The original design behind PUSH was for GET, so let's stick to that until
there is a clear need.

Mike

---

From: James M Snell <[email-masked]>
Date: Mon, 12 Aug 2013 19:42:12 -0700

+1... the *only* case I would extend it to HEAD is if the originating
request is HEAD, which does have a fairly clear use case... and makes
sense in principle.

---

From: Mike Belshe <[email-masked]>
Date: Mon, 12 Aug 2013 19:47:19 -0700

> request is HEAD, which does have a fairly clear use case... and makes

I hear you.  But it just seems like feature creep.  If you're issuing HEAD
requests, you're clearly not that interested in low latency anyway.  And
PUSH is about reducing latency of web pages.  So.... do we need this?

Mike

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 13 Aug 2013 09:00:08 +0200

I'd like to see us be able to push CORS responses so we can remove the HTTP
request roundtrip. Note that CORS uses the OPTIONS method.

I'm trying to think up situations where it'd be unacceptable to push a full
GET instead of just the headers in a HEAD response. For conditional GETs
for cache validation requests, which is the primary use case I have in
mind, I think pushing a 304 GET response is just fine.

Roberto, do you remember if we discussed any other use case where we
required just headers and it'd be costly to update the body?

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Aug 2013 10:16:53 +0200

> And then we see what happens.  Commence!

Both are statements of fact.

My point is that unless we have a very good reason to disallow something 
possible in HTTP/1.1, we shouldn't.

If we do, people will find workarounds, such as pushing a base64 
representation of the payload into a (probably ad-hoc) request header field.

Best regards, Julian

---

From: Mike Belshe <[email-masked]>
Date: Tue, 13 Aug 2013 02:34:03 -0700

On Tue, Aug 13, 2013 at 12:00 AM, William Chan (陈智昌)
<[email-masked]>wrote:

> I'd like to see us be able to push CORS responses so we can remove the
> HTTP request roundtrip. Note that CORS uses the OPTIONS method.
>

I don't think this works - I don't believe the OPTIONS request is required
to carry the query string, so you wouldn't know what response to push.
 (pls double check on the query string, but I think I'm right)

>
> I'm trying to think up situations where it'd be unacceptable to push a
> full GET instead of just the headers in a HEAD response. For conditional
> GETs for cache validation requests, which is the primary use case I have in

To be clear, you've got a resource A, which references static resources B &
C, and you want to push the HEAD responses to B & C as part of the response
for A.  Is that correct?

I admit this is kinda cool; but also observe that the performance savvy can
do this with HTTP today:  use expires headers & versioned URLs for B & C.
 I hate to add the need to push HEAD responses when the desired result can
already be accomplished without it; but I do recognize that naive pages
often run into the 304-not-modified trap.

Mike

>> I hear you.  But it just seems like feature creep.  If you're issuing
>> HEAD requests, you're clearly not that interested in low latency anyway.
>>  And PUSH is about reducing latency of web pages.  So.... do we need this?
>>
>> Mike
>>
>>
>>
>>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 13 Aug 2013 12:59:56 +0200

On Aug 13, 2013 11:34 AM, "Mike Belshe" <[email-masked]> wrote:
>
>
>
>
> On Tue, Aug 13, 2013 at 12:00 AM, William Chan (陈智昌) <
>
>
> I don't think this works - I don't believe the OPTIONS request is
required to carry the query string, so you wouldn't know what response to
push.  (pls double check on the query string, but I think I'm right)

Never heard that (and I'm a bit unclear on what you're staying). I may have
been imprecise in my language that led to confusion. I was hoping to push
the preflight response, not the subsequent resource response to the XHR,
although that's an interesting thought too.

>
>
> To be clear, you've got a resource A, which references static resources B
& C, and you want to push the HEAD responses to B & C as part of the
response for A.  Is that correct?

Yep

>
> I admit this is kinda cool; but also observe that the performance savvy
can do this with HTTP today:  use expires headers & versioned URLs for B &
C.  I hate to add the need to push HEAD responses when the desired result
can already be accomplished without it; but I do recognize that naive pages
often run into the 304-not-modified trap.

PermaURLs are great when you control all references to the resource, but if
you want to publish a URL for others to reference and still retain updating
control, that technique isn't so great.

Furthermore, this web perf technique imposes higher burdens on web devs
since it requires updating all references in markup and elsewhere. AFAICT,
pushing these cache validation responses can be done at a web server or
centralized point in application servers, which simplifies deployment and
speeds up far more of the web, not just advanced web devs.

I believe that these benefits, amongst others that caching intermediaries
may care about, are worth the modest increase in spec complexity.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 13 Aug 2013 13:13:42 +0200

> (pls double check on the query string, but I think I'm right)

Could you clarify what you want to have double checked? There are no
special provisions for query strings in "CORS" that I am aware of, and
it would be rather unwise to add any.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Roberto Peon <[email-masked]>
Date: Tue, 13 Aug 2013 08:20:26 -0700

What are the good reasons to restrict this?
One can always ignore a push by RSTing the promised stream.
An endpoint must have logic to do this anyway, so this isn't adding any
more code.

Safe methods without bodies seems fine.

cache invalidations != 304 get.
-=R