Source: CodeRabbit feedback on #309 (deferred from the v0.35.1 release fix PR #311)
Current behaviour: `triggers/actions.py:execute_http_forward` builds the outgoing headers like this:
```python
headers = {
"Content-Type": "application/json",
**rendered_headers,
}
```
User-supplied `forward_headers` correctly overrides the default (last-key-wins), so this is recoverable per webhook config. But for users that forward raw bodies of unknown type (multipart/form-data, application/x-www-form-urlencoded, text/plain, etc.) the default mislabels the body until they manually set `Content-Type`.
Suggested fix:
- Don't force a default Content-Type for raw forwards
- Or: only set the default when the upstream request had no Content-Type
- Or: detect the original request's Content-Type and propagate it
Why deferred: Users CAN fix this in config today via `forward_headers`, so it's not a silent corruption bug. The release blocker fixes (#309) were prioritised; this is correctness polish.
Files: `src/untether/triggers/actions.py` around line 226-229
Source: CodeRabbit feedback on #309 (deferred from the v0.35.1 release fix PR #311)
Current behaviour: `triggers/actions.py:execute_http_forward` builds the outgoing headers like this:
```python
headers = {
"Content-Type": "application/json",
**rendered_headers,
}
```
User-supplied `forward_headers` correctly overrides the default (last-key-wins), so this is recoverable per webhook config. But for users that forward raw bodies of unknown type (multipart/form-data, application/x-www-form-urlencoded, text/plain, etc.) the default mislabels the body until they manually set `Content-Type`.
Suggested fix:
Why deferred: Users CAN fix this in config today via `forward_headers`, so it's not a silent corruption bug. The release blocker fixes (#309) were prioritised; this is correctness polish.
Files: `src/untether/triggers/actions.py` around line 226-229