Re: Case Sensitive Headers

[Luke Seelenbinder]

Hi Christopher,

That's great! Thank you. It looks exactly like what we need.

Best,
Luke

—
Luke Seelenbinder
SermonAudio.com  | Senior Software Engineer






> On Jul 25, 2019, at 09:18, Christopher Faulet  wrote:
> 
> Le 12/07/2019 à 13:26, Luke Seelenbinder a écrit :
>> Hi Christopher,
>> That definitely is ugly—but it works. Thanks! I'll look for improvements in 
>> 2.1.
> 
> Hi Luke,
> 
> FYI, a feature has been added in the 2.1 to change the case of header names. 
> Take a look on the commit 98fbe953:
> 
>  http://git.haproxy.org/?p=haproxy.git;a=commitdiff;h=98fbe953
> 
> Now, you may decide to change the case of specific header names using global 
> directives "h1-case-adjust" or "h1-case-adjust-file". It can be enabled in 
> both directions, client or server, with 2 options, the first for the 
> frontends ("option h1-case-adjust-bogus-client") and the other one for the 
> backends ("option h1-case-adjust-bogus-server").
> 
> Best,
> -- 
> Christopher Faulet

Re: Case Sensitive Headers

[Christopher Faulet]

Le 12/07/2019 à 13:26, Luke Seelenbinder a écrit :

Hi Christopher,

That definitely is ugly—but it works. Thanks! I'll look for improvements in 2.1.



Hi Luke,

FYI, a feature has been added in the 2.1 to change the case of header names. 
Take a look on the commit 98fbe953:


  http://git.haproxy.org/?p=haproxy.git;a=commitdiff;h=98fbe953

Now, you may decide to change the case of specific header names using global 
directives "h1-case-adjust" or "h1-case-adjust-file". It can be enabled in both 
directions, client or server, with 2 options, the first for the frontends 
("option h1-case-adjust-bogus-client") and the other one for the backends 
("option h1-case-adjust-bogus-server").


Best,
--
Christopher Faulet

Re: Case Sensitive Headers

[Luke Seelenbinder]

Hi Christopher,

That definitely is ugly—but it works. Thanks! I'll look for improvements in 2.1.

Best,
Luke
—
Luke Seelenbinder
SermonAudio.com  | Senior Software Engineer

> On Jul 10, 2019, at 14:53, Christopher Faulet  wrote:
> 
> Le 10/07/2019 à 13:08, Luke Seelenbinder a écrit :
>> Hi Patrick,
>> 
>> That didn't work (in a few different forms I tried)—thanks for the 
>> suggestion 
>> though!
>> 
>> It seems HTX is pretty picky about how those headers get emitted. :)
>> 
>> I'm still looking for a solution to this that doesn't involve disabling HTX.
>> 
> 
> Hi Luke,
> 
> It is pretty ugly but you may hide the full "Content-Length" header in the 
> value of
> another one, for instance:
> 
>http-response set-header x-custom-cl "1\r\nContent-Length: 
> %[res.fhdr(content-length)]" if { res.fhdr(content-length) -m found }
>http-response del-header content-length
> 
> As said, it is ugly. But it does the trick for now. I will probably try to 
> work
> on a solution for the 2.1. Even more so the legacy HTTP will be removed for
> this release.
> 
> -- 
> Christopher Faulet
> 

Re: Case Sensitive Headers

[Christopher Faulet]

Le 10/07/2019 à 13:08, Luke Seelenbinder a écrit :
> Hi Patrick,
> 
> That didn't work (in a few different forms I tried)—thanks for the suggestion 
> though!
> 
> It seems HTX is pretty picky about how those headers get emitted. :)
> 
> I'm still looking for a solution to this that doesn't involve disabling HTX.
> 

Hi Luke,

It is pretty ugly but you may hide the full "Content-Length" header in the 
value of
another one, for instance:

http-response set-header x-custom-cl "1\r\nContent-Length: 
%[res.fhdr(content-length)]" if { res.fhdr(content-length) -m found }
http-response del-header content-length

As said, it is ugly. But it does the trick for now. I will probably try to work
on a solution for the 2.1. Even more so the legacy HTTP will be removed for
this release.

-- 
Christopher Faulet

Re: Case Sensitive Headers

[Luke Seelenbinder]

Hi Patrick,

That didn't work (in a few different forms I tried)—thanks for the suggestion 
though!

It seems HTX is pretty picky about how those headers get emitted. :)

