RE: PUSH Clarifications

For the #2 discussion, you're wandering into extension territory.  If we're dealing with unextended HTTP, HEAD and GET are the only safe methods, so the statements you're comparing are equivalent.  If there's an extension which defines a new HTTP method, there needs to be a means of determining that both sides of the exchange support that extension before attempting to use it.  If both sides have agreed that a new method FOO exists and is safe, then it should logically be pushable.  If only the server knows about it, then obviously the client wouldn't understand seeing it in a PUSH_PROMISE.

However, receiving the PUSH_PROMISE shouldn't be the first time the existence and use of FOO is disclosed; this gets into the question of how clients and servers negotiate the use of extensions which may add new methods, frame types, etc.  Your respective arguments presuppose some answers to that question which hasn't been seriously discussed yet.

-----Original Message-----
From: James M Snell [mailto:jasnell@gmail.com] 
Sent: Monday, August 5, 2013 3:16 PM
To: Julian Reschke
Cc: ietf-http-wg@w3.org
Subject: 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 23:19:29 UTC