In 8.2.2 of draft-ietf-httpbis-http2-14.txt, we have
If the client determines, for any reason, that it does not wish to
receive the pushed response from the server, or if the server takes
too long to begin sending the promised response, the client can send
an RST_STREAM frame, using either the CANCEL or REFUSED_STREAM codes,
and referencing the pushed stream's identifier.
So it seems that one can know whether the streams failed or not.
I am not asking whether we should wait for the push.
I am asking whether we want to have the ability to access the completed
or failed status, for example, using a callback handler.
Shing Wai Chan
On 9/8/14, 3:16 PM, Greg Wilkins wrote:
>
> Guys,
>
> this is a collective reply to the previous emails, because I think
> there is a common miss understanding.
>
> All the push mechanism can do is initiate a pushed resource during the
> processing of a response, it cannot confirm/deny the success of that
> push or even wait for the end of that push.
>
> Specifically it is best if associated resources are pushed early in
> the response and before they are referenced in any pushed html or
> css. If they are pushed after the html or css that references them,
> then the client may parse that and have already made a request for the
> resource and we will end up serving it twice.
>
> Once initiated, the pushed resource is an entirely different stream
> that can proceed in parallel with the original stream. It can succeed
> or fail, be stalled or throttled independently and may finish before
> or after the original stream. A client can send priority messages to
> indicate which of the streams it wants to proceed fastest, it can
> reset an unwanted pushed resource and it can consume content at
> different rates and so cause the streams to stall or flow differently.
>
> I am still proposing that the fundamental push mechanism is on the
> RequestDispatcher. My suggested code for
> context.addAssociatedResource(String uriInContext) was just an
> example of how a framework that had a Context abstraction could
> accumulate associated resources from components and push them the
> first time they are seen. It would still use the underlying
> RequestDispatcher mechanism that I proposed.
>
> I think we need a fundamental push mechanism, then all the frameworks
> and applications can innovate about how they actually use it. Some
> might track sessions to try to know what resources a session has seen,
> others might just have a fixed list of associated resources for some
> key requests. This is stuff that we are going to have to learn from
> and browser might even evolve to give us some more hints. So we want
> to keep the fundamental API as simple as possible and to just capture
> the essence of the mechanism and no more.
>
> cheers
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 9 September 2014 08:04, Shing Wai Chan <shing.wai.chan_at_oracle.com
> <mailto:shing.wai.chan_at_oracle.com>> wrote:
>
> I also don't see a need for request#completedPushRequest.
> I have a different question.
> Do we need to whether the push is completed or failed?
>
> Shing Wai Chan
>
>
> On 9/8/14, 2:33 PM, Stuart Douglas wrote:
>
>
> Greg, you already intimated this requirement but I wanted
> to make it
> explicit for discussion. I perceive a side-effect of this
> requirement:
> the container needs to know when all the PUSH_PROMISE
> frames pertaining
> to this request have been sent, so it can commence sending
> the HTML
> bytes. I've added a request.completedPushRequest() method
> for this
> case.
>
>
> I don't really see the need for the completedPushRequest()
> method. In particular there is no requirement in the spec that
> all push promises are sent before any HTML is sent, only that
> the promise should be sent before we send any HTML that
> references these resources.
>
> For example consider the case of a footer that is generated
> from a servlet include. This footer has an image that should
> be sent via push promise, but the calling page has no way of
> knowing that, and it is perfectly legitimate to start sending
> the page HTML, as long as the push promise arrives before the
> bit of the footer that references the image.
>
> I think that for the most part we should just make this a user
> level concern. We should require that if dispatchPushRequest()
> is called then the push promise will be sent on the wire
> before any data that is written after the call, but other than
> that it is up to the end user to make sure that they push
> resources before sending the html.
>
> Stuart
>
>
> I've added a wiki page with a diagram for discussion:
>
> https://java.net/projects/servlet-spec/pages/PushAPI
>
> Thoughts?
>
> Thanks,
>
> Ed
>
>
>
>
>
> --
> Greg Wilkins <gregw_at_intalio.com <mailto:gregw_at_intalio.com>>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com advice and support for jetty and cometd.