Node.js CONNECT 핸들러는 head 버퍼를 보존해야 합니다

Node HTTP 서버는 일반 프록시 요청을 요청 콜백으로 처리합니다. CONNECT는 다른 경로를 갑니다. 서버는 요청, 클라이언트 소켓, head 버퍼와 함께 connect 이벤트를 발생시킵니다.

그 이벤트는 HTTP 파싱과 터널 사이의 인계 지점입니다. 터널링된 트래픽에 계속 사용할 일반 ServerResponse 객체는 없습니다.

바이트를 중계하기 전에 HTTP 결정을 끝내세요

요청된 호스트와 포트를 검증하고, 프록시의 접근 및 인증 정책을 적용하며, 업스트림 연결을 설정하세요. CONNECT는 service.example:443 같은 권한을 식별합니다. 모든 콜론에서 무작정 나누지 말고 IPv6 권한을 염두에 두고 그 형식을 파싱하세요.

터널이 수락되면 성공 HTTP 응답과 그 뒤의 종료 빈 줄을 보내세요. 그런 다음 클라이언트 소켓의 이후 바이트로 진행하기 전에 head 바이트를 업스트림으로 전달하세요. 새 데이터 리스너를 붙여도 이미 핸들러에 별도로 전달된 버퍼는 되찾을 수 없습니다.

Node의 공식 터널링 예제는 두 스트림 방향을 연결하기 전에 serverSocket.write(head)로 그 인계를 수행합니다. 작은 예제는 전환을 보여 줍니다. 배포된 프록시에는 제한된 연결 시도, 접근 제어, 수명 주기 관리도 필요합니다.

성공 후에는 바이트가 서비스 프로토콜에 속합니다

성공한 CONNECT 응답은 연결을 바이트 스트림으로 바꿉니다. 대상이 HTTPS 사이트라면 TLS 교환이 그 스트림 안에서 이루어집니다. 단순히 터널링한다고 해서 프록시가 대체 웹사이트 인증서를 발급해야 하는 것은 아닙니다.

CONNECT를 수락하기 전에는 HTTP 오류로 거부 이유를 설명할 수 있습니다. 수락한 뒤 스트림에 HTTP 500을 쓰면 터널링된 프로토콜에 바이트를 주입하게 됩니다. 대신 이후 실패 시 적절한 연결을 종료하거나 파괴하세요.

양방향을 백프레셔를 고려한 스트림 처리로 연결하고, end, error, close 이벤트가 상대를 어떻게 종료할지 결정하세요. 초기 head 버퍼를 같은 소유 모델의 일부로 보존하세요. 그것은 애플리케이션 데이터이며 버릴 여분의 HTTP 헤더가 아닙니다.