Thank you,
Martin Mulholland.
WebSphere Application Server Web Tier Architect
email: mmulholl_at_us.ibm.com
IBM RTP, PO BOX 12195, 503/C227,
3039 Cornwallis Rd, RTP, NC 27709-2195
t/l 444-4319, external (919)-254-4319
Greg Wilkins <gregw_at_webtide.com> wrote on 05/09/2017 02:12:38 AM:
> From: Greg Wilkins <gregw_at_webtide.com>
> To: jsr369-experts_at_servlet-spec.java.net
> Date: 05/09/2017 02:13 AM
> Subject: [servlet-spec users] [jsr369-experts] Re: Re: Re: Trailer
> header implementation
>
>> On 8 May 2017 at 23:30, Shing Wai Chan <shing.wai.chan_at_oracle.com>
wrote:
>> I have discussed this with Ed. We are both ok to use existing
>> request header API
>> for request trailer. And no new API is added for request trailer.
>>
>> In this case, we will only add API for response trailer.
>>
>> Is this ok for other EG?
>> Please let us know.
>
> The good thing about this approach is that existing applications
> that consult headers after reading content will just work with trailers.
>
> The bad thing about this approach is that existing applications that
> consult headers after reading content will just work with trailers.
>
> Also it will be tough for applications to enforce compliance with
> the RFC for the Trailers header. They will have to check before all
> content is written for the absence of a header, then check again
> afterwards for it's presence. Difficult if the name is both a header
> and a trailer.
>
> Also, when are the trailers added to the header results? when the
> container has read the entire message or only once the application
> has read the -1 ? Async apps will have to be careful about
> concurrent modification on header enumerations.
>
> Finally, such an approach will put a tiny bit of extra complication
> in the implementation of the normal getHeader API, which is probably
> executed billions of times every day (if not hour). The 99.9999% of
> applications that don't care about trailers are each going to pay a
> tiny cost, which combined will be a non trivial amount of CPU/power
> etc. Better to have trailers separate, so only the few applications
> that wish to allow trailers need use the API.
>
> So on balance, I'd prefer to keep the trailers out of the headers API.
> However, I'm not opposed to using the same style API (even with
> retro enumerations) for getTrailerNames(), getTrailer(String) and
> getTrailerValues(String)
>
Have discussed this at length with my http component lead and these are
our thoughts:
An app using trailers would use the trailer headers to provide additional
info about the data sent, the app would know this, expect the headers and
know when and how to process them. If there is a same named header in the
trailer, the getHeader api would still return the first and app would have
to use getHeaders(String) to find the second.
The idea here is to:
1. not unnecessarily expose the RFC in the servlet API.
2. not to impose uneccessary requirements on the http implementation.
Based on the RFC I would expect the http component to make the trailer
headers available immediately after it had read all of the data. However
this is not the same as the application reading all of the data, so if we
want the trailers to only be available after the app has read all the data
that has to be a servlet container implementation. This maybe brings us
back
to having a getTrailers() option so we can block until the app has read
all
of the data but the reasons for not wanting getTrailers() are still there
and
even if we do this potentially the headers are still available using
existing
api's (they would in the IBM implementation). For this I also fall back to
the concept that the app would only be interested in the trailer headers
after reading all of the data, and it is not our place to deny access to
headers once they are available. Instead we just say headers from the
trailer section will be made available any time after they have
been received.
For the concurrent modification exception the IBM implementation always
returns new enumerations so that is easily avoided.
For extra code in getHeader API, in the IBM implementation this would not
exist because we do not retain any header information, we always retrieve
from the http component. I don't see any significant increase for http
other
than adding trailer headers to the header when they are received.
Maybe it would be good to have a call to reach a consensus.
Thanks,
Martin.