<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>CORS on 얼쑤 · Team Edo</title><link>https://team-edo.github.io/tags/cors/</link><description>Recent content in CORS on 얼쑤 · Team Edo</description><generator>Hugo</generator><language>ko-kr</language><lastBuildDate>Tue, 03 Nov 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://team-edo.github.io/tags/cors/index.xml" rel="self" type="application/rss+xml"/><item><title>206 응답 뒤에 숨은 CORS 오류</title><link>https://team-edo.github.io/posts/2026/11/cors-after-audio-redirect/</link><pubDate>Tue, 03 Nov 2026 00:00:00 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/11/cors-after-audio-redirect/</guid><description>&lt;p>얼쑤의 모범 연주 음원 API를 Swagger에서 확인하다가 &lt;code>Failed to fetch&lt;/code>를 만났습니다. 같은 음원의 처음 2바이트를 &lt;code>curl&lt;/code>로 요청하니 저장소는 HTTP 206을 반환했습니다. 저장소가 바이트를 보내고도 브라우저에서 읽을 수 없는 이유를 찾으려면, 처음 요청한 API와 음원을 실제로 돌려주는 서버를 나눠 봐야 했습니다.&lt;/p>
&lt;h2 id="302-뒤의-응답을-확인했다">302 이후의 응답 추적&lt;/h2>
&lt;p>Swagger 페이지와 음원 API는 같은 출처에 있었습니다. API는 곡과 음원의 게시 상태를 확인한 뒤 HTTP 302의 &lt;code>Location&lt;/code> 헤더에 R2 서명 URL을 담았습니다. 브라우저가 리다이렉트를 따라가면 음원 본문은 다른 출처인 R2에서 내려옵니다. 그 응답에는 Swagger 페이지의 출처를 허용하는 &lt;code>Access-Control-Allow-Origin&lt;/code>이 없었습니다. 브라우저는 저장소 응답을 받았지만 페이지의 자바스크립트에 넘기지 않았습니다. &lt;a href="https://fetch.spec.whatwg.org/#cors-check">Fetch 표준의 CORS 검사&lt;/a>&lt;/p></description></item></channel></rss>