- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 06 Aug 2013 07:51:37 +0200
- 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 Wrong. <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-method-registrations-11.html#updated.registry.contents> > ... >>> 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