Re: PUSH Clarifications

On Mon, Aug 5, 2013 at 10:51 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2013-08-06 00:15, James M Snell wrote:
>>
>> ...
>>
>> Oh right.. then how about PUSH_PROMISE(:method=FOO) ? ... I know,
>> gotta go check the registry because there is no reliable means of
>> determining if some method is safe at runtime...
>>
>> The end result ends up being: the only methods that an implementation
>> can absolutely guarantee will work with server push are GET and HEAD
>> given that those are the only ones that we know for certain are
>> safe... so why not just make it clear up front: a push is always an
>
>
> Wrong.
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-method-registrations-11.html#updated.registry.contents>
>

Well... yes, there are the PROPFIND, SEARCH and REPORT methods which
are both safe and idempotent... however, given that PUSH_PROMISE gives
us no means of sending an implied payload along with the implied
request headers, the utility of pushing those is almost comically
questionable... which brings us back to my original point: GET and
HEAD are the only ones that really make any sense given any of the
presented use cases for server push.

Martin says we don't want to preclude uses that are OK in theory... To
which I'd respond: Ok, give me even a theoretical use case that makes
sense. I'm not interested in "Someone, someday, might find some
theoretical, hypothetical case where pushing something other that GET
or HEAD might be marginally useful, maybe" type of arguments.

- James

>> ...
>>
>>>> If PUSH_PROMISE is viewed primarily as a means of preemptively
>>>> delivering content that the server expects the user-agent to request
>>>> (which is the key use case presented thus far), then it makes sense
>>>> that pushed resources are always only implied GET or HEAD requests.
>>>> None of the other methods make any sense.
>>>
>>>
>>>
>>> How would you know without knowing the method semantics of all future
>>> methods?
>>>
>>
>> (a) If and when such methods emerge and (b) if and when such methods
>> are implemented we can deal with the possible push ramifications at
>
>
> So when FOO is defined and useful we need to update the HTTP/2.0 spec and
> change the *framing*? Sounds like a big failure to properly define an
> extension point to me.
>
>
>> that time. For now, GET and HEAD are the only ones that I can see that
>> make sense given the only use cases that have been put on the table.
>
>
> I hear you but I disagree.
>
>> ...
>
>
> Best regards, Julian
>

Received on Tuesday, 6 August 2013 16:07:50 UTC