push vs safe methods with payload, Re: END_STREAM flag and trailing headers

On 2014-05-10 10:01, David Krauss wrote:
>
> 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.

Yes, that's the problem. Another simple approach would be to cram the 
payload into a ":payload" header field (and to Vary on that), but what 
I'm looking for is a protocol where we don't need to find workarounds 
for an IMHO legitimate use case.

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

That's an orthogonal issue. With PROPFIND it could be a full new 
directory listing, just an update for an individual entry, or a new 
entry. In CalDAV/CardDAV there are REPORT requests that allow reporting 
incremental changes, for instance.

But please do not conclude that this is a "WebDAV thing". As mentioned 
earlier, I believe we really should have a new method that is defined to 
be safe but does have a payload, so that we can get rid of the very 
widely used "POST-for-query" pattern.

Best regards, Julian

Received on Saturday, 10 May 2014 08:15:49 UTC