"네 프론트엔드는 여전히 브라우저야. fetch를 부르는 순간, 잊고 있던 브라우저 규칙이 전부 돌아와 — CORS 포함."
함정: 웹뷰의 fetch는 브라우저 fetch야
잊기 쉽지만, 네 UI를 돌리는 웹뷰는 브라우저고, 프론트엔드의 fetch()는 브라우저 보안을 따라 — CORS 포함. 구체적이고 미치게 하는 구석: JavaScript는 서버가 Access-Control-Expose-Headers로 명시적으로 허락한 응답 헤더만 읽을 수 있어. 요청은 성공하고, body는 멀쩡한데, response.headers.get("X-My-Custom")이 null을 반환해 — 헤더가 없어서가 아니라, 서버가 동의 안 하면 브라우저가 JS한테 숨겨서야. 이게 Cinder의 디버깅 세션 하나를 잡아먹었어: 커스텀 헤더가 보내지고 있었는데, 웹뷰가 그냥 안 보여줬어.
고침 1: 헤더를 노출해 (서버를 통제한다면)
서버가 네 거면 헤더 이름을 Access-Control-Expose-Headers에 추가해. 이제 웹뷰의 fetch가 그걸 읽을 수 있어. API가 네 통제 하면 이게 올바른 고침이야 — 평범한 CORS 설정이고, cross-origin API를 치는 어떤 웹 앱이든 하듯이.
고침 2: Rust를 거쳐가 (탈출구)
더 깊은 수: 웹뷰에서 HTTP 호출을 아예 안 해. Rust에서 해 — command 안에서 reqwest나 공식 tauri-plugin-http로 — 그리고 데이터(나 네가 신경 쓰는 헤더)를 프론트엔드에 반환해. Rust 코어는 브라우저가 아니야. CORS가 안 걸려. 이건 헤더 문제를 비껴가는 동시에 API 키 같은 비밀을 웹뷰 밖에 둬. 프론트엔드 네트워킹이 CORS로 너랑 싸우면, 그 요청이 대신 Rust에 속하는지 물어봐.