http.client의 다음 응답 조회가 ResponseNotReady로 막힌다
http.client에서 이전 본문을 남기면 다음 request()가 성공해도 getresponse()는 ResponseNotReady로 막힐 수 있다. 고정 길이 응답의 미독·부분·전체 읽기를 비교하고, 작은 본문 소비와 연결 폐기를 다음 요청 전에 결정하는 방법을 설명한다.
빌드노트
HTTP·네트워크 카테고리의 글입니다.
총 48개의 글
http.client에서 이전 본문을 남기면 다음 request()가 성공해도 getresponse()는 ResponseNotReady로 막힐 수 있다. 고정 길이 응답의 미독·부분·전체 읽기를 비교하고, 작은 본문 소비와 연결 폐기를 다음 요청 전에 결정하는 방법을 설명한다.
curl의 POST 재시도가 최종 200으로 끝나도 서버 효과는 두 번 발생할 수 있다. 카운터 증가 뒤 503을 반환하는 loopback 서버에서 재시도 0회·1회와 --fail을 비교하고, 최종 상태·수신 횟수·중복 방지 계약을 따로 확인한다.
프록시가 Set-Cookie 두 필드를 쉼표 문자열로 합치면 쿠키가 빠질 수 있다. 원시 응답, Node getSetCookie, 새 Chrome 프로필의 저장·전송 결과를 비교하고 Expires의 쉼표를 자르지 않고 필드별로 전달하는 방법을 설명한다.
curl의 로컬 요청도 proxy 환경에 따라 프록시로 갈 수 있다. 새 loopback 수신기로 기본 요청과 --noproxy의 접속 포트·응답을 비교하고, localhost 예외와 숫자 주소의 차이 및 HTTP/HTTPS 환경 변수 대소문자 규칙을 확인한다.
curl -L 뒤 다른 호스트에서 401이 난다면 첫 응답의 Location과 목적지의 Authorization 수신 여부를 함께 본다. curl 8.21.0의 loopback 실험에서 같은 origin의 헤더 유지, 호스트·포트 변경 시 누락, 검증한 목적지 직접 호출의 차이를 확인한다.
curl --data @file은 파일의 CR·LF·NUL을 제거한다. 9바이트 합성 파일을 loopback으로 보내 수신 길이·hex·SHA-256을 비교하고, 직접 문자열 인자와 파일 읽기를 구별해 원본 바이트 보존에는 --data-binary를 고르는 이유를 설명한다.
주소의 # 뒤 값은 브라우저 fragment로 남고 페이지를 가져오는 요청 대상에서는 빠진다. 새 브라우저와 loopback 서버에서 location 값과 요청 줄을 대조하고, 서버에 필요한 값을 query나 JSON 본문으로 명시하는 기준을 설명한다.
ETag가 일치한 GET의 304에는 JSON 본문이 없다. 실제 200·304·변경 후 200의 14→0→14바이트와 파싱 오류를 비교하고, 짧은 클라이언트 분기로 저장 본문 재사용과 조건부 헤더 없는 재요청을 구별한다.
같은 ETag를 읽은 두 클라이언트가 차례로 저장할 때 200/200과 200/412의 최종 문서를 비교했다. 서버의 강한 ETag 검사와 원자적 갱신, 412 뒤 초안을 보존하고 다시 읽는 흐름을 설명한다.
curl의 connect-timeout은 연결 이후의 응답 대기를 제한하지 않는다. 헤더·본문을 각각 2초 늦춘 로컬 서버에서 max-time 유무의 종료 코드와 시간을 비교하고, 재시도마다 다시 시작하는 제한과 retry-max-time을 넘길 수 있는 진행 중 전송을 구별한다.
Location: next는 응답을 받은 요청 URL을 기준으로 해석한다. 끝 슬래시 유무에 따른 실제 후속 GET 경로와 쿼리 교체 결과를 비교하고, 상대 경로·루트 상대 경로·절대 URL을 고르는 기준을 설명한다.
한글 다운로드 이름 대신 ASCII fallback이 제안될 때 filename과 filename*을 구별한다. 실제 Chrome 다운로드 여섯 조건에서 제안 이름과 동일한 27바이트 본문을 대조하고, 공백의 %20 표현과 중복 인코딩을 확인하는 방법을 설명한다.