HTTP (S) URL의 호스트 이름 부분은 대소 문자를 구분하지 않습니까?


16

서비스 측 구성을 변경하지 않고 http (s) : //CompanyName.com/xyz를 URL (예 : 브랜딩 목적)로 사용하는 것이 안전합니까?

DNS는 대소 문자를 구분하지 않지만 부작용이 여전히있을 수 있음을 알고 있습니다. 예를 들어 CompanyName.com ~ companyname.com과 일치하지 않는 체인의 다양한 부분을 생각하고 있습니다.

  • 일부 웹 백엔드가 일치하지 않을 수 있습니다
  • 일부로드 밸런서 / 프록시 / 캐시 / 애플리케이션 계층 방화벽이 일치하지 않을 수 있음
  • 일부 고객은 동일한 출처 정책을 잘못 적용 할 수 있습니다
  • 인증서 검사에서 일부 클라이언트가 일치하지 않을 수 있습니다
  • DNS는 일반적으로 대소 문자를 구분하지 않지만 IDN은 그림을 변경할 수 있습니까?

URL의 호스트 이름 부분에서 대문자 또는 기타 문제가 발생한 사람이 있습니까?


@Michael Hampton은 HTTP 표준에 따르면 호스트 이름은 대소 문자를 구분하지 않지만 일부 소프트웨어는 이와 관련하여 호환되지 않는다고 지적했다.

널리 사용되는 비준수 소프트웨어, 특히 클라이언트의 상태를 파악하려고합니다. 최근의 모든 주요 브라우저는 괜찮다고 생각하지만 모바일 앱은 어떻습니까? (이 질문을 별도의 SF 질문으로 나누는 것이 좋을까요?) [/ edit]


예를 들어 Firefox는 소문자 Host헤더 를 전송합니다 (적어도 개발자 도구가 표시하는 것입니다). 호스트 이름. curl반면에 헤더를 보낼 때 대소 문자를 유지합니다.

답변:


23

예. 호스트 이름은 일반적으로 DNS에서 대소 문자를 구분하지 않기 때문에 RFC 3986 § 3.2.2에 지정된 대로 호스트 이름은 대소 문자를 구분하지 않습니다 . 이 RFC는 또한 언급 한 문제를 피하는 방법에 대한 권장 사항을 제공합니다.

호스트는 대소 문자를 구분하지 않지만 생산자와 노멀 라이저는 등록 이름에 소문자를 사용하고 균일 성을 위해 16 진수 주소를 사용해야하며 퍼센트 인코딩에는 대문자 만 사용해야합니다.

내가 본 적어도 하나의 HTTP 캐시 ( W3 총 캐시 이런 식으로하지 정상화 호스트 이름을 수행하고, 끝 예를 들어, 아래 내용을 여러 번 캐시까지) example.com, Example.Com, EXAMPLE.COM, 등


1
적어도 최악의 경우는 콘텐츠가 부적합한 캐시에 의해 여러 번 캐시된다는 것입니다.
CVn
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.