jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: [servlet-spec users] Re: Re: Re: Re: Re: Re: Re: revised trailer proposals

From: Edward Burns <edward.burns_at_oracle.com>
Date: Wed, 19 Apr 2017 15:59:22 -0700

GW> Chunked encoding or HTTP/2 would give an empty map if there are no
GW> trailers, otherwise null to indicate no trailers could have been
GW> transferred.

>>>>> On Wed, 19 Apr 2017 13:52:22 -0700, Shing Wai Chan <shing.wai.chan_at_oracle.com> said:

SW> So, the former means no TE header.
SW> Do we need to distinguish this in #getTrailers()? Or we have to check the presence of TE header?
SW> So we have to do the null check for #getTrailers() here. Do we want that?

>>>>> On Thu, 20 Apr 2017 07:48:28 +1000, Greg Wilkins <gregw_at_webtide.com> said:

GW> It is more that TE header as Trailers can be carried on chunked HTTP/1.1 or
GW> HTTP/2, plus some other transports, so the text needs to not be protocol
GW> specific.

GW> Now I'm not sure if we really need to know the difference between
GW> no-trailers and not-able-to-transport-trailers, but the difference between
GW> a null return and an empty map is a good way to convey that semantic so why
GW> not use it.

To answer why not I'll observe that having to check for null returns is
a pain and we should avoid forcing people to do it if possible. Now, I
grant that we already return null from
HttpServletRequest.newPushBuilder() to indicate that push is not
available, but here we have an opportunity to return an empty Map. I
think of it as a complexity tax. If we are going to ask users to pay
this complexity tax, I'd like to know what we are giving them in return
is valuable. If there is a compelling case to distinguish between
no-trailers and not-able-to-transport-trailers, then it might be worth
paying the tax. If not, I'd say no it's not.

GW> Note also that Simone Bordet has pointed out to me that Map<String,String>
GW> is a poor data structure to use as it is case sensitive and trailers are
GW> case insensitive. If we are to use map, then we should say that all the
GW> keys are set as lowercase rather than any case passed by the client -
GW> which would make it hard to find headers if strange casings were
GW> passed.

Again, the complexity tax of introducing an entirely new data structure
was judged not worth paying. What about this implementation approach to
this problem?

http://stackoverflow.com/questions/11929542/how-to-ignore-the-case-sensitive-when-we-look-for-a-key-in-the-map

>>>>> On Wed, 19 Apr 2017 15:43:35 -0700, Shing Wai Chan <shing.wai.chan_at_oracle.com> said:

SW> Yes, we need to clarify that the header keys are in lowercase.

Thanks,

Ed

-- 
| edward.burns_at_oracle.com | office: +1 407 458 0017
|  1 business days until planned start of Servlet 4.0 Public Review