Hi Ana,
thank you, I'll try to implement it for the next release.
WBR,
Alexey
On 4/21/16 11:46 AM, Ana Laura Felisatti wrote:
> 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 <mailto: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 <mailto: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