Httpwatcher에서 이미지 요청시 Aborted 되는 현상

항상 이런 이슈는 퇴근쯔음 생긴다..-_- 싫다 정말..
여튼, 개편이후, PV가 갑자기 줄어서.. 확인해본결과..
문제는 이미지 태그의 src 이용해 리퀘스트를 날릴때, 그 리퀘스트가 중지되는 현상이 발견됐다.
Httpwatcher에서 확인해본결과.. 
아래와 같은 코드 사용시에..
(new Image()).src = “로그집계기록” 
열에 2~3번은 aborted가 되고 있었다. 
위와 같은 상황이라면 PV가 대략 20~30%는 하락할것이다..ㅎㅎ
여튼 수많은 삽질을 통해 대강의 원인을 찾아본결과..
아래와 같은 이유가 있었다.  (이유는 3가진데.. 자세한건 아래 링크 참조)

http://blog.httpwatch.com/2008/01/28/what-does-aborted-mean-in-httpwatch/

그중에서 다운로드 중일때, 리퀘스트를 날리면 요청을 끊어버린다는 것!!
이게 가장 유력한 원인으로 파악되고 있다. 
일단.. 내일 다시 테스트해봐야징.. 졸립넹..-_-
—–
최종정리~
위에서 발생한 문제는 최종적으로 가비지 콜렉션 문제로 정리됐다. 
즉, 위와 같이 (new Image()).src = “로그집계 기록”을 호출할경우..
요청에 대한 응답을 받기도 전에 이미지 객체가 가비지 콜렉션 되어 사라질수 있다. 
이럴경우, 응답은 취소가 된다. 
해결책은 간단하다. 가비지 콜렉션 되지 않도록 이미지의 참조 카운터를 누군가가 들고 있으면 된다. 아래와 같이 전역변수로 가지고 있어도 되고,
_gImg = [];
function 로그집계 = {
    var o = new Image(); 
    o.src = “로그집계”;
    _gImg.push(o);
}
로그집계();
혹은 아래와 같이 abort 이벤트에 대해서 이벤트를 바인딩 해둬도 된다 
function 로그집계 = {
    var o = new Image(); 
    o.src = “로그집계”;
    o.abort=function(){};
}
로그집계();
후자보다는 전자가 보다 명확한 방법이다. 
후자의 경우의 코드상의 의미는 abort 이벤트가 발생했을때, 어떠한 처리를 따로 해주는것인데..
저렇게 아무런 의미없는 함수를 바인딩해둘필요는 없지 않을까?
그래서 전자로 처리했다. 

FF 에서 강제로 한글 IME 변경하기..

imeMode 속성은, IE 전용 속성인데,
FF3 에서부터는 해당 속성을 지원해주는듯하다..
https://developer.mozilla.org/En/CSS/Ime-mode

하지만.. 테스트는 안해봤다. 테스트 해본 사람들에 의하면,..
아직 안된다고 하더라..ㅎㅎ

그래서 좀더 크로스 브라우징이 가능한 방법이 없을까?
생각하다가.. Flash 인터페이스를 이용하는건 어떨까 생각해봤다.
아래 링크를 참조하고..
http://kimkijeung.com/entry/IME-Input-Method-Editor

위 링크처럼 가능하다면, 플래시컨테이너 하나 로드해놓고,
인터페이스 함수만들어서, 자바스크립트로 해당 함수를 호출하면
간단히 해결될것같은데..

오늘 집에가서 한번 만들어봐야겠당..ㅋ

반대로, FF에서 한글을 입력 안하게 하는 방법도 있을수 있겠다
편법이지만..
http://blog.hooriza.com/1049

스크립팅 미디어 타입 : Scripting Media Types

오늘 스터디하다가, <script type=” “></script>에서 쓰이는 type의 형태에 대해서 잠깐 언급이 되서 정확하게 무슨 차이가 있는지.. 알아보기위해 또 검색을 시작했다.

사실 내가 알고 싶었던건…
text/javascript 와 application/javascript 그리고 application/x-javascript 로 선언된것들의 미묘한 차이였다.
그래서 찾아본 문서는 IETF에서 발행한 RFC4329 문서의
Scripting Media Types 라는 원문을 참고했다.
통번역을 하려고 했으나.. 기술문서라서.. 통번역보다는 그냥 중요부분만 발췌하기로 한다.
스크립팅 미디어 타입은 아래와 같이 다양하게 존재한다.

   +-----------------------------------------------------+
      | text/javascript          | text/ecmascript          |
      | text/javascript1.0       | text/javascript1.1       |
      | text/javascript1.2       | text/javascript1.3       |
      | text/javascript1.4       | text/javascript1.5       |
      | text/jscript             | text/livescript          |
      | text/x-javascript        | text/x-ecmascript        |
      | application/x-javascript | application/x-ecmascript |
      | application/javascript   | application/ecmascript   |
      +-----------------------------------------------------+

하지만, text 라는 시작하는 타입들은 문제의 소지가 있다고 알려져 있기때문에 RFC4329 문서에서는 text/javascript와 text/ecmascript에 “obsolete” 즉, 시대에 뒤진 혹은 안 쓰이는 것으로 표기하고, 대신에 application/javascript 와 application/ecmascript 를 쓸것을 권하고 있다. 
이유는 간단히 얘기하면,.. 구현정의에 있어서.. SHOUD와 MUST의 차이..
그리고 RECOMMENDED와 REQUIRED 라는 단어의 차이다. 
application/ecmascript는 must와 required 로 정의되기때문에.. 이 스크립팅 타입을 쓰게 되면, 좀더 명확한 사용과 어디에 무슨 용도로 쓸때인지를 명확하게 정의할수 있고, 장려할수 있다는 얘기가 되고, 반대로 text/javascript 일 경우에는 너무 널리 사용되기때문에.. 편법이나, 오용할 소지가 있다는 늬앙스를 가지고 있다. 
여튼, 문서를 좀더 자세히 살펴보면, 
소스코드 해석문제, 보다 상세히 얘기하면, 바이너리 소스코드도 소스코드로 해석이 되는데, 이런 바이너리 소스코드를 엔진이 실행할때, 인코딩방법의 차이가 있단다..
그리고 보안 이슈도 있다. 
보안 이슈는 인젝션 공격이라든가, 머 이러저러한 이야기들이 문서안에 있는데…
자세한 내용은 원문을 보길 바란다.
원문을 보기 싫은 사람은 나중에 내가 번역해서 올리길 기다하시길~@@ ㅋㅋ
오늘 여기까지고 어여 자야겠다.. 쓩~!