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