- From: David Krauss <potswa@gmail.com>
- Date: Sat, 10 May 2014 16:01:04 +0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 2014–05–10, at 3:36 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2014-05-10 05:08, David Krauss wrote: >> >> On 2014–05–09, at 2:16 PM, Julian Reschke <julian.reschke@gmx.de> wrote: >> >>> The question about a safe method that allows a request body comes up over and over, and right now people use POST for it. If we ever define that method, it won't be supported in HTTP2 push. >> >> Can you clarify? Pushes eliminate (or “skip over”) the request by definition. Pushing a redirect or error simply anticipates a client request with such a response. POST (or anything with a request body) would usually bypass prior PUSH_PROMISEs along with the rest of the cache. An exception to this rule could be defined in HTTP/2 using multiple header blocks, and perhaps segmentation: push the request, then the response. But, it would have to be an application-specific extension for now. > > I'm not sure *what* needs to be clarified. Can you clarify? Well, I already did. The above paragraph explains that PUSH_PROMISE does not allocate a spot for any part of a request, never mind the request body. I also propose a solution to the problem. > The use case is pushing responses for safe requests that *do* have q request body, such as a directory update (PROPFIND). What do you think such a push would look like? Perhaps a progressive change-set? What need is there for a fake request body, if the response already identifies the changed properties? Specific application protocols will need to refine their caching schemes to fit pushing.
Received on Saturday, 10 May 2014 08:01:40 UTC