Shing,
The client can reset a pushed stream in just the same way that it can reset
any normally requested stream.
From the servers point of view, both will probably have to be passed to the
servlet thread serving the request as an exception thrown from a write
operation. It is equivalent to a BrokenPipeException thrown now if a
client closes a socket while a HTTP/1.1 response is being written.
So if a framework wishes to track which resources it is pushing and record
if they were written to completion or not, so as to refine it's push
strategy, I think that is a great idea..... but I'm not sure we need or can
provide an API for that. The generation of the pushed resource may
be deep deep inside servlet/framework/application code that is probably
blocking and/or not interruptible, so a callback will be of little use.
A write exception is the only viable way to pass a reset stream to all
servlets.
However we could define a specific exception for reset stream, to make a
frameworks job of tracking pushed failures easier.
cheers
On 9 September 2014 08:44, Shing Wai Chan <shing.wai.chan_at_oracle.com> wrote:
> 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>
> 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>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com advice and support for jetty and cometd.
>
>
>
--
Greg Wilkins <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.