Re: How to stop receiving a pushed resource? (I-D Action: draft-ietf-httpbis-http2-01.txt)

[William Chan (陈智昌) <[e-mail]>]

Yes, the text at the bottom of your email is the mechanism that should
be used. It's possible that we could use some other mechanism to
convey the client cache in some way. There are many issues with it of
course.

Note that web developers are already pushing resources. It's called
resource inlining
(https://developers.google.com/speed/docs/pss/InlineSmallResources).
These resources do not have their own URLs, are usually inlined into
uncacheable documents, and thus are rarely cached at all. Using server
push will enable them to have their own URLs and be cached by the
client if that makes sense.

Remember, once you issue a request to a server, the server can send
you anything in return. It's in our interest to provide them better
facilities for sending responses, or they will hack around it in less
optimal ways.

On Mon, Jan 21, 2013 at 5:35 PM, Frédéric Kayser <[e-mail]> wrote:
> Hello,
> is this the mechanism clients should use to stop receiving pushed resources they already have in their local cache?
> How are servers supposed to guess what to push or not? Is it be based on modification date, could the clients send some hints?
>
> Frédéric
>
>> 4.3.2.  Client implementation
>>
>>    When fetching a resource the client has 3 possibilities:
>>
>>       the resource is not being pushed
>>
>>       the resource is being pushed, but the data has not yet arrived
>>
>>       the resource is being pushed, and the data has started to arrive
>>
>>    When a SYN_STREAM and HEADERS frame which contains an Associated-To-
>>    Stream-ID is received, the client must not issue GET requests for the
>>    resource in the pushed stream, and instead wait for the pushed stream
>>    to arrive.
>>
>> [...]
>>
>>    To cancel individual server push streams, the client can issue a
>>    stream error (Section 3.4.2) with error code CANCEL.  Upon receipt,
>>    the server MUST stop sending on this stream immediately (this is an
>>    Abrupt termination).
>
>