요청 설정

설정 탭은 요청이 오가는 방식을 정합니다. 어떤 HTTP 버전을 쓸지, 리디렉션을 따를지, 쿠키를 유지할지, 인증서를 확인할지, 얼마나 오래 걸려도 되는지입니다. 프록시와 인증서는 이 페이지 아래쪽에서 작업 공간 전체 또는 앱 전체에 대해 설정합니다.

설정 탭Copy Anchor Link

변경한 설정만 요청 파일에 저장됩니다. 기본값과 다른 설정이 있으면 탭에 점이 표시되고, 원본 모드가 켜져 있는 동안은 설정(원본)이라고 표시됩니다. 기본값으로 재설정은 모든 설정을 되돌립니다.

요청 파일에서는 설정이 다음과 같이 보입니다.

[settings]
http-version = "http2"
follow-redirects = false
timeout = 10.0

HTTP 버전Copy Anchor Link

HTTP/3에는 제한이 있습니다.

• macOS 27 이상이 필요합니다. 이전 Mac에서는 탭에 그렇게 표시되고 HTTP/3으로 설정한 요청은 보낼 수 없으며, 자동은 HTTP/2와 HTTP/1.1을 유지합니다.
• https:// 주소만 가능합니다.
• 프록시(시스템 프록시 포함)를 쓸 수 없고, 사용자 지정 CA 파일과 클라이언트 인증서도 쓸 수 없습니다. HTTP/3으로 설정한 요청에 이 중 하나가 필요하면 이유와 함께 거부됩니다. 자동에서는 그런 요청이 TCP를 유지합니다.
• 원본 모드는 HTTP/3과 함께 쓸 수 없습니다.

자동에서 응답이 HTTP/3을 제공하면 세부 정보 카드에 HTTP/3 제공됨이 표시됩니다. 다음 요청의 QUIC 연결이 실패하면 Echolot은 대신 TCP로 보내고, 제공된 내용을 잊으며, 세부 정보 카드에 이유가 표시됩니다. 두 번 보내지는 일은 없습니다.

두 가지 경우에는 버전이 저절로 바뀝니다.

• NTLM은 HTTP/1.1이 필요합니다. 자동에서는 NTLM 요청이 HTTP/1.1로 가고, HTTP/2나 HTTP/3에서는 거부됩니다.
• 서버가 HTTP/2 요청을 HTTP_1_1_REQUIRED로 재설정하면 Echolot은 그 뒤로 그 서버와 HTTP/1.1로 통신합니다. 반복해도 안전한 요청은 바로 HTTP/1.1로 다시 보내고, 다른 요청은 그렇다는 오류와 함께 중단되며 다시 보내면 HTTP/1.1로 나갑니다.

응답의 세부 정보 카드에는 사용된 버전이 TLS 버전 옆에 표시됩니다.

리디렉션Copy Anchor Link

리디렉션 따르기를 켜면 Echolot은 http://와 https:// 주소로 가는 301, 302, 303, 307, 308 응답을 따라갑니다.

• 303은 본문 없는 GET이 됩니다(HEAD는 HEAD로 유지).
• 301과 302는 브라우저처럼 POST를 GET으로 바꿉니다.
• 307과 308은 메서드와 본문을 유지합니다.

모든 홉이 기록됩니다. 세부 정보 카드에 리디렉션 3회(또는 해당 횟수)가 표시되며, 클릭하면 각 홉의 상태, 메서드, 주소, 시간과 최종 주소를 볼 수 있습니다. Alpenglow의 Echo › Follow redirects로 시험해 보십시오.

다른 출처로의 리디렉션에서는 자격 증명이 제거됩니다. Authorization과 Cookie 헤더, API 키 헤더, 비밀 값이 들어 있는 헤더, 서명(Digest, AWS, Hawk, EdgeGrid, NTLM), 클라이언트 인증서입니다. 자격 증명은 출처에 머뭅니다를 참고하십시오.

