Re: [#193] Request payloads and push

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)


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

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



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