Guzzle의 cURL 핸들러: 프록시 CONNECT 헤더 캡처

HTTP 프록시를 통한 HTTPS 요청은 CONNECT를 허용하는 하나의 응답을 받고, 그다음 터널 내부의 웹사이트에서 오는 응답을 받을 수 있습니다. 초기 경로 설정은 Guzzle의 요청별 프록시 옵션을 참고하세요. 첫 응답의 헤더가 최종 응답 객체에 반드시 존재하는 것은 아닙니다.

직접 고른 HTTP 엔드포인트로 재현하려면 HTTP 프록시 목록에서 후보를 골라 HTTPS 터널을 허용하는지 확인하세요. Guzzle 7.10의 cURL 핸들러 경로에서는 각 헤더 콜백을 별도 블록으로 보존합니다:

$blocks = [];
$client = new \GuzzleHttp\Client([
    'handler' => \GuzzleHttp\HandlerStack::create(
        new \GuzzleHttp\Handler\CurlHandler()
    ),
]);

$response = $client->get('https://www.example.com/', [
    'proxy' => 'http://proxy.example:8080',
    'curl' => [CURLOPT_SUPPRESS_CONNECT_HEADERS => false],
    'on_headers' => function (
        \Psr\Http\Message\ResponseInterface $part
    ) use (&$blocks) {
        $blocks[] = [
            'status' => $part->getStatusCode(),
            'reason' => $part->getReasonPhrase(),
            'headers' => $part->getHeaders(),
        ];
    },
]);

cURL 확장은 libcurl 7.54.0에서 도입된 CURLOPT_SUPPRESS_CONNECT_HEADERS를 제공해야 합니다. 이를 false로 설정하면 CONNECT 헤더가 cURL의 헤더 콜백에 도달합니다. Guzzle 7.10 핸들러는 완료된 헤더 블록마다 응답을 만들고 그 경계에서 on_headers를 호출합니다.

블록을 순서대로 유지하세요. 인증 챌린지, 리디렉션, 정보성 응답은 추가 블록을 만들 수 있습니다. 모든 값을 하나의 배열로 평탄화하지 말고 상태 코드가 200이라는 이유만으로 응답을 분류하지 마세요.

반환된 응답은 완료된 요청의 응답을 나타내며, blocks는 콜백이 수집한 관찰을 보존합니다. 터널이나 TLS 설정이 실패하면 호출하는 애플리케이션에서 발생한 전송 예외를 처리하세요. 최종 웹사이트 응답이 없을 수도 있습니다.

이 동작은 명시된 cURL 핸들러에 연결됩니다. 사용자 정의 핸들러나 스트림 핸들러가 동일한 프록시 핸드셰이크 콜백을 제공할 의무는 없습니다. 캡처한 프록시 헤더를 진단 데이터로 취급하고 계정과 관련된 값을 불필요하게 보관하지 마세요.