Re: [#193] Request payloads and push

On Aug 13, 2013 11:34 AM, "Mike Belshe" <mike@belshe.com> wrote:
>
>
>
>
> On Tue, Aug 13, 2013 at 12:00 AM, William Chan (陈智昌) <
willchan@chromium.org> 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)

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.

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

>
>
> Mike
>
>
>>
>>
>> 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?
>>
>>
>> On Tue, Aug 13, 2013 at 4:47 AM, Mike Belshe <mike@belshe.com> wrote:
>>>
>>>
>>>
>>>
>>> On Mon, Aug 12, 2013 at 7:42 PM, James M Snell <jasnell@gmail.com>
wrote:
>>>>
>>>> +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.
>>>
>>>
>>> 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
>>>
>>>
>>>>
>>>>
>>>> On Mon, Aug 12, 2013 at 7:00 PM, Mike Belshe <mike@belshe.com> wrote:
>>>> > 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
>>>> >
>>>> >
>>>> >
>>>> > On Mon, Aug 12, 2013 at 12:49 PM, James M Snell <jasnell@gmail.com>
wrote:
>>>> >>
>>>> >> 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
>>>> >>
>>>> >> On Mon, Aug 12, 2013 at 12:01 PM, Martin Thomson
>>>> >> <martin.thomson@gmail.com> wrote:
>>>> >> > 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!
>>>> >> >
>>>> >>
>>>> >
>>>
>>>
>>
>