Custom HTTP Notification appends charset=utf-8 to application/x-www-form-urlencoded causing incompatible requests

[Niopt]

Environment

• Graylog: 6.0.12
• Notification type: Custom HTTP Notification

Problem

Custom HTTP Notification always sends

Content-Type: application/x-www-form-urlencoded; charset=utf-8

instead of

Content-Type: application/x-www-form-urlencoded

The charset=utf-8 cannot be removed or overridden.

Target API

VK Teams Bot API

Endpoint:

https://myteam.mail.ru/bot/v1/messages/sendText

Expected behavior

Graylog should send

Content-Type: application/x-www-form-urlencoded

without automatically appending charset.

Actual behavior

Graylog sends

Content-Type: application/x-www-form-urlencoded; charset=utf-8

The request reaches the server, but VK Teams rejects or ignores it.

Verification

The same request works correctly from:

• curl
• Postman

Example:

curl -X POST \
https://myteam.mail.ru/bot/v1/messages/sendText \
-H "Content-Type: application/x-www-form-urlencoded" \
--data-urlencode "token=..." \
--data-urlencode "chatId=..." \
--data-urlencode "text=test"

If

charset=utf-8

is added to Content-Type, the request no longer works.

This was verified using:

• curl
• Postman
• Webhook.site

Webhook.site confirms that Graylog correctly sends:

• POST
• x-www-form-urlencoded
• correct request body

The only visible difference is the automatically appended charset.

Additional information

The Headers field cannot override the generated Content-Type header.

[drewmiranda-gl]

I did a little digging and found this appears to be how the okhttp client (edit to add: Which graylog uses for sending web requests) behaves. If a charset is not explicitly defined, which graylog does not, okhttp automatically appends the UTF_8 charset. See https://github.com/lysine-dev/okhttp/blob/61423f472da24e0ccc42b6a2c0863fb27932fea5/okhttp/src/commonJvmAndroid/kotlin/okhttp3/internal/internal.kt#L92-L105

While I always defer to our devs, IMO, this is working as designed and would not be considered a bug.

Some questions to help us:

• Can you expand on what "rejects or ignores it" means?
• Do you get a specific HTTP response code?
• Does the server log any error(s)?
• What is the web server?

[Niopt]

I discovered that this header is causing the problem.
Step-by-step reproduction of the problem:

Request without charset=utf-8

curl -i -X POST 'https://myteam.mail.ru/bot/v1/messages/sendText' -H 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'token=token' --data-urlencode 'chatId=chat_id' --data-urlencode 'text= test'

Answer:

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 21 Jul 2026 06:00:37 GMT
Content-Type: application/json;charset=utf-8
Content-Length: 44
Connection: keep-alive
Keep-Alive: timeout=75
x-envoy-upstream-service-time: 152
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-XSS-Protection: 1; mode=block; report=https://cspreport.mail.ru/xxssprotection
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
{"msgId": "7678598123916985458", "ok": true}

Request with charset=utf-8

curl -i -X POST 'https://myteam.mail.ru/bot/v1/messages/sendText' -H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8' --data-urlencode 'token=token' --data-urlencode 'chatId=chat_id' --data-urlencode 'text=test'

Answer:

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 21 Jul 2026 06:00:55 GMT
Content-Type: application/json;charset=utf-8
Content-Length: 60
Connection: keep-alive
Keep-Alive: timeout=75
x-envoy-upstream-service-time: 2
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-XSS-Protection: 1; mode=block; report=https://cspreport.mail.ru/xxssprotection
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
{"ok": false, "description": "Required parameter not found"}

Graylog adds this header; I checked it in Postman. I can't change the messenger API yet. Are there any solutions?