Webhooks post X-Github-* should be X-GitHub-* #1423

New Issue

GiteaMirror · 2025-11-02T04:00:18-06:00

GiteaMirror commented

2025-11-02 04:00:18 -06:00

Originally created by @robe2 on GitHub (Jan 5, 2018).

Gitea version (or commit ref): 1.3.2+3-g88c363f9
Git version: 1.7
Operating system: Debian
Database (use [x]):
- [x ] PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- [x ] Not relevant
Log gist:

Description

I setup a Jenkins generic web hook with hopes to handle both gitea and github pull requests and for the most part gitea can impersonate a github webhook.
However my webhook was looking for filter:

X-GitHub-Event

note the uppercase H this is because GitHub's pull requests have a header like this:

X-GitHub-Delivery: 23f8ed5c-f240-11e7-84b3-acee9f3589e5
X-GitHub-Event: pull_request

While Gitea outputs like this:

X-Github-Delivery: 5c2938d1-ec68-458d-af63-cc29919ffbbf
X-Github-Event: pull_request

The h should be upper-cased to be consistent with how GitHub posts their web hooks
...

Screenshots

Originally created by @robe2 on GitHub (Jan 5, 2018).  - Gitea version (or commit ref): 1.3.2+3-g88c363f9 - Git version: 1.7 - Operating system: Debian - Database (use `[x]`): - [x ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x ] Not relevant - Log gist: ## Description I setup a Jenkins generic web hook with hopes to handle both gitea and github pull requests and for the most part gitea can impersonate a github webhook. However my webhook was looking for filter: X-GitHub-Event note the uppercase H this is because GitHub's pull requests have a header like this: ``` X-GitHub-Delivery: 23f8ed5c-f240-11e7-84b3-acee9f3589e5 X-GitHub-Event: pull_request ``` While Gitea outputs like this: ``` X-Github-Delivery: 5c2938d1-ec68-458d-af63-cc29919ffbbf X-Github-Event: pull_request ``` The h should be upper-cased to be consistent with how GitHub posts their web hooks ... ## Screenshots

GiteaMirror added the type/bug label 2025-11-02 04:00:18 -06:00

GiteaMirror closed this issue

2025-11-02 04:00:18 -06:00

GiteaMirror commented

2025-11-02 04:00:19 -06:00

@robe2 commented on GitHub (Jan 5, 2018):

I'll try to provide a patch for this once I'm setup unless this casing was intentional for some reason. Still studying gitea code-base.

@robe2 commented on GitHub (Jan 5, 2018): I'll try to provide a patch for this once I'm setup unless this casing was intentional for some reason. Still studying gitea code-base.

GiteaMirror commented

2025-11-02 04:00:19 -06:00

@strk commented on GitHub (Jan 5, 2018):

The code seems to have right casing:
https://github.com/go-gitea/gitea/blob/v1.3.2/models/webhook.go#L581-L586
maybe something re-cases it ?

@strk commented on GitHub (Jan 5, 2018): The code seems to have right casing: https://github.com/go-gitea/gitea/blob/v1.3.2/models/webhook.go#L581-L586 maybe something re-cases it ?

GiteaMirror commented

2025-11-02 04:00:19 -06:00

@strk commented on GitHub (Jan 5, 2018):

From go doc http.Request:

        // HTTP defines that header names are case-insensitive. The
        // request parser implements this by using CanonicalHeaderKey,
        // making the first character and any characters following a
        // hyphen uppercase and the rest lowercase.

@strk commented on GitHub (Jan 5, 2018): From go doc http.Request: ``` // HTTP defines that header names are case-insensitive. The // request parser implements this by using CanonicalHeaderKey, // making the first character and any characters following a // hyphen uppercase and the rest lowercase. ```

GiteaMirror commented

2025-11-02 04:00:19 -06:00

@robe2 commented on GitHub (Jan 5, 2018):

