수학에서 어떤 방정식을 푼다고 할 때 우선적으로 고려하는 것은 “해가 존재하는가?”하는 문제다. 비슷하게 우리가 어떤 버그를 잡으려고 할 때 – 즉 디버깅; debugging 할 때 – 고려해야하는 것은 “이게 버그가 맞는가?; 의도된 사항인가?” 이다.
어제 저녁에 WordPress의 Simple Tagging Plugin에서 태그 이름을 C++로 했더니 해당 페이지를 못찾는 삽질을 하길래 이걸 해결하려고 삽질을 좀 했다. 내가 발견한 버그는 다음과 같은 거(였)다.
태그의 이름을 + 가 들어간 문자열 – 예를 들어 C++ – 로 한다.
해당 태그를 태그 클라우드에서 클릭하거나 임의로 해당하는 태그의 주소를 생성한다.
웹 브라우져에서 제대로 페이지가 나오나 본다 해당하는 포스트가 존재해도 나오지 않는다.
사실 이런 식으로 재현가능했기 때문에, 재현도 가능한데 곧 잡겠지라고 생각하면서 디버깅을 시작.
처음 닥친 문제: 수정한 코드가 페이지 출력에 반영이 되었다 말았다 한다. …원인이 좀 어이없었는데 내가 수정한 부분이 처음 반영되었다가 중간에 고친게 반영이 안되서 뭔가 했는데, 15분짜리 타이머를 갖는 쿼리 결과 캐쉬가 돌고 있었다. WordPress 전체의 캐슁 기능은 꺼 둔 상태라 전혀 예상하지 못했는데, 태그 플러그인 자체에서 캐슁하는 부분이 있더라 -_-;;
플러그인 캐슁 끄고 디버깅을 하다하다 안되서 소스 코드를 다시 보는데 재밌는 부분이 하나보인다 (주석에 주목).
$tag_name = str_replace(‘%2F’, ‘/’, $tag_name); // seems that Apache’s mod_rewrite are unable to handle urlencoded URLs properly
$tag_name = str_replace(‘%2B’, ‘+’, $tag_name); // seems that Apache’s mod_rewrite are unable to handle urlencoded URLs properly
$tag_name = str_replace(‘%20’, ‘_’, $tag_name); // seems that Apache’s mod_rewrite are unable to handle urlencoded URLs properly
Orz.
현재 이 블로그는 apache mod_rewrite를 통해 재해석되서 전달되는 URI를 기반으로 동작하고 있다. …그런 의미에서 워드프레스 플러그인에서 전달한 +나 /, _를 apache 쪽에서 제대로 처리하지 못하는 것이다. 즉, 플러그인 버그가 아니었던 것. 내가 손 댈 수 없는 부분 – 그러니까 apache mod_rewrite – 의 문제니 그냥 넘어가야한다 Orz
결국 나는 PHP 코드 안에 버그가 있었다고 생각했으나, 버그(?)는 PHP 밖, apache안의 특정 모듈에 있었던 것. 한 마디로 방정식의 해가 아예 없는걸 하고 있던거다 Orz
