-
- 1. URL에 "?" 대신에 "/" 를 사용
-
-
- 1.1. 이슈
-
- 1.2. 사용법
-
- 1.3. 부작용
-
- 1.4. wiki.pl 수정
-
- 1.5. 추가 업데이트 내역
-
- 1.6. 사용자 의견
-
1. URL에 "?" 대신에 "/" 를 사용
주소에 "?" 대신에 "/" 를 사용해서
- wiki.pl/페이지이름
- wiki.pl/메인페이지이름/서브페이지이름
- wiki.pl/action=edit&id=페이지이름
등을 처리할 수 있게 해보자.
(이렇게 해야 하는 이유는... IE의 버그 때문에 UTF-8로 URL이 넘어올때 "?"뒤의 쿼리 스트링이 잘못된 코드로 넘어오기 때문이다. 유니코드논의/파일명인코딩과 UseModWiki소스수정/UTF-8로인코딩된쿼리처리 참고)
접근 방법
- 위키 내에서 다른 페이지의 링크를 걸 때 ? 대신 /를 쓰는 것은 /SlashLinks에 의해 쉽게 된다.
- 위키는 최소한만 고치고 웹서버의 mod_rewrite 를 이용 - 이건 위키와 별개의 얘기니까 여기서는 패스
- 또는, 위키 스스로 PATH_INFO 정보를 가져와서 처리 - 여기서 이 작업을 해보자
현재 문제점:
- 위키 출력에서 상대 경로로 된 링크가 있을 경우, 웹브라우저가 그 경로를 wiki.pl이 있는 디렉토리가 아니라, URL의 가장 마지막 슬래쉬 직전의 이름을 기준으로 해석해버린다.
- 예: wiki/wiki.pl/Raymundo 에서 wiki.css 를 가져오려면 wiki/wiki.pl/wiki.css 를 부르게 되고 <-- 무한루프 위험
- 예: wiki/wiki.pl/메인페이지/서브페이지 에서 wiki.css 를 가져오려면 wiki/wiki.pl/메인페이지/wiki.css 를 가져오려 함
- 따라서 모든 링크가 절대 경로로 출력되거나, PATH_INFO 에 있는 슬래쉬 갯수만큼 "../"을 붙여주어야 함. (WikiPatches/SlashLinks의 방법)
- wiki.pl로 걸리는 링크는 이 방법으로 해결할 수가 있는데, 그 외에 브라우저가 직접 접근을 시도하는 스타일쉬트, 자바스크립트, 이미지, 첨부파일 등이 문제가 된다.
- 문제가 되는 항목들: (이걸 다 찾아내는 것도 일이다. 애초에 브라우저에 노출되는 디렉토리와 wiki.pl 내부에서 사용하는 디렉토리의 이름을 구분되게 지었어야 했다 ㅠ,.ㅠ)
- $StyleSheet
- $IconDir
- $InterIconDir
- $UploadUrl - 명시되지 않은 경우
- $JavaScript
- $OekakiJar
- 더 있으려나?
- 이 변수들의 값을 다 절대경로로 주면 문제는 해결되는데, 그럼 배포용 패키지에 기본값을 무엇으로 해야 좋을지 모르겠음.
- 아니면 wiki.pl 내에 이 변수를 쓰는 곳을 다 찾아서, 그 앞에다가 "../"를 필요한 갯수만큼 붙이도록 해줘도 되겠는데, 그러면 반대로 사용자가 저 변수의 값을 절대 경로로 준 경우가 문제.
- 각 변수를 사용할 때마다 그 변수의 값이 절대경로인지 상대경로인지 판단하게 하는 것은 너무 배꼽이 크다. 그냥 두고, SlashLinks 를 1로 바꾸게 되면 사이트 운영자가 직접 적절하게 고치도록 강요하는 수밖에 없을 듯.. (아 빌어먹을 IE버그)
- 어느날 GyparkWiki 가 slash link 를 쓰도록 변경되었을 때, 기존에 이 위키의 페이지를 링크하고 있던 것들이 제대로 돌아갈 것인가?
참고:
1.4. wiki.pl 수정
sub InitRequest {
...
$CGI::POST_MAX = $MaxPost;
$CGI::DISABLE_UPLOADS = 0;
if ($SlashLinks && (length($ENV{'PATH_INFO'}) > 1)) {
$ENV{'QUERY_STRING'} .= '&' if ($ENV{'QUERY_STRING'});
$ENV{'QUERY_STRING'} .= substr($ENV{'PATH_INFO'}, 1);
}
$q = new CGI;
$q->autoEscape(undef);
if ($q->cgi_error() =~ m/^413/) {
print $q->redirect(-url=>"http:$ENV{SCRIPT_NAME}".&ScriptLinkChar()."action=upload&error=3");
exit 1;
}
$UploadUrl = "http:$UploadDir" if ($UploadUrl eq "");
$Now = time;
$ScriptName = pop(@ScriptPath);
if ($SlashLinks) {
my $numberOfSlashes = ($ENV{'PATH_INFO'} =~ tr[/][/]);
$ScriptName = ('../' x $numberOfSlashes) . $ScriptName;
}
$ScriptName = $FullUrl if ($FullUrl ne '');
$IndexInit = 0;
$InterSiteInit = 0;
...
}
SlashLinks 옵션을 켰을 때, 로그인할 때는 로그인 폼에서 "디렉토리/wiki.pl"을 부르기 때문에 쿠키의 path가 "디렉토리/"가 되는데, 로그아웃하는 시점에서는 URL이 "디렉토리/wiki.pl/action=logout"이라서 path가 "디렉토리/wiki.pl/"이 된다. 따라서 한번 로그아웃하고 나면, 브라우저를 재시작하거나 쿠키를 삭제하지 않는 이상 두 개의 서로 다른 쿠키가 충돌하여서 로그인이 되지 않게 된다.
이 문제를 해결하기 위해 명시적으로 쿠키의 path값을 지정하도록 하였다. 하는 김에, 차후에 mod_rewrite를 써서 홈페이지 주소를 단순화하였을 때도 써먹을 수 있도록 그런 경우의 처리도 해 주었음. (한다고는 했는데, rewrite 룰을 어떻게 주느냐에 따라서 제대로 안 될 수도 있을 듯)
sub GetHttpHeader {
...
. "&randkey&" . $SetCookie{'randkey'}
. ";";
my $cookie_path = $q->url(-absolute=>1);
if ($ENV{'SCRIPT_NAME'} eq $cookie_path) {
$cookie_path =~ s/[^\/]*$//;
} else {
if ($ENV{'PATH_INFO'} ne '') {
$cookie_path =~ s/$ENV{'PATH_INFO'}$//;
} else {
$cookie_path =~ s/$ENV{'QUERY_STRING'}$//;
}
}
$cookie .= "path=$cookie_path;";
if ($SetCookie{'expire'} eq "1") {
$cookie .= "expires=Fri, 08-Sep-2010 19:47:23 GMT";
}
...
}
1.5. 추가 업데이트 내역
ext1.107a
- 로그아웃하고 나면 해당 세션에서 더 이상 로그인이 되지 않는 문제 수정
하나를 고치면 다른 게 걸리고... 아 왜 버그가 있는 건 브라우저인데 그것 때문에 이 고생을 해야 해 ㅠ,.ㅠ
음, 우려와는 달리 잘 동작하는 것 같군요. 그런데 좀 전에 로그아웃했다가 다시 들어왔더니만 로그인이 계속 풀려서 덜컥 했습니다만, 웹마를 재실행하니까 잘 됩니다. URL이 wiki.pl 로 끝나지 않고 뒤에 계속 슬래쉬가 붙는 것이 쿠키 처리에 영향을 주는 게 아닌지 조금 걱정스럽긴 하네요. 그 외에는 별 문제 없어 보입니다.
- 으음... 로긴을 할 때는 쿠키가 /cgi-bin/wiki/ 에 대해서 설정되고, 로그아웃을 할 때는 /cgi-bin/wiki/wiki.pl/ 에 대해서 설정되는 바람에, 다시 로긴을 하더라도 서로 다른 두 쿠키 사이에 충돌이 일어나는 듯.
- 이 문제는 해결했는데, 이번에는 트랙백에서 생각지도 못한 문제 발견. (별 문제가 없는 게 아니었군)
SlashLinks 를 켠 상태에서, 유즈모드에서 유즈모드로 트랙백을 보냈을 때 내용이 깨짐. 트랙백 대상 주소에 "?"가 없기 때문에 POST 방식으로 보내어서 그런 것 같긴 한데, 유즈모드->태터(태터 주소에도 물음표 없음)로 보내는 건 또 괜찮다. 태터->유즈모드도 괜찮고...
- 트랙백 내용이 깨지는 것은 캐릭터셋을 지정해주지 않았기 때문이었고, 간단히 해결.
다른 문제 발견, URL에 "/"대신 "%2F"로 인코딩되어 있으면 오히려 못 찾는다. OTL
- "/"는 인코딩하지 않게 함.
위키위키분류