이 섹션에는 클라이언트가 URL을 확인하는 방법에 관한 자세한 사양이 포함되어 있습니다.
URL 표준화
URL이 확인되기 전에 클라이언트는 해당 URL에 대해 일부 표준화를 실행해야 합니다.
먼저 클라이언트가 파싱한 URL이 RFC 2396에 따라 유효하다고 가정합니다. URL에서 국제화된 도메인 이름 (IDN)을 사용하는 경우 클라이언트는 URL을 ASCII 퓨니코드 표현으로 변환해야 합니다. URL에는 경로 구성요소가 포함되어야 합니다. 즉, 도메인 뒤에 슬래시 (http://google.com
대신 http://google.com/
)가 하나 이상 있어야 합니다.
먼저 URL에서 탭 (0x09), CR (0x0d), LF (0x0a) 문자를 삭제합니다. 이러한 문자 (예: %0a
)의 이스케이프 시퀀스는 삭제하지 마세요.
둘째, URL이 프래그먼트로 끝나면 프래그먼트를 제거합니다. 예를 들어 http://google.com/#frag
를 http://google.com/
로 줄입니다.
세 번째로, URL에서 더 이상 퍼센트 이스케이프 문자가 남지 않을 때까지 퍼센트 이스케이프 문자를 반복적으로 삭제합니다. 이렇게 하면 URL이 잘못될 수 있습니다.
호스트 이름을 표준화하려면 다음 안내를 따르세요.
URL에서 호스트 이름을 추출한 후 다음을 수행합니다.
- 모든 선행 및 후행 점은 삭제합니다.
- 연속된 점을 단일 점으로 바꿉니다.
- 호스트 이름을 IPv4 주소로 파싱할 수 있는 경우 4개의 점으로 구분된 십진수 값으로 정규화합니다. 클라이언트는 8진수, 16진수, 4개 미만의 구성 요소를 포함한 모든 법적 IP 주소 인코딩을 처리해야 합니다.
- 호스트 이름을 대괄호로 묶인 IPv6 주소로 파싱할 수 있는 경우 구성요소에서 불필요한 선행 0을 삭제하고 이중 콜론 구문을 사용하여 0 구성요소를 접어서 정규화합니다. 예를 들어
[2001:0db8:0000::1]
은[2001:db8::1]
로 변환되어야 합니다. 호스트 이름이 다음 두 가지 특수 IPv6 주소 유형 중 하나인 경우 IPv4로 변환합니다.[::ffff:1.2.3.4]
와 같이1.2.3.4
로 변환해야 하는 IPv4 매핑 IPv6 주소[64:ff9b::1.2.3.4]
와 같이 잘 알려진 접두사 64:ff9b::/96을 사용하는 NAT64 주소로,1.2.3.4
로 변환해야 합니다.
- 전체 문자열을 소문자로 표기합니다.
경로를 표준화하려면 다음 안내를 따르세요.
/./
를/
로 바꾸고 이전 경로 구성요소와 함께/../
를 삭제하여 경로의/../
및/./
시퀀스를 확인합니다.- 연속된 슬래시 실행을 단일 슬래시 문자로 바꿉니다.
이러한 경로 표준화를 쿼리 매개변수에 적용하지 마세요.
URL에서 <= ASCII 32, >= 127, #
또는 %
인 모든 문자를 퍼센트 문자로 이스케이프 처리합니다. 이스케이프는 대문자 16진수를 사용해야합니다.
호스트-서픽스 경로-프리픽스 표현식
URL이 표준화되면 다음 단계는 서픽스/프리픽스 표현식을 만드는 것입니다. 각 서픽스/프리픽스 표현식은 호스트 서픽스 (또는 전체 호스트)와 경로 프리픽스 (또는 전체 경로)로 구성됩니다.
클라이언트는 최대 30개의 서로 다른 호스트 서픽스와 경로 프리픽스 조합을 구성합니다. 이러한 조합은 URL의 호스트 및 경로 구성요소만 사용합니다. 스키마, 사용자 이름, 비밀번호, 포트는 삭제됩니다. URL에 쿼리 매개변수가 포함된 경우에는 하나 이상의 조합에 전체 경로 및 쿼리 매개변수가 포함됩니다.
호스트의 경우 클라이언트는 최대 5개의 다른 문자열을 시도합니다. 각 필터는 다음과 같습니다.
- 호스트 이름이 IPv4 또는 IPv6 리터럴이 아닌 경우 eTLD+1 도메인으로 시작하고 앞의 구성요소를 연속적으로 추가하여 최대 4개의 호스트 이름을 만듭니다. eTLD+1은 공개 접미사 목록을 기반으로 결정해야 합니다. 예를 들어
a.b.example.com
는example.com
의 eTLD+1 도메인과 호스트 구성요소b.example.com
가 하나 추가된 호스트를 생성합니다. - URL의 정확한 호스트 이름입니다. 위의 예를 따르면
a.b.example.com
이 선택됩니다.
경로의 경우 클라이언트는 최대 6개의 다른 문자열을 시도합니다. 문자열은 다음과 같습니다.
- 쿼리 매개변수를 포함한 URL의 정확한 경로입니다.
- 쿼리 매개변수가 없는 URL의 정확한 경로입니다.
- 루트 (/)에서 시작하여 후행 슬래시를 포함하여 경로 구성 요소를 연속적으로 추가하여 형성되는 4개의 경로입니다.
다음 예시는 확인 동작을 보여줍니다.
URL http://a.b.com/1/2.html?param=1
에 대해 클라이언트는 다음과 같은 가능한 문자열을 시도합니다.
a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/
URL http://a.b.c.d.e.f.com/1.html
에 대해 클라이언트는 다음과 같은 가능한 문자열을 시도합니다.
a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/
(참고: 마지막 5개 호스트 이름 구성요소와 전체 호스트 이름만 가져오므로 b.c.d.e.f.com
는 건너뜁니다.)
URL http://1.2.3.4/1/
에 대해 클라이언트는 다음과 같은 가능한 문자열을 시도합니다.
1.2.3.4/1/
1.2.3.4/
URL http://example.co.uk/1
에 대해 클라이언트는 다음과 같은 가능한 문자열을 시도합니다.
example.co.uk/1
example.co.uk/
해싱
Google 세이프 브라우징은 SHA256을 해시 함수로만 사용합니다. 이 해시 함수는 위의 표현식에 적용해야 합니다.
전체 32바이트 해시는 상황에 따라 4바이트, 8바이트 또는 16바이트로 자릅니다.
hashes.search 메서드를 사용할 때 현재 요청의 해시를 정확히 4바이트로 자르도록 해야 합니다. 이 요청에 추가 바이트가 전송되면 사용자 개인 정보 보호가 침해됩니다.
hashList.get 메서드 또는 hashLists.batchGet 메서드를 사용하여 로컬 데이터베이스의 목록을 다운로드할 때 서버에서 전송한 해시의 길이는 해시 길이를 나타내는 접미사가 포함된 목록의 이름 지정 규칙 내에 인코딩됩니다. 자세한 내용은 사용 가능한 목록 섹션을 참고하세요.