mod_url과 IE7

과거 URL에 ASCII가 아닌 문자가 들어왔을때 브라우저마다 서버마다 꼬여서 나온 것이 mod_url 모듈입니다. url을 검사해서 서버의 케릭터 셋과 맞지 않는다 싶으면 문자를 변환한 후 클라이언트에게 location 헤더로 알려줍니다. 그래서 적당한 곳으로 옮겨주죠. 비슷하게 태터툴즈의 경우 어떤 케릭터 셋으로 날라와도 가능한한 잘 처리하도록 코딩되어 있습니다. 물론 100% 동작은 하지 않지만 꽤 무난한 정도죠.

땜빵은 땜빵을 만들고 그것이 지속되다 결국 댐을 무너트리니, IE7이란 둑에 문제가 생긴 것 같습니다. UTF-8로 전송된 URL에 대해 mod_url이 euc-kr로 변환해서 접속해라고 알려주고 IE6는 이를 그대로 재전송하므로 문제가 없었는데 IE7은 다른 특성을 보입니다. UTF-8 옵션이 있는 경우 location 정보로 euc-kr이 온것을 인식하고는 이를 utf-8로 변환, 전송합니다. mod_url과 IE7과의 무한 전쟁이 시작됩니다. IE7은 끊임없이 UTF-8로 전송을 시도하고 mod_url은 끊임없이 euc-kr 주소로 접속하라고 반송합니다.

서버관리자분들 중 IE7 이후 트래픽이 급증했다고 생각이 든다면 mod_url의 제거를 검토해 보시기 바랍니다. 정상적인 방법이 아니다 보니 IE7에서 문제가 생겨버린 것 같습니다.

이 문제를 해결하는 가장 좋은 방법은 url은 ascii만으로 이루어 지게 하는 것입니다. 비록 그것이 외계어처럼 보여도 '%'가 난리를 치고 링크 길이가 상당히 길어지긴 하지만 url-encoding을 하는 것이 가장 정석입니다.

개인적으로 퍼머링크 같은 것은 시스템만 잘 알아보면 되지 이쁠 필요가 없다라고 생각하여 태터에 대해서도 모든 링크를 수정하려고 하였지만 어떤 사람들은 "이쁜 링크주소"가 필요하다는 군요. 이 상황에서 아마 가장 좋은 방법은 IANA를 뒤집어 엎어서 URL과 HTTP의 헤더 부분에 utf-8을 허용토록 하고는 모든 관련 업체들 보고 그렇게 구현하라고 하는 것입니다. 이러는 경우 어떤 문제가 생기냐면 HTTP를 쓰는 모든 프로그램과 장비들은 기존에 ascii만 써서 쉽게 구현되던 부분이 utf-8 모듈까지 올려야 하는 부담이 생깁니다. 아마 왠만큼 흔들어서는 꿈쩍도 안하겠죠. 따라서 현재 취할 수 있는 방법은 아마 잘 구현일 것입니다.

태터의 방식의 한계는, 아니 utf-8을 쓰지 않는 모든 상황에서 동일합니다만 UTF-8이 아닌경우 단 한가지 언어권의 데이터로만 받을 수 있습니다. euc-kr과 euc-jp를 동시에 처리하는 것은 거의 불가능해 집니다.

아니면 그언젠가 홍보했던 IE 옵션 변경.