Lower case headers

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Lower case headers

Ana Laura Felisatti
Hi.

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.

Thanks,


--
A. Felisatti
Reply | Threaded
Open this post in threaded view
|

Re: Lower case headers

oleksiys
Administrator
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.
Reply | Threaded
Open this post in threaded view
|

Re: Lower case headers

Ana Laura Felisatti
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Lower case headers

Ana Laura Felisatti
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 <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Lower case headers

oleksiys
Administrator
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 <[hidden email]> 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 <[hidden email]> 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