On 21/04/17 23:35, Greg Wilkins wrote:
>
> On 22 April 2017 at 01:32, Mark Thomas <markt_at_apache.org
> <mailto:markt_at_apache.org>> wrote:
>
> I disagree with the convenient / inconvenient tags above.
>
> If a header has multiple values in the vast majority of cases the first
> thing the user is going to want to do is split it up into the individual
> values. I'd argue it makes more sense for the container to write that
> code once than have every user write that code.
>
>
> Mark,
>
> I called Map<String, List<String>> inconvenient as for the common case of
> wanting a single value, the user must deal with a list. They must
> decide if they are going to iterate, take the first element after a
> range check or just trust it has more than 0 elements.
Ah. I see where you are coming from.
I guess it depends how many of these headers can have multiple values.
If the majority are single valued, Map<String,String> does make more sense.
> In the case that the field can have multiple values, they still need to
> parse each value in the list as that to can be a CSV:
>
> trailer: a,b
> trailer: c,d
>
> Would arrive as {"trailer"=["a,b","c,d"]}, or are you saying that the
> container should parse values and return {"trailer"=["a","b","c","d"]}?
I was suggesting the later. i.e. get the container to do the work.
> While this would be very convenient, it is a big difference to our
> handling of getHeaders and may not be appropriate for all headers.
>
> If the list value types are to provide parsed/split values, then I'm
> less keen on them. As much as I think the container should have
> provided that semantic, that horse bolted decades ago and we have ceded
> the responsibility for that to frameworks and applications.
Given we aren't limiting ourselves to mirroring the existing header API
then I think we still have the flexibility to do whatever makes the most
sense in this case - irrespective of previous decisions.
> So I still like 1. Map<String,String> and a mostly sufficient
> simplification of the trailer semantic. But if there is not universal
> support for it (or for the list variants), then I think we have to look
> at something like ugly but correct like 5. List<Map.Entry<String,String>>
I think it comes down to what the typical uses of trailer headers are
expected to be. Nearly all of the examples I have seen over the years
have been in various security vulnerability PoCs targetted at bypassing
various limits used to provide DoS protection. Real world examples are
few and far between. The extremely small sample of real uses I have
managed to find have been single value.
One final point in favour of Map<String,List<String>> - the Java
WebSocket API uses it (and Tomcat implements it with a case insensitive
key).
In summary:
Real world usage points to Map<String,String>
Consistency with Java WebSocket points to Map<String,List<String>>
At this point, I'd be equally happy with either.
Mark