DNS 전환 전 HTTPS 확인은 curl --resolve로 한다
DNS 전환 전 새 IP를 HTTPS로 검사할 때는 URL의 도메인을 유지하고 curl --resolve로 연결 주소만 바꾼다. 전용 CA와 loopback TLS 서버에서 Host·SNI·인증서 이름 검증을 비교하고 Windows Schannel의 미완료 조건도 구분한다.
빌드노트
HTTP·네트워크 카테고리의 글입니다.
총 48개의 글
DNS 전환 전 새 IP를 HTTPS로 검사할 때는 URL의 도메인을 유지하고 curl --resolve로 연결 주소만 바꾼다. 전용 CA와 loopback TLS 서버에서 Host·SNI·인증서 이름 검증을 비교하고 Windows Schannel의 미완료 조건도 구분한다.
curl은 기본적으로 URL의 점 경로를 전송 전에 정리한다. 세 경로를 기본 조건과 --path-as-is로 보내 실제 수신 요청 줄을 비교하고, curl의 처리와 서버의 후속 해석을 구분한다.
Range를 보냈어도 서버는 전체 내용을 200으로 반환할 수 있다. 고정 16바이트의 206·200·416 응답을 비교하고, Content-Range와 실제 바이트·같은 버전을 확인해 조각 결합과 전체 재시작을 결정한다.
Retry-After를 정수로만 읽고 실패를 0으로 바꾸면 정상적인 날짜 응답도 즉시 재요청으로 이어진다. 429·503의 실제 loopback 헤더와 고정 시계 계산을 대조하고, 유효한 0·누락·잘못된 값 및 대기 예산 초과를 구분한다.
HTTP 500 응답을 받아도 기본 curl의 종료 코드는 0일 수 있다. 고정 200·404·500에서 --fail과 --fail-with-body의 종료 코드·본문 파일을 비교하고, PowerShell에서 실패를 반환하는 처리와 정확히 200을 검사할 조건을 설명한다.
no-cache 응답의 ETag를 브라우저가 다시 보내는 것은 재검증이다. 새 Chromium 프로필에서 일반 fetch를 반복해 no-cache의 200·304·304와 no-store의 200·200·200을 비교하고, 저장 허용 여부에 따라 응답 정책을 고르는 기준을 설명한다.
Accept-Language를 바꿔도 같은 URL의 신선한 캐시가 이전 언어 응답을 재사용할 수 있다. 실제 Chromium에서 본문과 서버 요청 횟수를 비교하고, Vary로 언어를 구분하는 수정과 no-cache·no-store의 역할을 설명한다.
리다이렉트 뒤 POST 본문이 사라졌다면 첫 응답과 목적지 요청을 함께 본다. 실제 303 뒤 GET·0바이트, 307 뒤 POST·15바이트 기록을 바탕으로 Network 확인 순서와 저장 후 결과 조회(PRG)·같은 POST의 임시 주소 이동을 구분한다.
조건부 GET에 If-None-Match와 If-Modified-Since를 함께 보내면 날짜 조건은 판단에서 빠진다. Werkzeug 3.1.9의 실제 WSGI 응답을 태그·날짜 단독 요청과 비교하고, 날짜만 보고 304를 반환하는 분기를 고치는 위치를 설명한다.
브라우저의 redirect: manual 응답에서 상태 0과 빈 Location이 보이는 이유를 opaqueredirect로 설명한다. 실제 302 서버 로그와 브라우저 manual·follow·no-cors, Node fetch를 비교하고 자동 추적과 JSON 목적지 계약을 고르는 기준을 제시한다.
명령에 없는 사용자 정의 헤더가 curl 요청에 붙을 때 기본 설정 파일을 판별한다. 같은 실행 파일과 loopback 요청에서 기본 실행, 첫 -q, 뒤쪽 -q를 비교하고 명시적 --config가 계속 적용되는 차이를 확인한다.
URL을 인자 하나로 전달해도 curl 자체 URL globbing은 남는다. 실제 curl.exe로 대괄호·중괄호 쿼리의 오류, 요청 수와 수신 대상을 비교하고 -g/--globoff를 선택할 조건을 설명한다.