종합 연습 — HTTP 대화를 케이스로 읽어낸다

Location 의 행선지를 따라가면 /mypage → /login → /mypage 의 순환이 보입니다. 전형적인 원인은, 로그인 판정의 조건(Cookie 의 유무 등)이 2 개의 페이지에서 어긋나 서로 상대에게 이동시키는 것입니다. 브라우저는 일정 횟수에서 끊고 이 오류를 냅니다. 503 이라면 Status 에 그렇게 나올 것이고, DNS 가 망가져 있으면 애초에 접속할 수 없습니다. curl 은 루프를 한 단계씩 정직하게 보여 준 쪽입니다.

POST 에의 200 응답을 그대로 표시하면, 새로 고침 = POST 의 재실행이 됩니다(POST 는 멱등이 아니므로 이중 주문이 될 수 있음 — 제 2 장). POST/Redirect/GET 은 처리 후에 리다이렉트를 돌려주고 완료 페이지를 GET 으로 보여 주는 틀로, 새로 고침되어도 안전한 GET 이 반복될 뿐이 됩니다. no-store 는 재전송 문제를 해결하지 않고, 주문을 GET 으로 하는 것은 「안전한 메서드로 상태를 바꾸는」 반대 방향의 악수입니다.

(disk cache) 는 「서버에 리퀘스트가 나가지 않았다」의 결정적인 표식입니다(제 5〜6 장). 서버를 아무리 고쳐도, fresh 인 동안 브라우저는 보러 오지 않습니다. 수중의 확인은 Disable cache 로 충분하지만, 이용자 전원의 캐시는 지울 수 없으므로, 영구 대책은 style.v2.css 처럼 URL 자체를 바꿔 「다른 리소스」로 가져오게 하는 설계가 정석입니다. 업로드 실패라면 Size 열에 통상의 전송량이 나와 있을 것입니다.

403 은 「누구인지는 알았지만, 권한이 없다」(제 3 장). 삭제라면 404, 서버 다운이라면 5xx 나 접속 오류가 될 것이고, 403 이 돌아오고 있는 시점에서 서버는 살아 있고 리퀘스트도 도착해 있습니다. 「어제까지 볼 수 있었다」와 합치면, 자료의 공개 범위나 회원 종별·권한 설정이 바뀌었을 가능성이 높다고 조사할 곳이 좁혀집니다. 상태 코드 하나로, 의심할 곳이 이만큼 달라집니다.

실체는 UTF-8, 라벨은 ISO-8859-1 — 제 4 장에서 읽은 「라벨과 내용물의 불일치」 그 자체입니다. 브라우저는 선언을 믿고 잘못된 문자 인코딩으로 바이트열을 해석하기 때문에 깨집니다. 고쳐야 할 것은 서버의 charset 선언이며, 이용자에게 매번 설정 변경을 강요하는 안이나 본문을 영어·이미지로 하는 안은 원인을 방치한 회피책조차 되지 못합니다. 헤더를 고치면 전원의 표시가 한 번에 고쳐집니다.

502 는 「중계역은 살아 있지만, 뒤로부터 정상적인 응답을 얻지 못했다」(제 3 장). 502 라는 HTTP 리스폰스가 돌아오고 있다는 것 자체가, 프록시까지는 도달할 수 있다는 증거입니다. 그래서 첫수는 애플리케이션 서버의 사활과 로그. 브라우저 설정이나 DNS 계약이 원인이라면, 애초에 502 라는 형태의 답장은 도착하지 않습니다. 3 자리 숫자가 2 단 구성의 어느 쪽인지까지 가르쳐 주고 있습니다.

강좌의 마무리는 제 2 장의 실무 감각입니다. 타임아웃은 「처리되었는데 답장만 사라졌을」 가능성을 포함합니다. PUT 은 같은 내용으로의 치환이므로, 설령 2 번 처리되어도 최종 상태는 같음 — 안심하고 재전송할 수 있습니다. POST 는 2 번 처리되면 발주가 2 건. 확인이나 중복 방지의 구조 없는 재전송은 사고입니다. 「갱신의 재시도는 멱등성을 확인하고 나서」— 이 한 문장을 가져가 주세요.