Re: [#193] Request payloads and push

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?


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