Besides queryString, other http headers also have a similar issue.
So, we can do one of the following (as in queryString):
a) remove the initialized for headers
b) add removeHeader API
Any comments?
Thanks.
Shing Wai Chan
On 8/17/15, 3:52 PM, Stuart Douglas wrote:
>
> ----- 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
>>>>>