Re: PUSH Clarifications

On 2013-08-05 23:38, James M Snell wrote:
> On Mon, Aug 5, 2013 at 2:13 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> On 2013-08-05 19:21, James M Snell wrote:
>>>
>>> Saw the comments in the github repo issues regarding PUSH and safe
>>> methods discussed in Hamburg... I gave some comments over there, but
>>> given that it affects technical design and not just editorial, I
>>> wanted to echo those same comments here on list...
>>>
>>> I'm not 100% sure where the conversation ended up in Hamburg, but.. in
>>> my opinion.. a PUSH...
>>>
>>> 1) Ought to ALWAYS be either an implied GET or HEAD, sending a
>>> PUSH_PROMISE with a :method header field that specifies anything other
>>> than GET or HEAD ought to be a stream error. This keeps things as
>>> simple as possible without forcing us to get into dealing with
>>> possibly weird edge cases caused by unknown extension methods.
>>
>>
>> Such as?
>>
>
> 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.

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

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

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

> ...

Best regards, Julian

Received on Monday, 5 August 2013 21:57:13 UTC