Hi Ed,
Just a minor clarification that I needed for the diagram that you provided
for discussing the Push-Promise frame(s) being sent to the client in a
Container-aware manner:
Why have you chosen to show multiple/separate client instances on the
diagram for each request frame?
Sincerely,
Nawazish
On Tue, Sep 9, 2014 at 7:30 AM, <users-request_at_servlet-spec.java.net> wrote:
> Table of contents:
>
> 1. [servlet-spec users] Re: [jsr340-experts] Re: HTTP/2 Push Was:
> Server-Sent Events in Java EE 8 - Edward Burns <edward.burns_at_oracle.com>
> 2. [servlet-spec users] Re: [jsr340-experts] Re: HTTP/2 Push Was:
> Server-Sent Events in Java EE 8 - Stuart Douglas <sdouglas_at_redhat.com>
> 3. [servlet-spec users] Re: [jsr340-experts] Re: HTTP/2 Push Was:
> Server-Sent Events in Java EE 8 - Shing Wai Chan <
> shing.wai.chan_at_oracle.com>
> 4. [servlet-spec users] Re: [jsr340-experts] Re: HTTP/2 Push Was:
> Server-Sent Events in Java EE 8 - Greg Wilkins <gregw_at_intalio.com>
> 5. [servlet-spec users] Re: [jsr340-experts] Re: HTTP/2 Push Was:
> Server-Sent Events in Java EE 8 - Shing Wai Chan <
> shing.wai.chan_at_oracle.com>
> 6. [servlet-spec users] Re: [jsr340-experts] Re: HTTP/2 Push Was:
> Server-Sent Events in Java EE 8 - Greg Wilkins <gregw_at_intalio.com>
>
>
>
> ---------- Forwarded message ----------
> From: Edward Burns <edward.burns_at_oracle.com>
> To: users_at_servlet-spec.java.net
> Cc:
> Date: Mon, 8 Sep 2014 10:12:20 -0700
> Subject: [servlet-spec users] Re: [jsr340-experts] Re: HTTP/2 Push Was:
> Server-Sent Events in Java EE 8
> >>>>> On Fri, 22 Aug 2014 08:47:31 +1000, Greg Wilkins <gregw_at_intalio.com>
> said:
>
> GW> So I think the resources should be pushed as soon as they are
> discovered -
> GW> with some obvious protection against duplicate pushes.
>
> I agree with you and like your model better.
>
> GW> So the context could have a method:
>
> GW> context.addAssociatedResource(String uriInContext)
> GW> {
> GW> associated.add(uriInContext);
> GW> ConcurrentSet<String> pushed =
> GW> getRequest().getHttpSession().getAttribute("pushed);
> GW> if (pushed.addIfAbsent(uriInContext))
> GW> getServletContext().getRequestDispatcher(
> GW> uriInContext).push(getRequest())
> GW> }
>
> GW> that would trigger a push as the associated resource is first added to
> the
> GW> context, using the API that I have proposed.
>
> I don't see why it has to hang off the http session. The set of pushed
> resources is a request level concern, not a session one.
>
> Also, and this was brought to my attention by Shing-Wai:
>
> SWC> According to section 8.2.1 of draft-ietf-httpbis-http2-13.txt ,
> SWC> the push response should be sent earlier.
>
> Looking at the most recent draft (14):
>
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2/
>
> The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to
> sending any frames that reference the promised responses. This
> avoids a race where clients issue requests prior to receiving any
> PUSH_PROMISE frames.
>
> For example, if the server receives a request for a document
> containing embedded links to multiple image files, and the server
> chooses to push those additional images to the client, sending push
> promises before the DATA frames that contain the image links ensures
> that the client is able to see the promises before discovering
> embedded links. Similarly, if the server pushes responses referenced
> by the header block (for instance, in Link header fields), sending
> the push promises before sending the header block ensures that
> clients do not request them.
>
> 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've added a wiki page with a diagram for discussion:
>
> https://java.net/projects/servlet-spec/pages/PushAPI
>
> Thoughts?
>
> Thanks,
>
> Ed
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 14 work days til JavaOne 2014
> | 10 work days til start of JSF 2.3 and Servlet 4.0
>
>
> ---------- Forwarded message ----------
> From: Stuart Douglas <sdouglas_at_redhat.com>
> To: Edward Burns <edward.burns_at_oracle.com>
> Cc: users_at_servlet-spec.java.net
> Date: Tue, 09 Sep 2014 07:33:54 +1000
> Subject: [servlet-spec users] Re: [jsr340-experts] Re: HTTP/2 Push Was:
> Server-Sent Events in Java EE 8
>
> 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
>>
>
>
> ---------- Forwarded message ----------
> From: Shing Wai Chan <shing.wai.chan_at_oracle.com>
> To: users_at_servlet-spec.java.net
> Cc:
> Date: Mon, 08 Sep 2014 15:04:51 -0700
> Subject: [servlet-spec users] Re: [jsr340-experts] Re: HTTP/2 Push Was:
> Server-Sent Events in Java EE 8
> 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
>>>
>>
>
>
> ---------- Forwarded message ----------
> From: Greg Wilkins <gregw_at_intalio.com>
> To: Shing Wai Chan <shing.wai.chan_at_oracle.com>
> Cc: users_at_servlet-spec.java.net
> Date: Tue, 9 Sep 2014 08:16:49 +1000
> Subject: [servlet-spec users] Re: [jsr340-experts] Re: HTTP/2 Push Was:
> Server-Sent Events in Java EE 8
>
> 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.
>
>
> ---------- Forwarded message ----------
> From: Shing Wai Chan <shing.wai.chan_at_oracle.com>
> To: Greg Wilkins <gregw_at_intalio.com>
> Cc: users_at_servlet-spec.java.net
> Date: Mon, 08 Sep 2014 15:44:47 -0700
> Subject: [servlet-spec users] Re: [jsr340-experts] Re: HTTP/2 Push Was:
> Server-Sent Events in Java EE 8
> 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.
>
>
>
>
> ---------- Forwarded message ----------
> From: Greg Wilkins <gregw_at_intalio.com>
> To: Shing Wai Chan <shing.wai.chan_at_oracle.com>
> Cc: users_at_servlet-spec.java.net
> Date: Tue, 9 Sep 2014 08:55:03 +1000
> Subject: [servlet-spec users] Re: [jsr340-experts] Re: HTTP/2 Push Was:
> Server-Sent Events in Java EE 8
>
> 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.
>
> End of digest for list users_at_servlet-spec.java.net - Tue, 09 Sep 2014
>
>