jsr369-experts@servlet-spec.java.net

[jsr369-experts] [SERVLET_SPEC-134] Push API vJetty

From: Edward Burns <edward.burns_at_oracle.com>
Date: Fri, 14 Aug 2015 16:09:53 -0700

>>>>> On Wed, 12 Aug 2015 09:16:19 +1000, Greg Wilkins <gregw_at_webtide.com> said:

GW> We've not done a lot of work or analysis on this
GW> recently.... however it is included in our stable release and here
GW> is the API that we are currently providing:

GW> https://github.com/eclipse/jetty.project/blob/master/jetty-server/src/main/java/org/eclipse/jetty/server/PushBuilder.java

Thanks Greg,

I've taken this as a starting point and created a branch on which we can
iterate. I've published the artifact and the javadoc is at [1].

I've added getPushBuilder() to HttpServletRequest [2].

I've reworded your text somewhat, and am still in the process of doing
that. The biggest and only normative change to what you had is in the
final sentance of the class javadoc for PushBuilder. I've called out
some specific areas for discussion here.

  A PushBuilder can be customized by chained calls to mutator methods
  before the push() method is called to *initiate an asynchronous push
  request with the current state of the builder.* After the call to
  push(), the builder may be reused for another push, *however the
  implementation must make it so the path(String), etag(String) and
  lastModified(String) values are cleared before returning from
  push()*. All other values are retained over calls to push().

GW> However, while it is being used, I would not characterize this as
GW> extensively tested or analysed. To my knowledge nobody has used the API
GW> directly in a framework, but some have deployed the push filter in their
GW> applications.

GW> Note that while I like the idea of the simple degenerate case, my limited
GW> experience is that building the synthetic request is actually a lot more
GW> complex than you'd think and there are lots of corner/edge cases. Even the
GW> PushBuilder needs to synthesize/validate headers and the rules for that
GW> will need to be carefully crafted and explained to achieve portability.

You know, I think I can live without the dispatcher that I showed at
GeekOut on slide 70 of [3]:

It could just as well be

  ((HttpServletRequest)request).getRequestBuilder().path(url).push();

Let's get some discussion going here!

Ed

-- 
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 57 Business days til JavaOne 2015
| 72 Business days til DOAG 2015
[1] https://maven.java.net/service/local/repositories/snapshots/archive/javax/servlet/javax.servlet-api/4.0.0-b01-SERVLET_SPEC-134-SNAPSHOT/javax.servlet-api-4.0.0-b01-SERVLET_SPEC-134-20150814.225827-1-javadoc.jar/!/index.html
[2] https://maven.java.net/service/local/repositories/snapshots/archive/javax/servlet/javax.servlet-api/4.0.0-b01-SERVLET_SPEC-134-SNAPSHOT/javax.servlet-api-4.0.0-b01-SERVLET_SPEC-134-20150814.225827-1-javadoc.jar/!/javax/servlet/http/HttpServletRequest.html#getPushBuilder--
[3] http://www.slideshare.net/edburns/servlet-40-at-geekout-2015