users@grizzly.java.net

Re: Lower case headers

From: Ana Laura Felisatti <anafelisatti_at_gmail.com>
Date: Thu, 7 Apr 2016 14:49:21 -0300

Hi, Alexey.

Thanks for the quick response.

The use case where we have problems is that of a proxy: we just want to
send everything we get exactly as it arrived to another service. Since we
cannot access the original request headers in terms of case, we get
failures when the service is expecting some particular header and if they
are external services then there's nothing we can do to change that.

The case you mention actually came up regarding the Set-Cookie header and
the lower case transformation that is happening right now helped us since
the different headers values were grouped together as they should be and we
could access the header knowing it would be lower case, so I understand the
difficulty. What I would expect then is to keep the current behavior but
provide a way to turn the lower case transformation off and therefor the
header grouping as well. In fact, for the proxy use case it would make
sense to not group the values but handle each header as distinct so as to
also re send them individually.

I've run a quick test removing the transformation and the results out of
the box seemed perfect for the proxy case.

Let me know if I can provide anymore details and thanks again.

Ana

On Wed, Mar 30, 2016 at 6:09 PM, Oleksiy Stashok <oleksiy.stashok_at_oracle.com
> wrote:

> Hi Ana,
>
>
> On 3/30/16 1:42 PM, Ana Laura Felisatti wrote:
>
>> We've been using Grizzly for a while now in a project but some concerns
>> have come up regarding how the headers are processed. In short, we see no
>> way of accessing the original request header names in terms of case: if we
>> send "MYHeaDEr=bla" then what we'll see in the server side is
>> "myheader=bla".
>>
>> I've tracked the behavior down to
>> org.glassfish.grizzly.http.HttpCodecFilter#parseHeaderName. I'm guessing
>> there could be performance reasons for that perhaps and I know that headers
>> are case insensitive so it shouldn't really matter but I'd like to know
>> whether this can be done somehow and if not why.
>>
> For now there is no way to restore the original header name.
> Could you pls. explain your case, maybe we'll be able to implement a way
> to figure that out.
> I suspect you want Request.getHeaderNames() to return original names,
> right? Suppose there are both "MYHeaDEr" and "myheader" headers in the
> request, what should getHeaderNames() return in that case? I understand
> it's kind of corner case, but I'd like to understand your
> requirements/expectations better.
>
>
> Thank you.
>
> WBR,
> Alexey.
>



-- 
A. Felisatti