Repository navigation
fix(web): set explicit content headers on proxied storage responses - #2996
Merged
Merged
Conversation
![capy-ai[bot]](https://avatars.githubusercontent.com/in/1915919?s=60&v=4){kind=small}
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| const upstream = (contentType: string | null, init: ResponseInit = {}) => { | ||
| const headers = new Headers(init.headers); | ||
| if (contentType) headers.set("Content-Type", contentType); | ||
| return new Response("data", { status: init.status ?? 200, headers }); |
Contributor
There was a problem hiding this comment.
upstream(null) does not produce a response without Content-Type. new Response("data", ...) automatically adds text/plain;charset=UTF-8, so this repeats the plain-text case and leaves the missing-header fallback untested. Delete Content-Type from the constructed response when the input is null, then assert it is absent before calling GET.
Prompt To Fix With AI
This is a comment left during a code review.
Path: apps/web/__tests__/unit/storage-object-response-headers.test.ts
Line: 54
Comment:
**Missing-header case repeats plain text**
`upstream(null)` does not produce a response without `Content-Type`. `new Response("data", ...)` automatically adds `text/plain;charset=UTF-8`, so this repeats the plain-text case and leaves the missing-header fallback untested. Delete `Content-Type` from the constructed response when the input is `null`, then assert it is absent before calling `GET`.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Member
Author
|
@greptileai review |
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Responses that
/api/storage/objectstreams from storage now always sendX-Content-Type-Options: nosniffand asandbox; default-src 'none'CSP. The upstreamContent-Typeis only passed through when it is one of the media, image, caption, playlist or JSON types this route serves; anything else is sent asapplication/octet-streamwithContent-Disposition: attachment. The HEAD branch follows the same rules, and the redirect and internal download branches are unchanged.Testing
bun run biome check --writeon the touched filesnpx vitest runforstorage-object-response-headers,storage-object-verification,storage-object-route,playback-sourceandmp4-level-patch(90 passed)cd apps/web && npx tsc --noEmit(clean)
The PR appears safe to merge, with the previous test issue fixed and no new findings.Summary
Adds explicit content headers to storage responses.
Reviews (2) · Last reviewed commit: "test(web): exercise missing content type..." · Reviewed by Greptile