I'm still looking for a solution to this that doesn't involve disabling HTX.

Best,
Luke

—
Luke Seelenbinder
SermonAudio.com <http://sermonaudio.com/> | Senior Software Engineer


> On Jun 27, 2019, at 17:11, Patrick Hemmer  wrote:
> 
> 
> 
> From: Luke Seelenbinder [mailto:l...@sermonaudio.com 
> <mailto:l...@sermonaudio.com>]
> Sent: Wednesday, June 26, 2019, 10:07 EDT
> To: HAProxy  <mailto:haproxy@formilux.org>
> Subject: Case Sensitive Headers
> 
>> Hello List,
>> 
>> I have a painful case of noncompliance to report and figure out how to fix.
>> 
>> When HTX is enabled, all headers are returned in lower case (e.g., 
>> content-length, date, etc.). This is obviously fine and within spec. 
>> Unfortunately, I'm using a rather frustrating piece of software (Wowza) that 
>> talks to an haproxy instance and Wowza requires that the content-length 
>> header is always camel case, i.e., Content-Length, otherwise requests fail.
>> 
>> I tried using http-response set-header Content-Length 
>> %[res.hdr(content-length)] if { res.hdr(content-length) -m found } to force 
>> the value to upper case, but that didn't help.
>> 
>> This is very obviously a case of badly behaving software and not a problem 
>> with HAProxy, but I'm wondering if there's any other way to force that 
>> header to Content-Length without turning HTX off.
>> 
>> Thanks for any ideas!
>> 
>> Best,
>> Luke
>> 
>> —
>> Luke Seelenbinder
>> SermonAudio.com <http://sermonaudio.com/> | Senior Software Engineer
>> 
>> 
> This is just a stab in the dark, but try deleting the header, then adding it 
> back. For example
> 
> http-response set-var(res.conlen) res.hdr(content-length)
> http-response del-header content-length
> http-response set-header Content-Length %[var(res.conlen)] if { 
> var(res.conlen) -m found }
> 
> -Patrick

Re: Case Sensitive Headers

[Patrick Hemmer]

*From:* Luke Seelenbinder [mailto:l...@sermonaudio.com]
*Sent:* Wednesday, June 26, 2019, 10:07 EDT
*To:* HAProxy 
*Subject:* Case Sensitive Headers


Hello List,

I have a painful case of noncompliance to report and figure out how to 
fix.


When HTX is enabled, all headers are returned in lower case (e.g., 
content-length, date, etc.). This is obviously fine and within spec. 
Unfortunately, I'm using a rather frustrating piece of software 
(Wowza) that talks to an haproxy instance and Wowza requires that the 
content-length header is always camel case, i.e., Content-Length, 
otherwise requests fail.


I tried using http-response set-header Content-Length 
%[res.hdr(content-length)] if { res.hdr(content-length) -m found } to 
force the value to upper case, but that didn't help.


This is very obviously a case of badly behaving software and not a 
problem with HAProxy, but I'm wondering if there's any other way to 
force that header to Content-Length without turning HTX off.


Thanks for any ideas!

Best,
Luke

—
*Luke Seelenbinder*
SermonAudio.com <http://sermonaudio.com> | Senior Software Engineer


This is just a stab in the dark, but try deleting the header, then 
adding it back. For example


http-response set-var(res.conlen) res.hdr(content-length)
http-response del-header content-length
http-response set-header Content-Length %[var(res.conlen)] if { 
var(res.conlen) -m found }


-Patrick

Re: Case Sensitive Headers

[Luke Seelenbinder]

Hi Lukas,

Wowza actually talks to a service behind HAProxy, so it should be 
http-response, because Wowza expects to see "Content-Length" vs 
"content-length" header from the response served through HAProxy.

Best,
Luke

—
Luke Seelenbinder
SermonAudio.com  | Senior Software Engineer

> On Jun 27, 2019, at 15:41, Lukas Tribus  wrote:
> 
> Hello Luke
> 
> On Wed, 26 Jun 2019 at 16:08, Luke Seelenbinder  wrote:
>> I tried using http-response set-header Content-Length 
>> %[res.hdr(content-length)] if { res.hdr(content-length) -m found } to force 
>> the value to upper case, but that didn't help.
> 
> This should be http-request though, not http-response, as only the
> request headers are impacted, right?
> 
> Can you confirm this doesn't work with http-request?
> 
> 
> Thanks,
> Lukas
> 

Re: Case Sensitive Headers

[Lukas Tribus]

Hello Luke

