According to claude.ai:

RFC 7230 is part of the HTTP/1.1 specification and states that header field names are case-insensitive. This means that while header names might be written with specific capitalization in documentation (often in "Train-Case" with initial capitals like "Content-Type"), the actual implementation should treat them as case-insensitive.
The relevant quote from RFC 7230, section 3.2 is:
"Each header field consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the field value, and optional trailing whitespace."

So my interpretation of this is that our casing of GitHub in custom header fields doesn't really matter, and the only reason that we've chosen the way it is was discussed in another issue many years ago where we decided to be self-consistent and use Train-Case.

So unless there is a good reason to change it (which I don't think there is but am willing to listen), I think we should close this issue.

Looking through the code, we have specifically chosen to make the keys canonical in #3389.

Closing due to reasons listed in #3389.

Hi @gmlewis,

Sorry, but I should try to protect my changes here. Unfortunately the mentioned #3389 does not completely apply here: the mentioned headers in #3389 are internal for the go-github package, the changed ones in this PR are external. I would also understand if the standard will be used by GitHub here - but it's clearly is not, so what's the point of following the standard if it makes interface to not work correctly, forcing the developer to jump through hoops?

But maybe I'm wrong here and using the provided interfaces incorrectly - maybe you can tell me what to do in the following case:

The issue I have with those headers: when I try to parse webhook (both from github.HookDelivery & incoming webhook) I need to read the headers like that:

guid, ok := headers[github.DeliveryIDHeader] // Bug here due to incorrect key
if !ok {
    return fmt.Errorf("Can't find delivery GUID in headers")
}
sig, ok := headers[github.SHA256SignatureHeader]
if !ok {
    return fmt.Errorf("Can't find delivery signature in headers")
}
eventType, ok := headers[github.EventTypeHeader] // Bug here due to incorrect name
if !ok {
    return fmt.Errorf("Can't find delivery event type in headers")
}

Since those are used on client receiving side (defined and once used in r.Header.Get() in the same messages.go) - I'm not quite sure the provided example applies here. Instead I would need to do canonicalization by http.CanonicalHeaderKey now, so is it worth it? Maybe there is a better way you could suggest?

Thank you

Oh, I see. You are trying to use these directly to look up the values.
I'm sorry I didn't understand before. Reopening issue.
I'm pretty sure there is a Get call in the headers API that will do all the work for you... I'll reopen and then investigate and report back.

Have you tried this? https://pkg.go.dev/net/http#Header.Get

https://pkg.go.dev/net/http#Header.Get is pretty industry-standard.
I would say that if Header.Get doesn't work for you, then it is time to contact GitHub v3 API tech support and point them to this issue and see what they have to say.

The issue I have right now is with HookDelivery accessed by REST API - we have to use it to make sure no webhook requests are missing due to network issues.

Unfortunately HookDelivery and it's internal HookRequest are not providing easy way to access Headers but to use map interface...

The issue I have right now is with HookDelivery accessed by REST API - we have to use it to make sure no webhook requests are missing due to network issues.

Unfortunately HookDelivery and it's internal HookRequest are not providing easy way to access Headers but to use map interface...

Ah, I see what you mean. Then I would suggest a different way of fixing this.
I suggest that you leave all the canonicalized keys alone - please don't change their cases.
Instead, modify the existing implementation or helper functions to internally canonicalize the externally-generated header keys so that the helper functions in this repo work correctly.

The reason I don't want to change the casing of our constant strings is not only because of the standard, but GitHub could change the capitalization of their strings every other Monday and we would have to attempt to jump through hoops to keep up-to-date with their changes.

Therefore, let us fix this once and fix it such that no matter what capitalization is sent to this client library, it can handle it and work correctly.

Would you like to work on what I have suggested, or would you prefer that we turn this into an issue (instead of a PR) and have someone else tackle this issue, @sparshev ?

Thank you for explaining @gmlewis , appreciate your help!

Yeah, let's maybe turn it into an issue then - since those header keys are interfaces for the user of the library, I think they need to be good enough to use with the library data interfaces. Maybe the HookRequest itself could implement the http.Header.Get - kind of interface...