How to: Set a 5MB buffer for the client
gosmee client --sse-buffer-size 5242880
```

###### Important Considerations

Increasing payload and buffer sizes has security and performance implications:

- **Increased Memory Consumption**: Both the client and server will consume more memory when these limits are raised. A server handling many simultaneous large webhooks, or a client with a large buffer, can use quite a bit of RAM.
- **Denial-of-Service (DoS) Risk**: Exposing a server with a very large `max-body-size` can make it a target for DoS attacks, where an attacker sends huge payloads to exhaust server memory.
- **Kubernetes Deployments**: If you're running `gosmee` in Kubernetes and increase these limits, you **must** update the memory `requests` and `limits` in the `gosmee-server-deployment.yaml` and `gosmee-client-deployment.yaml` files. Failure to do so may cause your Pods to be OOMKilled (Out Of Memory) by Kubernetes.

Always set these values to the lowest practical limit that still accommodates your expected webhook sizes.

##### Channel Name Protection

To prevent potential DoS attacks and ensure system stability:

- Channel names are limited to 64 characters maximum
- All route handlers (`/`, `/events/{channel}`, `/replay/{channel}`, POST `/{channel}`) enforce this limit
- Built-in validation for all endpoints that handle channel names
- Protects against resource exhaustion attacks that could be caused by excessive channel name lengths

##### Webhook Signature Validation

When running gosmee server, you can enable webhook signature validation for multiple providers with multiple secrets:

```shell
gosmee server --webhook-signature=SECRET1 --webhook-signature=SECRET2
```

When enabled:

- For GitHub: Validates X-Hub-Signature-256 header using HMAC SHA-256
- For GitLab: Validates X-Gitlab-Token header using secure token comparison
- For Bitbucket Cloud/Server: Validates X-Hub-Signature header using HMAC SHA-256
- For Gitea/Forge: Validates X-Gitea-Signature header using HMAC SHA-256
- Supports multiple secrets - useful when receiving webhooks from different sources
- Rejects requests with missing or invalid signatures with HTTP 401 Unauthorised
- Each secret is tried for validation, webhook is accepted if any secret matches
- Performance impact is minimal: ~2μs per validation with negligible memory usage

You can also set multiple secrets via the `GOSMEE_WEBHOOK_SIGNATURE` environment variable by separating them with commas.