IT 소시민의 소소한 이야기

HTTP 프로토콜에는 요청에 대해 오류가 발생시 그에 적절한 오류 응답 코드를 정의하고 있습니다. 예를 들어 404는 페이지가 없는 경우, 500은 내부 서버 오류 등등으로요.
웹서버나 WAS에는 이러한 코드들에 대한 기본 페이지를 가지고 있습니다. 하지만 이러한 페이지들을 그냥 사용하는 경우는 없고 보통 사이트에 맞게 재정의해서 사용하기 마련입니다. 오류가 발생시 자신의 사이트에서 원하는 디자인으로 오류 발생을 알리는 거죠.
Java 플랫폼일 경우 모든 예외(exception) 발생을 포착하여 보통 사용자에게는 하나의 오류 페이지를 보여주게 지정하게 됩니다.
이러한 작업을 현재 진행하고 있는 프로젝트에 적용 중이었습니다. 예외 포착도 잘하게 설정 완료하고, 간단하게 오류 페이지도 만들어 놓은 후 프로그램에서 일부러 예외를 발생하게 설정을 완료한 후에 브라우저에서 해당 url을 요청하여 결과를 확인했습니다.
먼저 FF에서는 결과가 제대로 나왔습니다. 그 다음 IE 차례였는데, 제가 지정한 오류 페이지가 보이질 않고 브라우저 자신의 500 오류에 대한 메시지가 나오는 것입니다.

'음... 이상하네...'

Fiddler로 확인 결과 오류 코드와 함께 지정한 오류 페이지는 제대로 반환되고 있었습니다.
이 때부터 땅파기가 시작됐죠. 이러 저러한 설정들을 해가며 아무리 해도 여전히 안 되는 겁니다. 엄청난 땅파기 후에,

'음... 구글에게 한 번 물어볼까'

하는 생각에 검색 결과 다음과 같은 답을 찾을 수 있었습니다.

A Warning about Microsoft Internet Explorer - IE and too-short custom 404 error pages

IE는 특정 오류 페이지가 자신이 원하는 크기보다 작을 경우 응답 받은 내용을 보여주는 것이 아니라 자신이 가진 해당 오류에 대한 내용을 보여주는 것이었습니다.
다음의 표는 위의 URL에서 인용한 내용입니다.

