simple, easy
and comfortable..
오늘 아침 햇살과 시원한 공기도 같이 기억하자.
« 2004年10月 | Main | 2004年12月 »
and comfortable..
오늘 아침 햇살과 시원한 공기도 같이 기억하자.
무버블타입 3.0 에서 한글 엔트리 제목으로 파일 만들기를 보고 적용시켰습니다. 그리고 마무리를 위해서 무버블타입에서 한글로 파일명을 생성할 경우의 문제 해결책과 iconv를 이용한 한글 URL 변환 방법의 내용대로 해결을 하려고 하였으나 서버 설정의 문제로 보이는 현상에 직면해 어려움을 겪고 있습니다. ^^;
먼저 웹루트 .htaccess 파일에 ErrorDocument 404 /blog/error.cgi 의 내용을 적어넣고 아무리 게시물 링크를 눌러도 계속 404에러가 뜨는 것입니다. 며칠동안 여러가지 테스트와 확인 끝에 .htaccess 파일을 html파일이 있는 폴더 밑에 두어야 한다는 것을 발견했으며 그렇게되면 cgi의 경로를 지정해주기 위해서 ErrorDocument 404 http://yongsang.com/blog/error.cgi 의 내용으로 변경해줘야 한다는 것 까지 알게됐습니다.
드디어 게시물 링크를 눌렀을때 404 에러메시지는 사라졌습니다. 변환코드가 들어있는 error.cgi파일까지 리다이렉트 되는 것은 성공을 했지만 스크립트는 실행되지 않고 새로운 에러 메시지가 저를 환영합니다. 다름아닌 500 Internal Server Error. 아파치 서버가 내부오류라는 메시지를 보냅니다. 아파치 관련 문서를 보니 "ErrorDocument가 외부로 (같은 서버라도 http:와 같은 스킴(scheme)으로 시작한다면) 리다이렉션한다면 이중 어떤 것도 설정되지 않는다." 라고 충고하고 있는데 이 문제때문이 아닌?의심됩니다.
아~ 이쯤되면 서버관리자가 무척 원망스러워집니다. 어떻게 설정을 해놨길래 딴데선 한방에 풀리는 문제가 이리도 안되는 건지 말이죠.. 으~~ 열납니다.
하지만 애써주시는 알록블록님께는 다시한번 감사드립니다. 덕분에 즐거운 작업을 하고 있습니다. ^^ 이젠 해결을 거의 눈앞에 두고 있는 기분인데 그렇겠죠??
500 Internal Server Error이후 아무리 테스트를 해봐도 스크립트에 문제가 있는것은 아닐꺼다는 결론을 내렸습니다. 그렇다면 서버설정에 문제가 있다는 것으로 심증을 굳히고 그것을 확인하기 위해 두 곳에서 동일한 테스트를 실행했습니다. 현재 문제가 있는 제 계정과 다른 호스팅회사를 이용하는 아는 사람의 계정을 빌려서 테스트했습니다.
1. 웹루트 폴더 아래 .htaccess라는 파일을 만들고 그 안에 ErrorDocument 404 /blog/error.cgi 내용을 삽입하고 저장합니다. (이 조작으로 파일없음 404 에러가 발생할 경우에 지정한 웹루트 폴더 밑의 blog폴더 아래 error.cgi로 연결됩니다.)
2. /blog 폴더아래에 error.cgi라는 펄 스크립트를 만들고 아래와 같이 입력한 뒤 파일의 권한은 755로 변경합니다.
자료를 찾아보았더니 두가지 조치가 필요한 것으로 생각됩니다.
1. .htaccess 파일을 사용할 수 있도록 설정을 변경
2. 호출한 스크립트가 실행될 수 있도록 설정을 변경.
이렇게 하려면
httpd.conf 파일의 295번째줄정도
좀 더 편안히.. 좀 더 느긋하게..
조급하고 들뜬 마음을 가라앉히자.
요즘 나도 모르게 열이 올라있단걸 알았습니다.
| Description: | What the server will return to the client in case of an error |
|---|---|
| Syntax: | ErrorDocument error-code document |
| Context: | server config, virtual host, directory, .htaccess |
| Override: | FileInfo |
| Status: | Core |
| Module: | core |
| Compatibility: | Quoting syntax for text messages is different in Apache 2.0 |
In the event of a problem or error, Apache can be configured to do one of four things,
The first option is the default, while options 2-4 are
configured using the ErrorDocument
directive, which is followed by the HTTP response code and a URL
or a message. Apache will sometimes offer additional information
regarding the problem/error.
URLs can begin with a slash (/) for local URLs, or be a full URL which the client can resolve. Alternatively, a message can be provided to be displayed by the browser. Examples:
ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry can't allow you access today"
Additionally, the special value default can be used
to specify Apache's simple hardcoded message. While not required
under normal circumstances, default will restore
Apache's simple hardcoded message for configurations that would
otherwise inherit an existing ErrorDocument.
ErrorDocument 404 /cgi-bin/bad_urls.pl
<Directory /web/docs>
ErrorDocument 404 default
</Directory>
Note that when you specify an ErrorDocument
that points to a remote URL (ie. anything with a method such as
http in front of it), Apache will send a redirect to the
client to tell it where to find the document, even if the
document ends up being on the same server. This has several
implications, the most important being that the client will not
receive the original error status code, but instead will
receive a redirect status code. This in turn can confuse web
robots and other clients which try to determine if a URL is
valid using the status code. In addition, if you use a remote
URL in an ErrorDocument 401, the client will not
know to prompt the user for a password since it will not
receive the 401 status code. Therefore, if you use an
ErrorDocument 401 directive then it must refer to a local
document.
Microsoft Internet Explorer (MSIE) will by default ignore server-generated error messages when they are "too small" and substitute its own "friendly" error messages. The size threshold varies depending on the type of error, but in general, if you make your error document greater than 512 bytes, then MSIE will show the server-generated error rather than masking it. More information is available in Microsoft Knowledge Base article Q294807.
Prior to version 2.0, messages were indicated by prefixing them with a single unmatched double quote character.
출처 : http://httpd.apache.org/docs-2.0/ko/mod/core.html#errordocument
"http://"로 시작하는 외부 URL은 잘 적용되지만 "/"로 시작하는 내부 URL-path는 연결이 되질 않습니다. 왜 그런지 이유를 모르겠습니다.
알록블록의 iconv를 이용한 한글 URL 변환 방법이 드디어 성공했습니다. 어언 10여일간 인터넷을 돌아다니면서 자료를 찾아보고 웹호스팅 관리자에게 수차례 전화해서 설명하고, 요청하고 또 수차례 테스트를 반복하는 작업을 통해 결국 성공할 수 있었습니다.^^ 아파치서버의 설정이 오버라이드와 스크립트 실행 등을 지원하지 않았기 때문이었습니다. 그 과정에서 요청했던 펄의 버전도 5.6.1에서 5.8.5로 업그레이드 되었고 Encode모듈도 설치되었습니다. 이후에 iconv를 사용하는 코드를 Encode모듈을 사용한 코드로 변경해볼 계획입니다. 참고로 알록블록님의 스크립트의 맨 첫째줄(#!/home/bin/perl -w)은 호스팅 업체마다 펄의 경로가 다를수 있으니 자신의 환경에 맞게 고쳐줄 필요가 있습니다. 저의 경우는 "#!/usr/bin/perl -w"로 변경해주었습니다. 알록블록님의 수고에 감사드립니다. ^^
하지만 앞으로는 한글파일명이나 URL을 좀 더 쉽게 사용할 수 있었으면 좋겠다는 생각이 들었습니다. 무버블타입에서 좀 더 적극적으로 한글을 지원해주었으면 좋겠고 아파치 서버에서도 유니코드나 한글사용 지원이 좀 더 일반화되고 사용하기도 쉬웠으면 좋겠다는 아쉬움이 들었습니다.
어쨌든 이제 한글 파일명을 사용하면서 불완전했던 이전 게시물을 완전히 다 볼 수 있게됐습니다.
펄도 5.8.5버전으로 업그레이드 됐고 Encode모듈도 설치됐으니 슬슬 iconv를 사용하는 코드를 Encode모듈을 사용하는 코드로 바꾸려고 마음먹고, 간단히 성공하겠거니 테스트를 해봤는데 실패했습니다. ^^; 또다시 몇가지 확인해보니 URI::Escape 모듈이 없어서 진행이 되질 않는 것입니다. 전에 알록블록님이 말씀한 것이 생각나 블로깅합니다. Encode모듈을 비롯한 필요한 모듈을 개인적으로 설치하는 방법에 대해서 포스팅해주시면 고맙겠습니다. ^^ 즐거운 하루 되시길..
요청 문서 : UTF-8 인코딩하에서 개별엔트리 파일명 한글로 만들기
적개심, 분노, 화... 이것들을 어떻게 할 것인가? 만약 내 마음속에 계속 담아둔다면 내 마음은 상처 받을 것이다. 나를 완전히 태워버릴지도 모른다.
그렇게 내버려 둘 순 없다.
그것들을 몰아내자. 버려버리자.
그것은 내것이 아니다.
나에게 만족스럽고 가치있는 것들을 생각하겠습니다. 상황이 더 좋아지길 기대합니다.
행복하고 편안하기를 기원합니다. 모두 다~
엔트리아이디 확인
변수명에 대문자를 사용할경우 주의해야할 것 같습니다. 알록블록님의 자바스크립트는 대소문자가 섞인 문자열을 출력하지만 새롭게 생성한 코드에서는 모두 소문자로 바꿔출력합니다. 아마도 자바스크립트 생성기 내부구조에 약간의 변화가 있었던게 아닐까 추측합니다. 다시말해 fuckingSpamCommenter 같이 변수명에 대문자를 사용해서 스크립트를 생성해도 그 스크립트로 생성되는 문자는 모두 소문자로 바뀝니다. 이메일 주소를 생성하는 스크립트이기 때문인 것 같습니다.
그러니까 처음부터 소문자로된 변수명을 쓰기로한 경우라면 아무 문제 없지만 대소문자를 섞어쓴 변수명을 사용할 경우 제대로 그렇게 표시되는지 확인할 필요가 있습니다.
덕분에 이제 스팸코멘트에 신경 끌 수 있겠군요. 감사합니다. ^^
This page contains all entries posted to yongsang's weblog ::: 용상의 블로그 in 2004年11月. They are listed from oldest to newest.
2004年10月 is the previous archive.
2004年12月 is the next archive.
Many more can be found on the main index page or by looking through the archives.