jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: [servlet-spec users] [SERVLET_SPEC-134] Push API vJetty

From: Stuart Douglas <sdouglas_at_redhat.com>
Date: Sun, 16 Aug 2015 21:01:39 -0400 (EDT)

----- Original Message -----
> From: "Shing Wai Chan" <shing.wai.chan_at_oracle.com>
> To: jsr369-experts_at_servlet-spec.java.net
> Sent: Monday, 17 August, 2015 2:33:19 AM
> Subject: [jsr369-experts] Re: [servlet-spec users] [SERVLET_SPEC-134] Push API vJetty
>
> From javadoc,
> "The instance is initialized as follows:
> ...
> * The query string from HttpServletRequest.getQueryString()
>
> PushBuilder queryString(String queryString)
> Set the query string to be used for the push. Will be appended to any
> query String included in a call to path(String).
> "
>
> So, this means we can only add more query String, but cannot modify or
> remove the query string from the httpServletRequest.
> Is it an issue here? Do we need APIs to remove or clean up or replace
> the query string?
> (Just consider the case of push a jpg file which may/do not need query
> string. Or in some case, we need to "replace" the query string.)
> (The same may be for other headers.)

This is the query string from the .path() call, not the query string from the original
request. I think in this case it makes sense, if you don't want a query string just don't
include one in the call to path().

Stuart

>
> Shing Wai Chan
>
>
> On 8/14/15, 4:09 PM, Edward Burns wrote:
> >>>>>> 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
> >
>