개발&Development/웹 2006.11.17 05:28 posted by 겐도

과거 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 옵션 변경.

'개발&Development > ' 카테고리의 다른 글

DDoS of Spam  (2) 2006.11.22
스팸업계의 반격?  (0) 2006.11.20
mod_url과 IE7  (8) 2006.11.17
미디어 태그  (3) 2006.11.17
이럴수가!  (0) 2006.11.15
mysql_real_escape_string의 황당한 시츄에이션  (1) 2006.10.30
TAG , ,
  1. Commented by C.L at 2006.11.17 06:18

    http://cl.dgtalx.net/50 요기 보시면 솔루션이..

  2. Commented by 세라비 at 2006.11.17 13:40

    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을 가정하는 방향(이를테면, 액세스하는 파일시스템의 인코딩으로 변환한다거나)이 가장 적절하겠죠.

    • Commented by 겐도 at 2006.11.17 15:01

      서버가 보내온 euc-kr 주소를 다시 번역해서 utf-8로 보내는 IE7의 이상한 동작이 문제랍니다. %인코딩과는 다른 문제.

  3. Commented by 세라비 at 2006.11.17 15:21

    그러니까 제 말은 Percent-encoding이 URI 표준이므로, 설령 웹서버가 비표준 URL로 redirect하더라도 Percent-encoding으로 요청하는게 표준적인 동작이지, '이상한 동작'은 아니라는 거죠. 서버의 파일 이름에 대한 인코딩 문제는 서버에서 해결할 일이지, 저렇게 이상하게 처리하는 것이 (어쩔 수 없이) 잘못 처리해온거구요. 앞으로 IE 7의 이러한 강제때문에 좀 더 표준적인 처리가 가능하겠죠.

    • Commented by 겐도 at 2006.11.17 16:00

      euc-kr로 들어온 내용을 그대로 %인코딩하는게 아니라 utf-8로 변환후 전송하는게 문제 :)
      기존에 서버에서만 땜빵을 해서 브라우저가 하는 짓을 예상하고 만들었는데 갑자기 브라우저가 배반을 한거에요. 헤더의 내용에 euc-kr이 들어온 것을 감지하고는 케릭터 셋을 변환해 버리죠. 사실 헤더에는 ascii만 올 수 있다고 정의되어 있는데 mod_url이 % 인코딩 안하고 전송한 것도 문제였지만 IE7이 또 나름대로 땜빵한다고 거길 케릭터셋을 확인해 버렸으니;;;

  4. Commented by 세라비 at 2006.11.17 18:26

    제가 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 여기를 읽어보시길...

  5. Commented by 세라비 at 2006.11.17 18:30

    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을 시도한다면?