SetContentType middleware breaks Content-Type detection for requests
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 42/100
Research direction
Start by locating SetContentType, GetRequestContentType, and DefaultDecoder, then trace how the shared context key is read for request Content-Type detection. Confirm the existing middleware and decoder behavior, identify a focused regression test location, and consider the issue's proposed separation of context state; done means response handling no longer interferes with request detection.
Written by the indexing model from the issue text.
Description
The documentation for SetContentType only mentions responses and says nothing of requests:
SetContentType is a middleware that forces response Content-Type.
However, this breaks Content-Type detection for requests in the DefaultDecoder because SetContentType and GetRequestContentType share the same context key.
It's not obvious to me why GetRequestContentType even looks at the context, as that seems to betray the function name. But if that behavior is going to stay, I suggest using a separate context key so that SetContentType does not interfere.
- Dominant language
- Go
- Stars
- 341
- Forks
- 68
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from go-chi/render
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 5/5 Over a week Newbie friendliness 10/100
-
Any concern render.JSON() can leak internal errors to outside?Possibly taken @team-humaki claimed this 48 days ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 30/100
Similar issues
-
area: frontend priority: normal
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
TestAutonomousStop_ReportsObservedState fails under host load: 1s wall-clock ceiling vs 250ms cycleOpentype:bug
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
nightgauge/nightgauge#2909 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
jasonfen/terminal-space-program#842 ·
Maintainers usually reply within 1 day
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
MustacheCase/zanadir#521 ·
Maintainers usually reply within 1 day
-
v3.1.0: spread placement groups fail — label key uses the reserved hetzner.cloud prefixPossibly taken @ScrimReaper claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
stubbi/karpenter-provider-hetzner#120 ·
Maintainers usually reply within 4 days