리디렉션 따르기가 꺼져 있으면 3xx 응답이 곧 응답입니다.

쿠키Copy Anchor Link

윈도우마다 쿠키 저장소가 있습니다. 쿠키 보내기 및 저장을 켜면 요청은 저장소에서 자신의 주소와 일치하는 쿠키를 보내고, 응답이 설정하는 쿠키는 저장소에 들어갑니다. 어떤 쿠키도 보내거나 보관하지 않아야 하는 요청에서는 끕니다.

응답의 쿠키 탭에는 요청과 함께 보냄, 응답이 설정함, 이 윈도우에 저장됨이 표시됩니다. 쿠키 하나는 해당 버튼으로, 전체는 모두 지우기로 제거합니다. 응답을 참고하십시오.

저장소는 브라우저의 규칙을 따릅니다. 응답은 .com이나 .co.uk 같은 공개 접미사 전체에 대해서는 쿠키를 설정할 수 없습니다. Alpenglow의 Echo › Set a cookie를 시험한 다음 demo.echolot.dev로 가는 다른 요청을 보내 보십시오.

응답 압축 해제Copy Anchor Link

응답 압축 해제를 켜면 Echolot은 (해당 헤더를 직접 설정하지 않았다면) Accept-Encoding: gzip, deflate, br, zstd를 보내고 gzip, deflate, Brotli, Zstandard 응답을 디코딩합니다. 본문 탭에는 디코딩된 본문이 표시되고, 도착한 그대로의 바이트는 통신 탭에 남으며, 본문의 저장 메뉴에서 인코딩된 본문 저장…을 쓸 수 있습니다. 세부 정보 카드에는 예를 들어 br, 12 KB → 48 KB처럼 표시됩니다.

서버가 압축한 그대로 응답을 보거나 Accept-Encoding 헤더를 보내지 않으려면 끕니다.

TLS 인증서 확인Copy Anchor Link

서버의 인증서를 Mac이 신뢰하지 않는데 그 CA를 추가할 수도 없는 서버를 시험하는 경우가 아니면 켜 두십시오. 끄면 세부 정보 카드에 주황색의 열린 자물쇠가 표시되고 팝오버에 인증서 확인 꺼짐이라고 나옵니다.

사설 CA에는 해당 호스트에 대해 그 CA를 신뢰하는 편이 더 낫습니다. 인증서를 참고하십시오.

시간 초과Copy Anchor Link

시간 초과는 연결부터 마지막 바이트까지 교환 전체에 허용되는 시간입니다. 시간이 다 되면 요청이 요청 시간이 초과되었습니다와 함께 중단되고 연결이 닫힙니다.

원본 모드Copy Anchor Link

원본 모드는 잘못된 형식의 요청까지 포함해, 서버가 어떻게 처리하는지 시험하기 위해 요청을 작성한 바이트 그대로 보내는 모드입니다. Echolot은 모든 요청에 추가하는 헤더(Host, User-Agent, Accept, Accept-Encoding, Cookie, Content-Length와 프레이밍)를 넣지 않으며 요청의 형식이 올바른지도 검사하지 않습니다. 헤더 탭의 자동 생성 아래에 원본 모드: Echolot은 헤더를 추가하지 않으며 위에 있는 헤더만 보냅니다.라고 표시됩니다.

직접 쓴 헤더만 보내는 요청을 만들려면 인증도 인증 없음으로 설정하고, 본문에 필요하면 직접 Content-Type을 쓰십시오. 원본 모드는 HTTP/1.1로 쓰기 때문에 HTTP/3과 함께 쓸 수 없습니다.

재시도Copy Anchor Link

Echolot은 연결을 열어 둔 채 재사용하여 DNS, 연결, TLS 시간을 아낍니다. 재사용하면 세부 정보 카드에 재사용된 연결이 표시됩니다. 때로는 서버가 열어 둔 연결을 요청이 나가는 바로 그 순간에 닫아 버립니다. 이때는 다음과 같이 합니다.

• 반복해도 안전한 요청은 새 연결로 다시 보냅니다. GET, HEAD, OPTIONS, TRACE, PUT, DELETE, 또는 Idempotency-Key 헤더가 있는 요청입니다. 세부 정보 카드에 다시 보냈다고 표시됩니다.
• 그 밖의 요청(Idempotency-Key가 없는 POST 등)은 서버가 이미 처리했을 수 있으므로 다시 보내지 않습니다. 응답이 도착하기 전에 연결이 닫혔습니다. 서버가 요청을 이미 처리했을 수 있습니다라는 메시지와 함께 중단됩니다.

Echolot은 그 밖의 경우에는 재시도하지 않습니다.

프록시Copy Anchor Link

요청은 기본적으로 설정 › 네트워크에서 선택한 프록시를 거칩니다.

작업 공간은 자체 프록시를 설정할 수 있으며, 이 설정은 팀원과 명령줄 도구에도 함께 전달됩니다.

1. 사이드바 하단의 작업 공간 전환기에서 작업 공간 설정…을 엽니다.
2. 프록시 탭을 선택하고 앱의 프록시 설정 사용을 끕니다.
3. 시스템 설정, 환경(HTTPS_PROXY…)(HTTPS_PROXY, HTTP_PROXY, NO_PROXY를 읽음), 없음, 수동 중에서 선택합니다.
4. 수동에서는 프록시({{proxy}}처럼 변수를 쓸 수 있음), 사용자 이름, 비밀번호, 직접 연결을 입력합니다. 비밀번호는 {{proxy_password}}처럼 비밀 변수로 쓰십시오. 작업 공간 파일에는 비밀 값이 저장되지 않습니다. 비밀번호를 그대로 입력하면 키체인으로 이동이 제안됩니다.

HTTP/3은 프록시를 거치지 않습니다. 작업 공간을 참고하십시오.

인증서Copy Anchor Link

사설 인증 기관을 쓰거나 클라이언트 인증서(상호 TLS)를 요구하는 호스트에는 작업 공간에 규칙을 추가합니다.

1. 작업 공간 설정…을 열고 인증서 탭을 선택합니다.
2. 호스트 추가를 클릭하고 api.example.com처럼 호스트를 입력하거나, 모든 하위 도메인에는 *.internal을 입력합니다.
3. 신뢰할 CA 옆에서 선택…을 클릭하고 PEM 파일을 하나 이상 고릅니다. 시스템의 인증서에 더해 신뢰됩니다.
4. 클라이언트 인증서는 클라이언트 인증서 옆에서 파일을 선택합니다. PEM 파일 또는 .p12(.pfx)입니다. 키가 없는 PEM 인증서 파일에는 개인 키 파일도 선택합니다.
5. 키 또는 .p12에 암호가 있으면 암호에 {{p12_passphrase}}처럼 비밀 변수로 씁니다.

호스트와 일치하는 첫 번째 규칙이 적용됩니다. 작업 공간 안의 파일은 작업 공간 기준 상대 경로로 저장되므로 규칙이 작업 공간을 가진 모든 사람에게 동작합니다. 각 규칙의 인증서는 그 호스트에만 사용되며, 다른 호스트로의 리디렉션이 첫 호스트의 클라이언트 인증서를 제시하는 일은 없습니다.

앱 전체 설정Copy Anchor Link

프록시는 앱 전체의 기본값이 있는 유일한 요청 설정입니다(설정 › 네트워크). 그 밖의 설정은 요청마다 위 표의 기본값에서 시작하며 요청 파일에 변경한 내용이 보관됩니다. 여러 요청의 설정을 한꺼번에 바꾸려면 사이드바에서 요청들을 선택하고 요청 N개 편집…으로 헤더, 매개변수, 인증을 바꾸거나 파일을 직접 편집하십시오.