Embed: proxy buffers for the subscribe response headers - #1548
Conversation
…headers A tenant blog answered 502 to its own signup form. The routing was right, host.docker.internal resolved and the origin answered, and what failed was the read: Next attaches a report-only CSP of about 3.5KB to every response, so even a 400 carries roughly 4.2KB of headers and overflows nginx's 4k default with "upstream sent too big header". eu.ecency.com already carries these buffers for exactly this reason. Here they sit on the location rather than the server block, because it is the only one proxying to the web tier; the rest go to hosting_api, whose headers are small. Verified against the live origin, using the production image on the compose network with the same host-gateway alias: the committed config answers 502 and this one passes the origin's own response through.
|
Warning Review limit reached
Next review available in: 38 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
PR Summary by QodoPrevent tenant newsletter proxy 502s from large response headers
AI Description
Diagram
High-Level Assessment
Files changed (1)
|
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTip of the day💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent |
Code Review by Qodo
1. Missing proxy buffer regression test
|
| proxy_buffer_size 16k; | ||
| proxy_buffers 8 16k; | ||
| proxy_busy_buffers_size 16k; |
There was a problem hiding this comment.
1. Missing proxy buffer regression test 📘 Rule violation ▣ Testability
This bug fix changes the nginx response-header buffering path, but the change set adds no automated regression test for an oversized upstream header producing a non-502 response. Manual verification in the PR description does not satisfy the requirement for a test that fails before the fix and passes after it.
Agent Prompt
## Issue description
The new proxy buffer configuration fixes an oversized upstream response-header failure, but no automated regression test was added.
## Issue Context
The test must reproduce an upstream response with headers larger than nginx's default buffer and assert that the request is passed through rather than returned as 502.
## Fix Focus Areas
- apps/self-hosted/hosting/nginx-multi-tenant.conf[153-155]
- apps/self-hosted/hosting
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Fixes #1547.
A tenant blog answers 502 to its own signup form. The routing added in #1542 is correct:
host.docker.internalresolves throughextra_hosts, TLS is fine and the origin answers. The read is what fails.Next attaches a ~3.5KB report-only CSP to every response, so even a 400 from the route carries about 4.2KB of headers, over nginx's 4k default
proxy_buffer_size. Measured on alpha, which runs develop and so has the route, with an invalid body so nobody was subscribed:400, 4250 bytes of response headers.eu.ecency.comalready carries these buffers with the same explanation. Here they go on the location rather than the server block, because the newsletter location is the only one proxying to the web tier; the others proxy tohosting_api, whose headers are small.Verification
Run against the live origin, using the production image
ecency/self-hosted:sha-4eead79on theecency-hostingnetwork with the samehost.docker.internal:host-gatewayalias production has:502404, the origin's own answer, passed throughnginx -tpasses in that image on that network.The remaining 404 is a separate and expected thing: the production origin has no
newsletterroute yet..next/server/app/api/in the runningecency/vision-web:latestliststhreespeak,hosting,oembedand the rest, with nonewsletter, so the relay reaches ecency.com only with the next develop to main deploy. Both this fix and that deploy are needed before a reader on a tenant blog can subscribe.