On Wed, 26 Jun 2019 at 16:08, Luke Seelenbinder  wrote:
> I tried using http-response set-header Content-Length 
> %[res.hdr(content-length)] if { res.hdr(content-length) -m found } to force 
> the value to upper case, but that didn't help.

This should be http-request though, not http-response, as only the
request headers are impacted, right?

Can you confirm this doesn't work with http-request?


Thanks,
Lukas

Re: Case Sensitive Headers

[Luke Seelenbinder]

Hello Lukas,

Thanks for getting back to me.

I'm game to try anything if you all have ideas with Lua or otherwise. We're 
looking at a server that's used less than 1% of our requests, but we need for 
legacy device support. :(

Best,
Luke

—
Luke Seelenbinder
SermonAudio.com  | Senior Software Engineer


> On Jun 26, 2019, at 16:17, Lukas Tribus  wrote:
> 
> Hello,
> 
> 
> On Wed, 26 Jun 2019 at 16:08, Luke Seelenbinder  wrote:
>> 
>> Hello List,
>> 
>> I have a painful case of noncompliance to report and figure out how to fix.
>> 
>> When HTX is enabled, all headers are returned in lower case (e.g., 
>> content-length, date, etc.). This is obviously fine and within spec. 
>> Unfortunately, I'm using a rather frustrating piece of software (Wowza) that 
>> talks to an haproxy instance and Wowza requires that the content-length 
>> header is always camel case, i.e., Content-Length, otherwise requests fail.
>> 
>> I tried using http-response set-header Content-Length 
>> %[res.hdr(content-length)] if { res.hdr(content-length) -m found } to force 
>> the value to upper case, but that didn't help.
>> 
>> This is very obviously a case of badly behaving software and not a problem 
>> with HAProxy, but I'm wondering if there's any other way to force that 
>> header to Content-Length without turning HTX off.
>> 
>> Thanks for any ideas!
> 
> Yeah I think we are gonna see more of such interoperability issues as
> people migrate to 2.0 with htx enabled:
> 
> https://discourse.haproxy.org/t/haproxy-2-0-0-header/3930/4
> 
> This is only the second time this has come up though.
> 
> 
> Maybe we can workaround this with some LUA magic?
> 
> 
> cheers,
> lukas
> 

Re: Case Sensitive Headers

[Lukas Tribus]

Hello,


On Wed, 26 Jun 2019 at 16:08, Luke Seelenbinder  wrote:
>
> Hello List,
>
> I have a painful case of noncompliance to report and figure out how to fix.
>
> When HTX is enabled, all headers are returned in lower case (e.g., 
> content-length, date, etc.). This is obviously fine and within spec. 
> Unfortunately, I'm using a rather frustrating piece of software (Wowza) that 
> talks to an haproxy instance and Wowza requires that the content-length 
> header is always camel case, i.e., Content-Length, otherwise requests fail.
>
> I tried using http-response set-header Content-Length 
> %[res.hdr(content-length)] if { res.hdr(content-length) -m found } to force 
> the value to upper case, but that didn't help.
>
> This is very obviously a case of badly behaving software and not a problem 
> with HAProxy, but I'm wondering if there's any other way to force that header 
> to Content-Length without turning HTX off.
>
> Thanks for any ideas!

Yeah I think we are gonna see more of such interoperability issues as
people migrate to 2.0 with htx enabled:

https://discourse.haproxy.org/t/haproxy-2-0-0-header/3930/4

This is only the second time this has come up though.


Maybe we can workaround this with some LUA magic?


cheers,
lukas

Case Sensitive Headers

[Luke Seelenbinder]

Hello List,

I have a painful case of noncompliance to report and figure out how to fix.

When HTX is enabled, all headers are returned in lower case (e.g., 
content-length, date, etc.). This is obviously fine and within spec. 
Unfortunately, I'm using a rather frustrating piece of software (Wowza) that 
talks to an haproxy instance and Wowza requires that the content-length header 
is always camel case, i.e., Content-Length, otherwise requests fail.

I tried using http-response set-header Content-Length 
%[res.hdr(content-length)] if { res.hdr(content-length) -m found } to force the 
value to upper case, but that didn't help.

This is very obviously a case of badly behaving software and not a problem with 
HAProxy, but I'm wondering if there's any other way to force that header to 
Content-Length without turning HTX off.

Thanks for any ideas!

Best,
Luke

—
Luke Seelenbinder
SermonAudio.com  | Senior Software Engineer