DataCook DataCook

304 응답을 보면 오류로 재시도하기 전에 요청의 검증자와 기존 캐시 본문을 함께 확인하세요.Network 창에 304가 보이면 200이 아니라는 이유로 실패라고 생각하기 쉽습니다. 하지만 304 Not Modified는 조건부 GET이나 HEAD에서 이미 가진 버전을 계속 써도 된다는 응답일 수 있습니다. 서버가 본문을 보내다 실패한 상황과는 다릅니다.문제는 숫자만 따로 볼 때 생깁니다. 무엇과 비교해서 바뀌지 않았다는 것인지, 그 버전의 본문을 누가 가지고 있는지까지 알아야 응답을 해석할 수 있습니다. 이 글은 2026년 9월 13일 MDN과 Fetch 명세를 기준으로 설명합니다. 요청과 응답은 가상 예시이며 실제 서버에서 캡처하거나 실행하지 않았습니다.ETag는 서버가 붙인 버전 식별자입니다ETag..

캐시 정책은 저장을 허용할지, 재사용 전에 확인할지, 누구와 공유할지의 세 질문으로 나눠 정하세요.Cache-Control: no-cache를 붙였는데 브라우저에 응답이 남아 있습니다. 이름만 보면 설정이 무시된 것 같지만, 저장 자체를 막고 싶었다면 선택한 지시어가 목적과 달랐을 수 있습니다. no-cache의 핵심은 저장 금지가 아니라 확인 없는 재사용 금지입니다.이 차이를 알아야 “항상 최신 내용을 보여 주세요”와 “이 응답을 HTTP 캐시에 남기지 마세요”를 다르게 구현할 수 있습니다. 아래는 2026년 9월 13일 HTTP 명세와 MDN 기준의 설명입니다. 헤더와 시간은 설계 예시이며 실제 서비스의 캐시를 측정하거나 삭제하지 않았습니다.no-cache는 저장한 응답을 확인하고 쓰게 합니다서버가 ..

쿠키 로그인 문제는 저장 여부, 전송 대상, SameSite 조건, 요청의 credentials, 응답 공유 순서로 확인하세요.개발자 도구에는 로그인 쿠키가 있는데 API는 비로그인 상태라고 합니다. 이때 SameSite를 None으로 바꾸는 것부터 시작하면 문제가 풀리지 않거나, 필요 이상으로 쿠키가 전송되는 범위를 넓힐 수 있습니다. 브라우저에 저장된 쿠키가 모든 요청에 붙는 것은 아니기 때문입니다.쿠키가 저장됐는지, 이번 요청의 목적지에 보낼 수 있는지, 실제로 보냈는지, 서버의 응답을 화면 코드가 읽을 수 있는지는 서로 다른 단계입니다. 이 글은 2026년 9월 13일 공식 문서 기준으로 그 단계를 나눕니다. 주소와 토큰은 설명용이며 실제 로그인이나 설정 변경은 하지 않았습니다.같은 사이트와 같은..

CORS 오류는 브라우저의 Origin, 사전 요청, 실제 응답 헤더를 차례로 대조해 원인을 좁히세요.curl에서는 JSON이 잘 오는데 웹 화면에서는 CORS 오류가 납니다. 서버가 완전히 정상인데 브라우저만 고장 났다는 뜻은 아닙니다. curl이 응답을 받는 것과 브라우저가 다른 출처의 스크립트에 그 응답을 읽게 허용하는 것은 다른 조건입니다.특히 CORS 오류가 났다고 실제 요청이 서버에 전혀 도착하지 않았다고 단정하면 안 됩니다. 사전 요청에서 막힌 것인지, 본 요청은 처리됐지만 응답을 읽지 못한 것인지 먼저 구분해야 합니다. 아래는 2026년 9월 13일 MDN·Fetch 관련 문서 기준의 설명이며 실제 서버에 요청하거나 설정을 바꾸지 않았습니다.브라우저가 비교하는 Origin부터 확인합니다Or..