hmm I wonder how many tools abide by that rule. Since it's coming thru as a key-value store the casing is preserved when I query it and two terms have different keys. I assume any language that are case sensitive might have similar issue.

Though if it's meant to be case sensitive anyway why does the http lib bother changing the case of input from what programmer specified? Seems like a needless exercise that just causes confusion.

@robe2 commented on GitHub (Jan 5, 2018): hmm I wonder how many tools abide by that rule. Since it's coming thru as a key-value store the casing is preserved when I query it and two terms have different keys. I assume any language that are case sensitive might have similar issue. Though if it's meant to be case sensitive anyway why does the http lib bother changing the case of input from what programmer specified? Seems like a needless exercise that just causes confusion.

GiteaMirror commented

2025-11-02 04:00:20 -06:00

@lafriks commented on GitHub (Jan 5, 2018):

I think most the languages that have standard lib for header parsing have keys case insensitive

@lafriks commented on GitHub (Jan 5, 2018): I think most the languages that have standard lib for header parsing have keys case insensitive

GiteaMirror commented

2025-11-02 04:00:20 -06:00

@robe2 commented on GitHub (Jan 5, 2018):

Okay then it's probably not worth the bother fixing given it's so deeply embedded.

@robe2 commented on GitHub (Jan 5, 2018): Okay then it's probably not worth the bother fixing given it's so deeply embedded.

GiteaMirror commented

2025-11-02 04:00:20 -06:00

@robe2 commented on GitHub (Jan 5, 2018):

Just closed this before I read this related ticket

https://github.com/golang/go/issues/5022

Would it be possible to use header key directly just for this GitHub thing that really should match what github is posting in their webhook?

If that's agreeable I'll be happy to reopen this and test it out.

@robe2 commented on GitHub (Jan 5, 2018): Just closed this before I read this related ticket https://github.com/golang/go/issues/5022 Would it be possible to use header key directly just for this GitHub thing that really should match what github is posting in their webhook? If that's agreeable I'll be happy to reopen this and test it out.

GiteaMirror commented

2025-11-02 04:00:20 -06:00

@strk commented on GitHub (Jan 5, 2018):

For the sake of compatibility I'd try retaining the expected casing.

@strk commented on GitHub (Jan 5, 2018): For the sake of compatibility I'd try retaining the expected casing.

GiteaMirror commented

2025-11-02 04:00:20 -06:00

@bkcsoft commented on GitHub (Jan 8, 2018):

Headers are case insensitive, Jenkins is broken and should be fixed 🙄

4.2 => https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html

@bkcsoft commented on GitHub (Jan 8, 2018): Headers are case insensitive, Jenkins is broken and should be fixed 🙄 4.2 => https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html

GiteaMirror commented

2025-11-02 04:00:20 -06:00

@strk commented on GitHub (Jan 9, 2018):

beside Jenkins being or not broken, this issue is about the GitHub compatibility header being NOT THE SAME as the one sent by GitHub. If we want to comply let's comply

@strk commented on GitHub (Jan 9, 2018): beside Jenkins being or not broken, this issue is about the GitHub compatibility header being NOT THE SAME as the one sent by GitHub. If we want to comply let's comply

GiteaMirror commented

2025-11-02 04:00:21 -06:00

@thehowl commented on GitHub (Jan 9, 2018):

I agree on the change. Though it might cause some breakage, users which depend on the casing have an underlying problem in their http lib, which is that of headers being case sensitive when they should be insensitive. On the plus side, we get API that is compatible with github.

@thehowl commented on GitHub (Jan 9, 2018): I agree on the change. Though it might cause some breakage, users which depend on the casing have an underlying problem in their http lib, which is that of headers being case sensitive when they should be insensitive. On the plus side, we get API that is compatible with github.

GiteaMirror referenced this issue

2025-11-02 11:57:16 -06:00

[PR #1423] [MERGED] Support for custom html meta #15900

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#1423