☰

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

tag-icon • tag-icon domain http case-insensitive
HTTP(S) URL의 호스트 이름 부분은 대소문자를 구분하지 않나요?

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

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

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

URL의 호스트 이름 부분에 대문자가 포함된 문제를 경험한 사람이 있나요?

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

나는 특히 클라이언트에서 비호환 소프트웨어가 얼마나 널리 퍼져 있는지 파악하려고 노력합니다. 나는 최근의 모든 주요 브라우저가 괜찮다고 가정하지만, 예를 들어 모바일 앱은 어떻습니까? (이것을 별도의 SF 질문으로 나누어야 할까요?) [/edit]

답변1

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

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

나는 적어도 하나의 HTTP 캐시를 보았습니다(W3 총 캐시) 이러한 방식으로 호스트 이름을 정규화하지 않고 결국 콘텐츠를 여러 번 캐싱하게 됩니다(예 example.com: Example.Com, EXAMPLE.COM, 등).

관련 정보