PostgreSQL 18에서 수정 전후 값이 필요하면 RETURNING의 old와 new를 명시하고 반환 행 수까지 함께 확인하세요.값을 바꾸기 전에 SELECT로 읽고, UPDATE한 뒤 다시 SELECT로 읽는 코드는 이해하기 쉽습니다. 하지만 조회 사이에 다른 작업이 같은 행을 바꿀 수 있습니다. 변경 전후를 보고하려던 두 조회가 실제로 이번 UPDATE가 다룬 행의 전후와 일치하는지 따로 고민해야 합니다.PostgreSQL 18에서는 RETURNING에서 old와 new를 명시해 변경 전후 값을 함께 받을 수 있습니다. 다만 반환값을 받았다는 사실이 트랜잭션의 최종 커밋이나 업무 전체 완료를 의미하지는 않습니다. 아래는 2026년 9월 13일 공식 문서 기준의 설명이며 실제 데이터베이스에서 UPD..

Ruff에서는 코드 규칙 검사와 포맷 검사를 별도로 실행해 어떤 종류의 수정이 필요한지 구분하세요.저장할 때 코드 모양이 깔끔해졌는데 CI에서는 Ruff 오류가 남습니다. 반대로 ruff check가 통과했는데 ruff format --check는 실패하기도 합니다. 두 명령이 같은 파일을 봐도 질문이 다르기 때문입니다. 하나는 선택한 코드 규칙의 위반을 찾고, 다른 하나는 정해진 배치와 표기 방식으로 정리할 부분이 있는지 봅니다.이 글은 2026년 9월 13일 공식 문서를 기준으로 두 작업을 나누는 방법을 설명합니다. 예시 코드는 진단 차이를 보여 주기 위해 작성했으며 실제 Ruff 실행 결과를 옮긴 것이 아닙니다. 기존 프로젝트를 일괄 수정하거나 자동 실행 설정을 추가하는 작업도 하지 않았습니다.포맷..

예전 Cloudflare Workflows에서는 오래된 실행 상태를 볼 수 있었는데 새로 만든 워크플로에서는 더 빨리 사라진다면, 코드만 비교하지 말고 생성 시점과 보존 설정을 함께 확인해야 합니다. 같은 서비스 안에서도 기존 작업과 새 작업이 다른 기본값을 사용할 수 있습니다.Cloudflare Workflows를 새로 만들 때는 성공과 오류 인스턴스 상태를 각각 며칠 보존할지 명시적으로 검토하세요.2026년 9월 10일 공지는 그날 이후 생성한 Workers Paid 워크플로의 완료·오류 인스턴스 상태 기본 보존을 7일로 바꾼다고 안내합니다. 다만 확인한 API·요금 문서에는 다른 기본값 설명이 남아 있어, 옵션을 생략한 모든 실행 경로의 값을 여기서 단정하지는 않습니다.새 워크플로와 기존 워크플로를..

코드와 데이터가 그대로인데 어느 시점부터 D1 쿼리가 실패한다면, 최근 배포만 조사해서는 원인을 찾지 못할 수 있습니다. 무료 플랜의 일일 사용량 한도에 도달한 상황이라면 쿼리를 다시 보내도 같은 제약이 이어질 수 있기 때문입니다.D1 한도 오류가 나면 요청 횟수보다 읽고 쓴 행 수와 UTC 기준 초기화 시각부터 확인하세요.Cloudflare의 2026년 9월 1일 공지는 Workers Free 계정이 D1의 일일 읽기·쓰기 행 한도를 넘으면 Workers Binding API와 REST API의 쿼리가 실패한다고 설명합니다. 한도는 UTC 자정에 초기화되며, 이 제한 때문에 저장된 데이터 자체가 바뀌는 것은 아니라고 명시합니다.반환한 행 수와 읽은 행 수는 다릅니다화면에 결과가 한 건 보였다고 데이터베..