docs: clarify that auth-headers-* keys need to be in lowercase

[nadiamoe]

This is unfortunately not mentioned in https://github.com/TimWolla/haproxy-auth-request/tree/main, but after some debugging I think this is what is required. Specifying a list of headers using the case they're returned as will not work, while specifying them in lowercase will.

I have verified the casing of the headers via tcpdump. Moreover Authelia, a popular authentication backend, specifies the header names in lowercase in their example here, despite Authelia itself returning them in Header-Case.

[jcmoraisjr]

Hi, can you share if you faced some issue, and how you did your tests in a way that Camel-Case headers does not work? I'm a bit puzzled since per RFC-7230 HTTP headers are case insensitive, so it should work either way.

[nadiamoe]

I think headers are case insensitive, but the search that https://github.com/TimWolla/haproxy-auth-request does is not.

This function here converts the comma-separated list into a lua pattern: https://github.com/TimWolla/haproxy-auth-request/blob/cdb891cf52995780bb6128c2a7495d36325e4ff2/auth-request.lua#L38

and then gmatch is used here: https://github.com/TimWolla/haproxy-auth-request/blob/cdb891cf52995780bb6128c2a7495d36325e4ff2/auth-request.lua#L86

As far as I can tell, gmatch is case sensitive.

At some other point in the pipeline something must be lowercasing the headers that haproxy-auth-request is seeing (I verified that authelia returns it with Header-Case using tcpdump), I'm not sure where that may be.

[jcmoraisjr]

Ah sure, you're right. I not only misunderstood your proposal, but also ignored that Lua's string.match() isn't aware we are handling http headers that are case insensitive.

From my own tests I can (almost) confirm that haproxy-lua-http, used by auth-request, always handles header names in lowercase, despite on how it received the response, so your proposal does make sense to me: we just need to mimic how haproxy-lua-http works (always lower case) and how Lua's match() works as well (case sensitive match).

However, my proposal instead is to change this in the code, giving a better user experience for one expecting http headers to be case insensitive:

diff --git a/pkg/converters/ingress/annotations/backend.go b/pkg/converters/ingress/annotations/backend.go
index 52768257..56cfe73d 100644
--- a/pkg/converters/ingress/annotations/backend.go
+++ b/pkg/converters/ingress/annotations/backend.go
@@ -247,9 +247,9 @@ func (c *updater) setAuthExternal(config ConfigValueGetter, auth *hatypes.AuthEx
        if annHdrFail == "" {
                annHdrFail = "-"
        }
-       hdrRequest := strings.Split(annHdrRequest, ",")
-       hdrSucceed := strings.Split(annHdrSucceed, ",")
-       hdrFail := strings.Split(annHdrFail, ",")
+       hdrRequest := strings.Split(strings.ToLower(annHdrRequest), ",")
+       hdrSucceed := strings.Split(strings.ToLower(annHdrSucceed), ",")
+       hdrFail := strings.Split(strings.ToLower(annHdrFail), ",")

        if signin != "" {
                if !reflect.DeepEqual(hdrFail, []string{"*"}) {

What do you think? From my side I'll double check my findings in order to ensure that we don't have some corner cases.

[nadiamoe]

@jcmoraisjr Changing the code looks even better to me! 🎉
Perhaps we could still add a small note to the docs in that case, specifying it's case-insensitive. Just to avoid surprising someone which already has experience with auth-request/haproxy-lua-http.

[jcmoraisjr]

Sure, a short sentence stating that "header match is case insensitive" looks good, as a quick reminder about the http spec.