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.)
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
>