과거 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 옵션 변경.
이올린에 북마크하기
이올린에 추천하기Trackbas address :: http://gendoh.tistory.com/trackback/2510825
-
Tracked from Go! Bbuwoo
at 2007/05/28 02:16
삭제
Subject: IE7 과 mod_url 문제
IE7 에서 mod_url 이 설정되어 있는 서버로 한글 주소를 전송할 경우 encoding 이 맞으면 (즉, mod_url 이 작동할 일이 없으면..) 문제가 없지만, 맞지 않을 경우에는 무한 루프에 빠지게 되는 문제가 있습니다. 즉 예를 들어서, 다음의 조건에 해당될 경우 입니다. IE7 이 URL 의 utf8로 전송한다. (기본값임) 서버측의 mod_url 이 다음과 같이 설정이 되어 있다. CheckURL on ServerEncoding EU.....
http://cl.dgtalx.net/50 요기 보시면 솔루션이..
여러가지 방법들이 있겠지만 역시 시스템을 utf-8로 개편하는 것이 최고겠죠.
IE에서 UTF-8로 전송한다는 것은 아마 Percent-encoding을 얘기하는 걸 겁니다. IE란 둑이 무너진 것이 아니라, 땜빵을 점진적으로 제거해온 것이 맞죠. Percent-encoding은 URI 표준에도 이미 들어가있고 IE 6부터 Percent-encoding은 지원했고 IE 7은 그걸 더 강화한 조치에 불과하죠. 그냥 단순히 URI가 UTF-8 즉, 현재 URI에 허용되지 않는 문자들로 확장하는 걸 얘기하시는 거라면, 또 다른 차원의 얘기지만, Percent-Encoding만으로도, Client-side에서는 URI을 보여줄 때만 decoding해서 보여주고, Server-side에서는 Percent-encoding을 가정하는 방향(이를테면, 액세스하는 파일시스템의 인코딩으로 변환한다거나)이 가장 적절하겠죠.
서버가 보내온 euc-kr 주소를 다시 번역해서 utf-8로 보내는 IE7의 이상한 동작이 문제랍니다. %인코딩과는 다른 문제.
그러니까 제 말은 Percent-encoding이 URI 표준이므로, 설령 웹서버가 비표준 URL로 redirect하더라도 Percent-encoding으로 요청하는게 표준적인 동작이지, '이상한 동작'은 아니라는 거죠. 서버의 파일 이름에 대한 인코딩 문제는 서버에서 해결할 일이지, 저렇게 이상하게 처리하는 것이 (어쩔 수 없이) 잘못 처리해온거구요. 앞으로 IE 7의 이러한 강제때문에 좀 더 표준적인 처리가 가능하겠죠.
euc-kr로 들어온 내용을 그대로 %인코딩하는게 아니라 utf-8로 변환후 전송하는게 문제 :)
기존에 서버에서만 땜빵을 해서 브라우저가 하는 짓을 예상하고 만들었는데 갑자기 브라우저가 배반을 한거에요. 헤더의 내용에 euc-kr이 들어온 것을 감지하고는 케릭터 셋을 변환해 버리죠. 사실 헤더에는 ascii만 올 수 있다고 정의되어 있는데 mod_url이 % 인코딩 안하고 전송한 것도 문제였지만 IE7이 또 나름대로 땜빵한다고 거길 케릭터셋을 확인해 버렸으니;;;
제가 Percent-encoding을 Percent-encoding + UTF-8로 가정하고 덧글을 적어서 오해가 좀 일어났군요.
제가 보기에는 전혀 문제 없어보이는데요. 클라이언트와 서버는 서로의 인코딩을 모르고 있기때문에 적어도 약속된 인코딩 하나는 있어야합니다. (서버의 인코딩을 무조건 사용해야한다고 생각하시나요?) IE 7은 UTF-8을 그 약속된 인코딩으로 사용하는 것이구요. URI 표준도 UTF-8을 추천하고 있습니다.
서버의 인코딩을 무조건 사용해야한다고 가정한다면 몇가지 문제들이 발생하죠. 물론 모든 URI가 서버에서 생성된다고 생각하면 아주 단순하지만, 현재의 URI사용 practice만 보더라도 URI는 클라이언트에서도 생산될 수 있어요. 그 외에도 서버의 인코딩을 클라이언트는 알 수 없기 때문에 제가 위에 적은 것처럼 클라이언트는 URI를 적절하게 decoding해서 보여줄 수가 없게되죠. 간단하게, URI는 전세계 사람들이 적어도 제대로 볼 수 있어야한다면?
mod_url의 동작에 맞추는게 아니라, 일반적으로 local encoding문제를 해결하는 방법이 무엇인지 생각해보면 IE의 방법이 최선이라고 생각합니다.
자세한 것은 http://tools.ietf.org/html/rfc3986#section-2.5 여기를 읽어보시길...
IE 7이 Percent-encoding 없이 온 비표준 URL을 적절하게 'decoding'하는 것은 파일에서 읽은 비표준 URL을 적절하게 'decoding'하는 것과 다를게 없습니다.
UTF-8로 encoding하는 문제와는 별개의 문제죠.
Percent-encoding으로 왔다면 UTF-8 encoding으로 가정할테고, 만약 mod_url이 Percent-encoding + euc-kr을 한다면, 그리고 웹서버가 local encoding에 따라 Percent-encoding을 decoding한다면 mod_url에도 별다른 문제가 없을 수도 있겠군요.
하지만, 만약 브라우저가 URI의 (예쁜?) 표시를 위해 decoding을 시도한다면?