회사에서 회의 중 URL이 Case Sensitive하게 처리되어야 하는지에 대한 사실 확인이 필요하여 이를 찾아본 과정의 기록입니다.

결론부터 말하면 URL은 Case Sensitive 합니다.
(결론부터 알려드렸지만 끝까지 읽어주세요. 광고도 없는 걸요;)

아주 조금만 더 들어가서 우리가 URL이라고 말하는 건 크게 6가지 요소로 나눌 수 있습니다.

RFC 7230에 따르면, 위 구성요소 중 Scheme와 Host를 제외한 요소들은 Case Sensitive하게 처리되어야 합니다.
(Port는 숫자로만 구성되니 논외로 합시다)

 

시작부터 비교적 명확하게 결론이 났습니다.  Scheme와 Host를 제외한 요소들은 Case Sensitive하게 처리되어야 한다.

즉,  https://www.google.com/HTTPS://WWW.GOOGLE.COM/은 완전히 동일한 결과를 보장하지만,  https://www.google.co.kr/search?query=new와 https://www.google.co.kr/search?query=NEW는 다른 URL로 볼 수 있고, 실제로 검색결과도 미세하게 다릅니다.

 

어허,  근데 실제로 대부분의 사람들이 URL을 입력 할 때 대/소문자를 의미있게 구분해서 사용하고 있을까? 라고 자문해보면  ‘아니오‘라고 말 할 수 있습니다. 대부분의 사람들은 소문자만으로 URL을 입력하고 있고, URL에 대문자가 섞여 있다면 아마 Caps lock을 의심해봐야 합니다.

RFC 규약의 scheme와 host를 제외한 요소는 Case Sensitive하게 처리돼야 한다는 사실과는 별개로 실제 URL에 대소문자를 의미있게 섞어서 사용하는 사람이 거의 없다고 할 때,  HTTP://WWW.EXAMPLE.COM/LIST로 접속한 사용자에게 http://www.example.com/list의 결과화면을 보여주지 않을 이유가 없습니다.

실제로 많은 서비스들에서는 Scheme와 Host를 제외한 요소에 대해서도 Case Insensitive하게 URL을 처리하고 있습니다.  믿지 못하는 분은 아래 2개의 링크를 클릭해보시길 바랍니다. 동일한 페이지를 나타내는 걸 알 수 있습니다.

http://stackoverflow.com/questions/7996919/should-url-be-case-sensitive

HTTP://STACKOVERFLOW.COM/QUESTIONS/7996919/SHOULD-URL-BE-CASE-SENSITIVE

 

다시 처음으로 돌아가서 그래서 URL은 Case Sensitive한가? 또는 Case Sensitive하게 처리되어야 하는가?

RFC에 따르면 Scheme와 Host를 제외한 요소들은 Case Sensitive하게 처리되어야 한다. 허나; 서비스에서 Path와 Query, Fragment의 대소문자 구분이 크게 의미가 없을땐 알아서 잘 하자잉.

 

References