티베로 데이 2008에 다녀왔습니다.
(http://tiberoday.tmax.co.kr/index.jsp)

사실 기념품에 눈이 멀어 다녀왔지만, 회사에서 티베로 도입을 검토한다는 얘기도 있고 해서 동향 파악도 할 겸 다녀왔습니다.

컨퍼런스의 슬로건은 Over The miRACLE 이었습니다. 제가 굵은체로 표시한 부분만 보면 아시겠지만 ORACLE을 넘어서겠다는 그들의 의지를 나타나내는 슬로건입니다. 물론 이런 해석은 자의적인게 아니라 티맥스 쪽에서 그렇게 얘기하더군요.

4시간이상 앉아서 들으면서 느낀 점은 티맥스가 기업 데이터 정복을 위해 엄청나게 노력하고 있다는 것이었습니다. 자세히 찾아본 것이 아니어서 틀릴 수도 있지만 오라클이 제공하는 제품군에 대응하는 모든 제품들을 다 선보이고 있는 듯 했습니다.

다른 것들은 제가 엔터프라이즈 환경에서 개발을 하고 있지 않기 때문에 별로 눈에 들어오지 않았지만, Tibero라는 DMBS 자체와 Tibero Lite는 관심이 가더군요.

뭐 당연히 자사 제품 소개니까 좋다고 하겠지만, 성능 평가 결과 Tibero가 Oracle에 비해 동등하거나 조금 더 나은 결과를 보여준다고 합니다. 거기다가 가격도 Oracle에 절반정도이며 기존에 Oracle에서 마이그레이션을 하는 경우 툴의 제공은 물론 기존의 질의문이나 프로시져, 함수 등을 거의 수정할 필요가 없다고 합니다.
오라클을 쓸 수 밖에 없는 환경이라면 한 번 쯤 고려해 볼 만한 거 같습니다. 비용도 비용 문제지만 국내 업체이기 때문에 강할 수 밖에 없는 기술 지원이 상당히 매력적인거 같습니다.

Tibero Lite는 SQL Lite 같은 파일 기반 DB 시스템이라고 보시면 됩니다. 잘 아는 것처럼 SQL Lite 같은 경우는 php 뿐만 아니라 Google Gears및 Android등에 쓰이고 있죠. 파일 기반의 DB 시스템은 소규모 환경에서 꽤 유용한 거 같습니다.
Tibero Lite가 SQL Lite 등에 비해서 월등해 보인 점은 다양한 파일 형식 지원과 많은 수의 오라클 통계 함수 등 훨씬 많은 질의문 지원 등입니다. 어느 정도 경량화 돼 있느냐와 API 지원등이 관건이겠지만 꽤 괜찮아 보였습니다. 이 건 티맥스에서 오픈 소스화 하여 발전시켜 나가는 것도 좋지 않을까 생각되네요.

그 외에도 많은 제품들을 설명하고 실제 적용 사례도 설명됐습니다.

참, Tibero DBMS의 클러스터 지원은 오라클 쪽과 같은 Shared DB Cluster 방식이라고 하더군요. 몇 가지 Cluster 방식을 설명하면 자신들이 지원하는 방식인 Shared DB 방식에 대해 장점들을 강조했습니다. 나름대로 자부심을 가지고 있는 듯이 느껴졌습니다.

이 후의 향방이 중요하겠고 또한 실제 내부가 어떨지 모르겠지만 국산 DBMS 기술이 다른 누구도 아닌 Oracle을 상대로 해서 발전하고 있다는 점이 놀라웠습니다.

티맥스의 꿈이 어떻게 실현될지 앞으로가 기대됩니다.

썬 개발자 네트워크에서 이메일이 와서 선테크 블로거를 신청했습니다.

http://www.sdnkorea.com/suntechblogger/introduction <- 여기에서 자세한 안내를 볼 수 있습니다.

물론 선물에 눈이 멀어 신청했지만, Java와 MySQL 등과는 뗄래야 뗄 수 없는 관계이기 때문에 앞으로 관련 글들을 올려보려고 합니다.
고군분투!

웹 개발을 하다보면 잘 알 것 같으면서도 잘 모르는 것들이 종종 있습니다. 그 중에서 몇가지를 정리해 봤습니다.

1. Cookie의 크기와 최대 수

3대 규칙
- 쿠키당 4Kb
- 도메인당 20개
- 총 쿠키 개수 300개 (하지만 현재 브라우저들은 더 많이 지원)

Cookie에 대한 내용은 Netscape Communications에서 1997년에 제안한 권고안인
RFC2109:HTTP State Management Mechanism에 정의돼 있습니다.
3대 규칙이 원문에는 모두 at least가 붙어 있습니다. 그러므로, 최소한 이 정도는 되야 한다는 규칙인데 총 쿠기 개수를 제외하고는 그대로 지켜지고 있는 것으로 보입니다.


2. CSS에서 position의 값인 absolute와 relative의 차이점

relative
- 문서의 기본 흐름에 의해 위치한 자신의 현재 위치를 기준으로 위치 지정

absolute
- relative로 지정된 조상 엘리먼트 중 가장 가까운 엘리먼트를 기준으로 위치 지정


3. URL의 최대 길이

RFC 2616, "Hypertext Transfer Protocol - HTTP/1.1"에는 길이에 대한 제한이 명시돼 있지 않습니다. 다만 서버에서 받아들일 수 없는 길이의 요청이 있을 경우 414(Request-URI Too Long) 코드를 반환하도록 규정하고 있습니다.
이러한 규정 하에서 각 서버와 브라우저들은 나름대로 다음과 같이 구현하고 있습니다.

MS IE: 2083 글자 (http://support.microsoft.com/kb/q208427/)
FireFox: 65536 글자 이후부터 주소창에 표시되지 않음
Safari: 적어도 80,000
Opera: 적어도 190,000
Apache: 요청의 개별 필드당 8192byte
IIS: 16,384 글자

이러한 엄청난 확인을 직접 한 사람이 있습니다.
http://www.boutell.com/newfaq/misc/urllength.html <- 여기를 보시면 이 모든 데이터를 위해 직접 실험한 분의 내용을 볼 수 있습니다.


이번에는 3개만 정리해 봤습니다.
다음 번에는 문자셋에 대해서 좀 정리를 해 볼 예정입니다.

역시 저자의 기발함이 돋보이는 책.
이 책은 한 마디로 정리된다,

"베르나르 베르베르 식의 창세기!"

베르나르 베르베르는 그 유명한 개미가 아닌 "뇌"라는 책을 통해서 접하게 되었다. 그리고 (정말 기발한 생각이 가득 담긴)나무를 거쳐 이 책까지 읽게 되었다.
저자의 여러 책들을 읽은 혹자는 이전 내용들의 반복이라고 약간은 혹평을 하기도 하던데 그렇지 않은 내 입장에서는 별 무리없이 재미있게 읽을 수 있었다.
하지만 단편들의 묶음인 나무에서는 그 길이 때문인지 그런 느낌은 전현 느낄 수 없었던 것에 반해 이 책에서도 뇌에서와 같이 2% 조금 못되게 뭔가 약간 모자란듯한 느낌을 받았다.