W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: PUSH Clarifications

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 06 Aug 2013 07:51:37 +0200
Message-ID: <52008EE9.8020309@gmx.de>
To: James M Snell <jasnell@gmail.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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


> ...
>>> 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 05:52:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC