Hi, there.
I've created
https://java.net/jira/browse/GRIZZLY-1832. Please let me know
your thoughts.
Cheers,
On Thu, Apr 7, 2016 at 2:49 PM, Ana Laura Felisatti <anafelisatti_at_gmail.com>
wrote:
> 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
>
--
A. Felisatti