Re: PUSH Clarifications

On Mon, Aug 5, 2013 at 2:56 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2013-08-05 23:38, James M Snell wrote:
[snip]
>>
>> 1) Let's say I create two new http methods FOO and BAR. FOO is not
>> safe and is not idempotent. BAR, however, is safe and idempotent. How
>> is does an implementation that is unfamiliar with FOO or BAR determine
>> whether they are safe to PUSH (or safe to accept from as pushed
>> resources?).
>
>
> They check in the method registry. (No, not at runtime)
>
>
>> 2) What does it mean when a server sends:
>>
>>    a. PUSH_PROMISE(:method=DELETE) ?
>>    b. PUSH_PROMISE(:method=PATCH) ?
>>    c. PUSH_PROMISE(:method=PUT) ?
>
>
> Those are not safe.
>

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
implied GET (or HEAD). (I can live with saying that a server can push
:method=HEAD if it wants... the biggest thing for me is that I want it
limited to only GET and HEAD).

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

>
>>>> 2) Ought to only be an implied HEAD request if the originating request
>>>> is also a HEAD request. Otherwise, the PUSH is always a GET.
>>>
>>>
>>>
>>> Why?
>>>
>>
>> See above.
>>
>> Further, if I send a HEAD request, then the assumption ought to be: I
>> only want metadata back, not content, pushed resources ought to also
>> consist only of metadata and not content...
>
>
> With PUSH, isn't it always about the server deferring what the client might
> do next? I agree that HEAD does not imply subsequent GET requests, but then
> why don't we let the server decide?
>

I'm not going to lie down in the road about it but, if the user-agent
wanted content, it would have sent a GET. I would consider it rather
obnoxious of the server to preemptively send something that I might
have had absolutely no intention to request or use... But, like I said
above, I can live with allowing the server to push HEAD or GET so long
as we limit it to those.

>
>>>> 3) Ought to only be sent when the response has a 2xx status code. It
>>>> does not make much sense at all to send a PUSH when the status code is
>>>> [3-5]xx.
>>>
>>>
>>>
>>> I think we discussed and liked an idea of HEAD->304 to update cache meta
>>> data.
>>>
>>
>> That's not what I mean. We have the originating request and response,
>> and N pushed resources. If the response to the originating request is
>> 4xx/5xx there is exceedingly little justification for sending any
>> pushed resources. The response codes used for each of the pushed
>> resources is a separate matter.
>
>
> Why not send a HEAD->404 to inform the client that a resource is gone?
>

Like I said, the :status sent for the push resources is completely
independent of the :status sent for the originating stream. I'm only
talking about the status of the originating stream here. Sure, in
theory, if I GET foo.html that used to link to foo.jpg and receive a
404 saying foo.html is gone, it *might* be marginally useful to also
receive a 404 saying that foo.jpg is also gone, but the utility of
that is tenuous at best (imho of course). (Again, I'm not going to lie
down in the road about it.. I'm just sharing my current opinion on
it.)

- James

>> ...
>
>
> Best regards, Julian

Received on Monday, 5 August 2013 22:16:19 UTC