Re: PUSH Clarifications

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

2) What does it mean when a server sends:

  a. PUSH_PROMISE(:method=DELETE) ?
  b. PUSH_PROMISE(:method=PATCH) ?
  c. PUSH_PROMISE(:method=PUT) ?

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.


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

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

That said, thinking about it further... in certain situations, a case
could certainly be made for sending a push resource along with a 3xx
response so I'm not 100% against that.. For instance, I could send a
3xx response and immediately push the resource I'm redirecting you
too...

HEADERS
  :status = 302
  location = /images/jpg

PUSH_PROMISE
  :method = GET
  :path = /images/jpg

...

This would actually be a fairly interesting use of pushed resources so
will have to give more thought to that one.

- James

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

Received on Monday, 5 August 2013 21:38:55 UTC