상태코드는 요청 처리 결과를 분류하는 출발점입니다. 그러나 200만 보고 API 연동 성공으로 판단하면 로그인 HTML을 JSON으로 읽으려는 오류를 놓칠 수 있습니다. win-j의 리디렉션과 관리자 경로를 기준으로, 코드·헤더·본문을 함께 읽는 순서를 정리합니다.
처음 응답과 마지막 응답을 구분하기
현재 코드에서 /utility/utiliys/는 도구 목록 /utility/로 보내는 예전 경로입니다. 이름의 오타까지 포함한 기존 주소를 유지하면서 영구 이동 응답을 보냅니다. 반면 로그인하지 않은 사용자의 /manager/utility-search-api/ 요청은 관리자 로그인 화면으로 이동시킵니다.
| 로컬에서 확인하는 요청 | 첫 응답 | 해석 |
|---|---|---|
| 예전 도구 목록 경로 | 301, Location: /utility/ |
도구 목록 주소로 영구 이동 |
| 비로그인 관리자 검색 | 302, 로그인 경로 | JSON 결과를 받기 전에 인증 필요 |
| 존재하지 않는 게시글 주소 | 404 | 해당 경로의 공개 글을 찾지 못함 |
| staff 사용자의 제목 없는 글 저장 | 400, JSON 안내 | 필수 입력 검사 실패. CSRF 검사를 통과한 요청 기준 |
이 표는 프로젝트 경로와 로컬 테스트에 대한 설명입니다. 역방향 프록시를 포함한 운영 응답은 배포 설정에 따라 별도로 확인해야 합니다. 특히 302 → 로그인 페이지의 200 흐름에서는 마지막 응답이 정상 HTML이어도 원래 원했던 검색은 성공하지 않았습니다.
브라우저에서 확인할 세 곳
- 개발자 도구의 Network 탭에서 요청 기록 보존을 켜고 해당 동작을 한 번 실행합니다.
- 원래 요청의 Status와
Location을 보고 이동이 있었는지 확인합니다. - 마지막 응답의
Content-Type과 Preview 또는 Response를 봅니다. JSON 목록인지 로그인 HTML인지 구분합니다.
기록을 다른 사람에게 전달할 때는 Cookie, Authorization, 개인정보가 포함된 본문을 지웁니다. 로그인 문제를 재현하려고 운영 관리자 비밀번호를 코드에 넣을 필요는 없습니다.
자주 보는 코드의 차이
| 코드 | 의미 | 다음 확인 |
|---|---|---|
| 200 | 요청 성공 | 실제 본문이 기대한 결과인지 |
| 201 | 리소스 생성 | 생성된 대상과 Location |
| 204 | 성공, 응답 콘텐츠 없음 | .json()을 호출하지 않는지 |
| 301 / 308 | 영구 이동 | 새 주소. 308은 메서드를 유지 |
| 302 / 307 | 임시 이동 | 로그인·임시 경로. 307은 메서드를 유지 |
| 304 | 조건부 요청에서 표현이 바뀌지 않음 | 로컬 캐시 사용. 새 페이지 이동이 아님 |
| 400 | 요청 처리에 필요한 조건을 충족하지 못함 | 필드·형식과 서버 안내 |
| 401 / 403 | 인증 필요 / 접근 거절 | 인증 방식, 권한, CSRF 등 |
| 404 / 405 | 대상 없음 / 지원하지 않는 메서드 | URL과 Allow 헤더 |
| 429 | 요청 빈도 제한 | Retry-After와 제공자 제한 |
| 500 / 502 / 503 / 504 | 서버 처리·게이트웨이·가용성·시간 초과 문제 | 발생 시각과 해당 계층의 로그 |
모든 3xx가 다른 주소로의 이동은 아니고, 모든 4xx가 사람이 입력을 잘못했다는 뜻도 아닙니다. 예를 들어 배포 후 CSRF 설정 불일치로 정상 폼이 403을 받을 수 있습니다. HTTP 상태코드 정의
Python으로 첫 응답만 확인하기
아래 코드는 공개된 예전 도구 목록 주소에 GET 한 번을 보냅니다. 출력은 실행 시점의 서버 상태에 따라 달라집니다.
import requests
response = requests.get(
"https://win-j.com/utility/utiliys/",
timeout=(3.05, 10),
allow_redirects=False,
)
print(response.status_code)
print(response.headers.get("Location", "이동 주소 없음"))
print(response.headers.get("Content-Type", "형식 미지정"))
Requests의 GET은 기본적으로 리디렉션을 따라갑니다. 따라서 첫 응답을 보려면 위처럼 이동을 끄고, 이미 이동을 따라간 요청에서는 response.history와 response.url을 함께 확인합니다. Requests 리디렉션 처리
실패 요청을 다시 보내기 전
조회 요청은 일시적 장애 여부를 확인해 제한적으로 재시도할 수 있습니다. 반면 글 저장·결제 같은 POST가 시간 초과된 경우 서버에서는 이미 처리가 끝났을 수 있습니다. 무조건 반복하면 중복 생성으로 이어집니다. 저장 결과 조회, 요청 식별자, 해당 API의 재시도 규칙을 먼저 확인합니다.
상태코드를 기록할 때는 메서드·경로·시각·응답 형식까지 함께 적으면 같은 403이나 500도 원인을 좁히기 쉬워집니다. 헤더 확인 방법과 CORS·CSRF 구분은 이 다음 점검에 사용합니다.
첫 댓글을 남겨보세요.