----- Original Message -----
> From: "Shing Wai Chan" <shing.wai.chan_at_oracle.com>
> To: jsr369-experts_at_servlet-spec.java.net
> Cc: "Stuart Douglas" <sdouglas_at_redhat.com>
> Sent: Tuesday, 18 August, 2015 2:48:42 AM
> Subject: [jsr369-experts] Re: [servlet-spec users] Re: [SERVLET_SPEC-134] Push API vJetty
>
> However, from the javadoc, the queryString is "initialized as follows":
> * The query string from HttpServletRequest.getQueryString().
>
> So, this implies that the path() call inherits the query string from the
> original request.
> That is why I ask the question.
>
> To fix the issue, we can do one of the following:
> a) remove the initialized for queryString from above
> b) add remove/replace queryString API
>
> For the queryString issue, (a) is better.
> But then we also need to consider similar issues for headers.
Oops, I totally miss read that.
I don't think that it makes any sense to initialise the query string to be the same as the original request. I think in the majority of cases the new request will have a different query string, so I think your option a) is the way to go.
Stuart
>
> Thanks.
> Shing Wai Chan
>
> On 8/16/15, 6:01 PM, Stuart Douglas wrote:
> >
> > ----- 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
> >>>
>