PHP cURL 프록시 헤더: CONNECT와 목적지 응답의 차이
PHP cURL 전송이 프록시를 사용할 때 CONNECT, 인증, 리디렉션, 최종 응답 헤더를 구분해 유지하세요.
헤더 줄은 응답 본문과 분리해 수집합니다. 프록시를 거치는 전송은 CONNECT, 인증, 리디렉션, 목적지 응답 헤더를 한 번의 작업으로 전달할 수 있습니다.
$headerLines = [];
curl_setopt($handle, CURLOPT_HEADERFUNCTION,
function ($handle, $line) use (&$headerLines) {
$headerLines[] = $line;
return strlen($line);
}
);
이 콜백은 원시 줄 순서를 유지하고 수락한 바이트 수를 반환합니다. 완전한 줄을 받지만, 아직 응답별로 묶거나 최종 웹사이트 헤더를 선택하지는 않습니다.
순서를 블록으로 해석하기
HTTP 상태 줄이 응답 블록을 시작하고 빈 줄이 그 헤더를 끝냅니다. 최종 목적지 응답을 고르기 전에 이 경계를 보존합니다. 중간 인증 시도와 리디렉션도 각각 블록을 추가할 수 있습니다.
트레일러는 나중에 콜백을 통해 도착할 수 있습니다. 이후의 모든 필드를 첫 응답에 붙이지 말고, 초기 헤더와 구분할 수 있을 만큼 파서 상태를 유지합니다.
터널 증거를 유지하거나 억제하기
HTTPS 터널의 CONNECT 상태는 CURLINFO_HTTP_CONNECTCODE을 따로 읽습니다. 수락된 터널은 웹사이트 응답의 성공을 증명하지 않습니다.
수집기가 CONNECT 헤더를 필요로 하지 않으면 CURLOPT_SUPPRESS_CONNECT_HEADERS이 구성된 헤더 출력과 콜백 경로로의 전달을 제어합니다. 연결된 libcurl과 PHP 빌드에서 지원 여부를 확인하세요. 억제하면 수집은 단순해지지만 진단에 도움이 되는 헤더 수준 터널 증거가 사라집니다.
고정 오프셋으로 또는 HTML 태그를 검색해 본문을 복원하지 마세요. 헤더 크기는 다양하고 중간 응답도 다르며 본문은 바이너리이거나 비어 있을 수 있습니다. 오래된 릴리스별 버그 보고서는 추측한 오프셋을 정당화하지 않습니다.
본문 처리는 분리하고, 수집이나 파싱이 실패하면 관찰된 응답 단계와 함께 전송 오류를 보존합니다. 그래야 중단된 콜백, 잘못된 애플리케이션 데이터, 거부된 프록시 교환을 구분할 수 있습니다.