BLOG.COMBEL.NET

반송 메시지 유형

 

CONNECTION ERROR:

421 4.4.1 IP ADDRESS: Network is busy.

한메일 수신 서버가 응답을 못하는 상황입니다. 잠시 후 다시 접속을 시도해 주시기 바랍니다.

421 4.4.5 IP ADDRESS: Connection refused. Server is busy.

한메일 수신서버에 동시접속 가능한 수를 초과하였습니다. (white IP기준 100개)
접속 수를 줄여 재발송을 시도해 주시기 바랍니다.

554 5.7.1 IP ADDRESS: Connection refused. Your IP address is blocked.

Daum 스팸센터에서 해당IP를 스팸IP로 판단하여 접속을 차단하였습니다.
자세한 사항은 스팸센터로 문의 하시기 바랍니다.

COMMAND ERROR:

421 4.4.0 IP ADDRESS: Closing connection by timeout

시간초과로 한메일 수신 서버 접속이 끊겼습니다. 다시 접속해 주시기 바랍니다.

421 4.7.0 IP ADDRESS: Too many bad commands

사용 불가능한 명령어의 제한 수를 초과하였습니다. 명령어를 확인 후 다시 입력하시기 바랍니다.

421 4.7.0 IP ADDRESS: Too many transactions

한 번 접속 후 접속을 끊지 않고 계속해서 메일을 발송할 경우, 일정양의 메일 수신후 한메일 서버에서 더 이상의 메일수신을 거부합니다. 메일 발송 시, 기존 접속을 끊고 새로운 접속을 맺으셔야 합니다.

500 5.5.0 IP ADDRESS: Command line too long

명령어가 제한길이인 8,192 바이트를 초과하였습니다. 명령어를 확인 후 다시 입력하시기 바랍니다.

500 5.5.2 IP ADDRESS: Command not recognized: UNRECOGNIZED COMMAND

한메일 수신 서버가 이해할 수 없는 명령어 입니다. SMTP 규약에 맞게 수정 후 다시 입력해 주시기 바랍니다.

501 5.5.2 IP ADDRESS: Syntax error in command line: COMMAND LINE

명령어 구문에 오류가 있습니다. SMTP 규약에 맞게 수정 후 다시 입력해 주시기 바랍니다.

501 5.5.4 IP ADDRESS: EHLO requires domain name

EHLO 명령어에 도메인 명이 포함되어 있지 않아 반송되었습니다. 도메인 명을 포함한 명령어를 다시 입력해 주시기 바랍니다.

501 5.5.4 IP ADDRESS: Command argument required

명령어에 필요한 인자값이 없습니다. SMTP 규약에 맞게 수정 후 다시 입력해 주시기 바랍니다.

501 5.5.4 IP ADDRESS: Invalid command argument: ARGUMENT

명령어 중 인자의 포맷이 올바르지 않습니다. SMTP 규약에 수정 다시 입력해 주시기 바랍니다.

502 5.5.1 IP ADDRESS: Command not implemented: UNIMPLEMENTED COMMAND

이 메시지로는 정확한 에러 사항을 파악할 수 없습니다.
telnet으로 한메일 수신 서버에 접속하여 발송하기까지의 로그를 복사하여 보내주시면 문제를 확인해 드리겠습니다.
한메일 수신 서버 아이피 : 222.231.35.29

 

MAIL COMMAND ERROR:

450 4.7.1 IP ADDRESS: Message refused. Your IP address has sent too many mails(MAIL COUNT).

한메일로 전송 가능한 메일 통수를 초과하였습니다. 자세한 사항은 스팸센터로 문의해 주시기 바랍니다.

451 4.4.1 IP ADDRESS: Network is busy(TYPE)

보낸이의 메일주소가 유효한 Daum 사용자인지 확인하던 중, 일시적인 오류가 발생하였습니다. 잠시 후 재전송을 시도해 주십시오.

503 5.5.1 IP ADDRESS: Sender already specified

보낸이의 메일 주소가 이미 정의되어 있습니다. SMTP 규약에 따라 보낸이의 메일주소는 중복해서 정의될 수 없습니다.
명령어를 확인하신 후 다시 발송시도 해주시기 바랍니다.

550 5.1.8 IP ADDRESS: No such user: SENDER ADDRESS

보낸이의 메일 주소가 Daum에 가입되지 않은 아이디입니다. 보낸이 주소를 확인 후, 재 발송해 주시기 바랍니다.

553 5.1.7 IP ADDRESS: Invalid mail address: SENDER ADDRESS

보낸이의 메일 주소가 한메일 수신 서버에서 확인되지 않는 주소입니다. 보낸이 주소를 확인 후, 재발송 해주시기 바랍니다.

 

RCPT COMMAND ERROR:

450 4.5.3 IP ADDRESS: Too many recipients

한메일 수신서버가 한번에 받을수 있는 받는이 수 제한을 초과했습니다. 받는이를 나눠서 메일을 재발송해주십시오.

451 4.2.0 IP ADDRESS: Temporary home error: RECIPIENT ADDRESS

받는이의 한메일 홈서버에 일시적인 장애가 있어서 메일을 수신할 수가 없습니다. 잠시 후 다시 시도해 주시기 바랍니다.

451 4.4.1 IP ADDRESS: Network is busy

받는이의 메일주소가 유효한 Daum 사용자인지 확인하던 중, 일시적인 오류가 발생하였습니다. 잠시 후 재전송을 시도해 주십시오.

503 5.5.1 IP ADDRESS: MAIL command required

받는이의 메일주소를 정의하기 전에 반드시 보낸이의 메일주소를 정의하여야 합니다.
SMTP 규약에 맞게 명령어를 다시 입력해주시기 바랍니다.

550 5.1.1 IP ADDRESS: No such user: RECIPIENT ADDRESS

받는이의 메일주소가 Daum에 가입되지 않은 아이디입니다. 받는이 주소를 확인 후 다시 발송해 주시기 바랍니다.

550 5.2.0 IP ADDRESS: Message refused by the recipient: RECIPIENT ADDRESS

받는이가 보낸이 주소를 ‘수신거부’ 혹은 ‘바로삭제’로 설정하여 메일이 전달될 수 없습니다.

550 5.2.1 IP ADDRESS: Mailbox is inactive: RECIPIENT ADDRESS

받는이가 Daum에 로그인한지 3개월 이상 지나 휴면계정으로 전환된 사용자입니다.
Daum 휴면 사용자는 메일을 수신할 수 없습니다.

552 5.2.2 IP ADDRESS: Mailbox is full: RECIPIENT ADDRESS

받는이의 편지함이 가득 차서 더 이상 메일을 수신할 수 없습니다.
받는이에게 다른 방법으로 연락이 가능하시다면 한메일의 편지함 정리를 요청해주시기 바랍니다.

553 5.1.2 IP ADDRESS: Relaying denied: RECIPIENT ADDRESS

@hanmail.net 또는 @daum.net이 아닌 주소로 메일을 발송하였습니다. 받는이 메일 주소를 확인 후, 다시 발송해 주시기 바랍니다.

553 5.1.3 IP ADDRESS: Invalid mail address: RECIPIENT ADDRESS

받는이의 메일 주소가 정확하지 않습니다. 확인후 재발송 해주시기 바랍니다.

 

DATA COMMAND ERROR:

451 4.4.1 IP ADDRESS: MESSAGE ID Network is busy

한메일 수신서버 네트워크의 일시적인 오류로 인하여 메일이 전달되지 않거나, 저장이 되지 않았습니다.
잠시 후, 발송을 다시 시도해 주시기 바랍니다.

503 5.5.1 IP ADDRESS: MAIL command required

보낸이의 메일주소가 정의되지 않았습니다. 확인 후 다시 명령어를 입력해 주시기 바랍니다.

503 5.5.1 IP ADDRESS: RCPT command required(recipient)

받는이의 메일주소가 정의되지 않았습니다. 1명 이상의 받는이 주소를 포함시켜 다시 발송해 주시기 바랍니다.

552 5.2.3 IP ADDRESS: Message size exceeds the limit(LIMIT)

메일이 수신 제한 용량을 초과하였습니다. (일반 회원:20M, 프리미엄 회원:50M)
사이즈를 줄여 다시 발송해 주시기 바랍니다.

554 5.4.6 IP ADDRESS: Routing loop detected

한메일 수신 서버가 이미 해당 메일을 수신하였습니다. 발송 서버의 루핑이 예상되오니, 확인을 부탁드립니다.

554 5.6.0 IP ADDRESS: Message requires 'From' header

헤더에 보낸이 정보가 없는 경우 수신을 거부합니다. 정확한 보낸이 주소를 포함하여 다시 발송해주시기 바랍니다.

554 5.6.0 IP ADDRESS: Invalid 'From' header: FROM

헤더의 보낸이 정보가 ‘RFC2822 인터넷 메시지 규정’에 맞지 않는 경우 수신을 거부합니다.
RFC 규정을 참고 후, 다시 발송해주시기 바랍니다.

554 5.7.1 IP ADDRESS: Message refused. Your host name(HOST NAME) dosen't match with your IP address.

메일발송 IP 정보와 Hostname 정보가 일치하지 않아 해당 메일 수신을 거부합니다.
발송 서버에 ‘MX레코드’와 ‘리버스 도메인’이 등록되어 있는지 확인해주시기 바랍니다. 2개 모두 정확히 등록되어 있어야 합니다.
도메인 설정이 정확한지 네트워크 담당자에게 문의해주세요.

554 5.7.1 IP ADDRESS: Message refused. Your domain(DOMAIN) has sent too many mails.

해당 도메인에서 너무 많은 메일이 발송되어, 한메일 수신이 원활하지 않습니다. 잠시 후 다시 발송해 주시기 바랍니다.

554 5.7.7 IP ADDRESS: Message not terminated by end with "." on a line by itself

DATA 명령어가 끝나기 전에 클라이언트가 닫혔기 때문에 해당 메일을 전달할수 없습니다.
SMTP 규약에 따라 “.” 명령어를 포함하여 다시 입력해 주시기 바랍니다.

[출처] 반송 메일 메세지 유형|작성자 성공을위한성공을위해

스팸과의 끊임없는 전쟁.. 툴에 의해 무작위의 메일주소로 스팸을 쏴대는 덕에 550 user unkown은 maillog에 수없이 쌓여만 간다.. 이 방법이 구체적인 해결방법이 될지는 모르지만..
iptables를 이용해 25번 포트의 히트수를 체크하여 제한된 값을 넘는 아이피에 대해 차단하는 방법이다.


1시간에 600히트를 넘으면 드랍시켜 버린다. 설정 잘못하면 대략 난감해질 듯..

Memcached에 등록된 Key List를 PHP함수를 이용해 가져오는 방법이다.
필요에 의해 검색해서 스크랩함..


[code php]
<?PHP
$memcache = new Memcache;
$memcache->connect('127.0.0.1', 11211);
$list = array();
$allSlabs = $memcache->getExtendedStats('slabs');
$items = $memcache->getExtendedStats('items');
foreach ($allSlabs as $server => $slabs) {
    foreach ($slabs AS $slabId => $slabMeta) {
        $cdump = $memcache->getExtendedStats('cachedump', (int)$slabId);
        foreach ($cdump AS $server => $entries) {
            if ($entries) {
                foreach ($entries AS $eName => $eData) {
                    $list[$eName] = array(
                        'key' => $eName,
                        'server' => $server,
                        'slabId' => $slabId,
                        'detail' => $eData,
                        'age' => $items[$server]['items'][$slabId]['age'],
                    );
                }
            }
        }
    }
}
print_r($list);
?>
[/code]


* 이 코드는 key list를 제대로 못가져오는 듯 하다. 개수가 적을 때는 상관 없지만 많은 경우 문제가 생기는 듯

언어 옵션(Language Options)

engine = On
Apache 상에서 PHP 의 스크립트 언어 엔진을 유효하게 한다

zend.ze1_compatibility_mode = Off
Zend 엔진 1에 대한 호완 모드 (PHP 4.x)

short_open_tag = Off
<? ?> 태그 허용 여부. 기본적으로 <?PHP, <script>를 사용한다.

asp_tags = Off
ASP 스타일의 <% %> 태그 허용 여부.

precision = 14
부동 소수점을 표시할 때의 유효 자리수를 설정한다.

y2k_compliance = Off
강제적으로 2000년 문제를 대응하게 한다 (대응하고 있지 않는 브라우저의 경우는 문제를 일으킨다).

output_buffering = 4096
출력 버퍼링을 사용하면 PHP의 출력 층에 있어서의 몇 안 되는 지연되는 곳에 바디 부분을 송출한 다음에도 헤더(쿠키 포함)를 송출할 수 있다. 실행 시에 출력 버퍼링용 함수를 호출하므로써 출력 버퍼링을 유효하게 할 수가 있다.
또 이 지시문을 On으로 하면, 모든 파일에 대해 출력 버퍼링이 유효가 된다. 버퍼를 특정의 사이즈에 제한하고 싶은 경우는 이 지시문의 값으로 On 대신에 최대의 바이트수를 설정한다(e.g., output_buffering=4096).

output_handler =
함수의 모든 스크립트의 모든 출력을 리디렉트 시킬 수 있다. 예를 들어, "mb_output_handler"를 output_handler로 설정하면 문자 인코딩을 지정된 인코딩으로 확실하게 바꿀 것이다.
output handler를 설정하면 자동으로 ouput buffering이 활성화된다.
참 고 : 휴대용 스크립를 쓰는 사람들은 이 지시문에 의존하지 말아야 한다. 대신 ob_start()를 사용하여 ouput handler를 설정하면 된다. 스크립트가 하는 일을 알지 못한다면 이 지시문의 사용은 문제가 발생할 수 있다.
참고 : "mb_ouput_handler"와 "ob_iconv_handler"를 동시에 사용할 수 없고, "ob_gzhandler"와 "zlib.output_compression"은 동시에 사용할 수 없다.
참고 : 'On'으로 설정했다면 output_handler는 비어있어야 한다!!! 대신에 zlib.ouput_handler을 사용해야 한다.

zlib.output_compression = Off
zlib.output_compression_level = -1
zlib library를 사용하여 출력을 압축한다.
이 옵션의 유효한 값은 'off', 'on', 또는 압축에 사용되는 특정 버퍼 사이즈(기본값 4KB)이다.
참고 : 결과물의 사이즈는 압축의 특성에 따라 달라진다. PHP 출력양은 압축 결과에 따라 몇 백바이트이다. 큰 사이즈에서 보다 나은 성능을 원한다면 ouput_burffering의 활성화하면 된다.
참고 : 기본 output_handler 대신, 또는 기타 출력이 손상될 경우 zlib.output_handler를 사용하기 바란다.

zlib.output_handler =
zlib.output_compression을 활성화 했다면 output handler를 추가로 지정할 수 없다. 이 설정은 ouput_handler와 비슷하지만 다른 명령이다.

implicit_flush = Off
implicit_flush 를 On 으로 설정하면 출력 층에 대해 각 출력 블록마다 자동적으로 플래시를 하게 된다. 이것은 즉 print(), echo() 및 각 HTML 블록의 뒤에 PHP 함수의 flush()를 부르는 것과 같은 내용이다. 이 옵션을 유효하게 하면 퍼포먼스의 문제와 밀접하게 관계되므로 일반적으로는 디버그 용도만의 사용에 한정해야 할 것이다.

allow_call_time_pass_reference = Off
함수 사용시에 변수를 강제적으로 참조 하는 것을 금지한다. 이것을 PHP4 스타일로 실시하기 위해서는 함수 정의 시에 관련하는 인수를 참조 하도록 한다.

safe_mode = Off
safe_mode_gid = Off
세이프 모드의 디폴트에서는 파일을 오픈할 때에 UID 를 비교한다.
이 제한을 풀고 싶은 경우는 safe_mode_gid 를 On 로 한다.

safe_mode_include_dir =
safe_mode 가 On 의 경우 파일을 이 디렉토리 및 그 하위로부터 include 하는 경우는 UID/GID 의 체크가 스킵 된다(이러한 디렉토리는 include_path 에 포함되도록 하거나 또는 include 시에 절대 경로를 사용해야 한다).

safe_mode_exec_dir =
safe_mode 가 On 의 경우 exec 관련의 함수를 통해 실행할 수 있는 권한을 safe_mode_exec_dir 에 있는 실행 파일만으로 설정 한다.

open_basedir =
open_basedir 이 설정 되었을 경우 모든 파일 조작은 해당 디렉토리 및 그 하위 디렉토리로 제한된다.


safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH

disable_functions =
이 지시문에서는 특정의 함수를 시큐리티적인 이유로써 사용할 수 없게 할 수 있다.
이것은 인수로서 fopen,fwrite 의 , 단락의 리스트로 설정한다.
이것은 safe_mode의 On/Off 에 관계없이 항상 유효하게 된다.

highlight.string = #CC0000
highlight.comment = #FF9900
highlight.keyword = #006600
highlight.bg = #FFFFFF
highlight.default = #0000CC
highlight.html = #000000
문법의 하이라이트 표시할 때의 색의 지정.

expose_php = On
PHP 가 해당 서버에 인스톨 되고 사용되고 있다는 내용을 알려주거나 알려주지 않도록 설정한다.


자원 제한(Resource Limitation)

max_execution_time = 30
각 스크립트의 최대 실행 시간을 초단위
memory_limit = 8M
스크립트 마다의 최대 메모리 소비량


에러 핸들링과 로그(Error Handling & Log)

error_reporting 는 비트 필드에서, 지정한 수치까지의 에러가 보고된다.
E_ALL - 모든 에러와 경고
E_ERROR - 치명적인 실행시 에러
E_WARNING - 실행시의 경고(치명적이지 않는 것)
E_PARSE - 컴파일시의 퍼스 에러
E_NOTICE - 실행시의 공지 사항(이러한 경고는 작성한 코드의 버그에 기인하는 것이 많지만, 고의의 경우도 있다(즉, 초기화되어 있지 않은 변수를 사용하거나 자동적으로 공문자열에 초기화된다고 하는 사실에 의존했을 경우).
E_CORE_ERROR - PHP 의 초기화시에 발생한 치명적 에러
E_CORE_WARNING - PHP 의 초기화시에 발생한 치명적이지 않은 경고
E_COMPILE_ERROR - 치명적인 컴파일시의 에러
E_COMPILE_WARNING - 컴파일시의 경고(치명적이지 않는 것)
E_USER_ERROR - 유저가 생성한 에러 메세지
E_USER_WARNING - 유저가 생성한 경고 메세지
E_USER_NOTICE - 유저가 생성한 통지 메세지

사용예:
error_reporting = E_ALL & ~E_NOTICE
통지를 제외한 모든 에러를 표시한다

error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR
에러만을 표시한다

error_reporting = E_ALL
모든 에러와 경고를 표시한다.

display_errors = Off
에러를 표시한다. 실제 운영 환경에서는 이 기능은 오프로 해 두고 error_log 기능을 사용하는 것을 추천한다. 이것은 실제 운영 환경에서 display_errors 를 유효하게 해 버리면 당신의 웹사이트의 파일 정보나 데이타베이스 schema등의 시큐리티 정보를 접속 사용자에게 표출 될 수 있기 때문이다.

display_startup_errors = Off
display_errors 가 On 의 경우여도 PHP 의 시작시의 에러는 표시되지 않는다.
디버그시를 제외해 display_startup_errors 는 Off 인 채로 설정해 두는 것을 추천한다.

log_errors = On
로그 파일에 에러 로그를 기록 한다. 실제 운영 환경에서는 에러 표시 기능 대신에 에러 로그 기능을 사용하는 것을 추천한다.

track_errors = Off
마지막 에러/경고 메세지를 $php_errormsg 에 저장한다.

html_errors = Off
에러 메세지중에 HTML 태그를 넣지 않게 한다.

error_prepend_string = ""
에러 메세지의 전에 출력하는 캐릭터 라인

error_append_string = ""
에러 메세지의 뒤에 출력하는 캐릭터 라인

error_log = filename
지정된 파일에 에러를 기록한다

;error_log = syslog
syslog 에 에러를 기록한다. (NT 에서는 이벤트 로그, Windows 95 에서는 무효)

warn_plus_overloading = Off
캐릭터 라인에 + 연산자가 사용되고 있으면 경고


데이터 핸들링(Data Handling)

주의 - track_vars 는 PHP 4.0.3 이상에서는 항상 유효하다.

;arg_separator.output = "&"

arg_separator.input = ";&"
입력 URL을 파싱해 변수로 하기 위해서 PHP로 사용되는 단락 문자의 리스트.

variables_order = "GPCS"
이 지시문은 PHP 가 등록하는 GET, POST, Cookie 환경 변수
(순서에 G, P, C, E, S, 자주 EGPCS 나 GPC 등으로 불린다)에 있어서의 순서를 규정한다.
등록은 왼쪽에서 오른쪽을 향해 행해져 새로운 값은 낡은 값을 덮어 쓴다.

register_globals = Off
EGPCS 변수를 글로벌 변수로서 등록할지 말지를 설정한다.
register_globals 를 Off 한 채로도 움직이는 PHP스크립트를 쓰도록 평소부터 노력해 두면 좋다.
코드의 불편함을 그다지 자주 생각하지 않은 채 변수를 글로벌로서 액세스를 가능하게 하면 잠재적으로 세큐리티를 발생시킬 수 있다.

register_argc_argv = Off
argc 및 argv 변수(GET 의 정보에 포함될 가능성이 있다.)를 선언할지 말지를 규정한다.
이러한 변수를 사용하지 않으면 퍼포먼스를 개선한다.

post_max_size = 8M
PHP 가 받아들이는 일을 할 수 있는 POST 데이터의 최대 사이즈

gpc_order = "GPC"
이 지시문은 추천 되지 않는다. 대신에 variables_order 를 사용하라.

magic_quotes_gpc = Off
GET/POST/Cookie 의 입력 데이터에 관해서 특수 문자를 이스케이프

magic_quotes_runtime = Off
실행시에 생성된 데이터(즉 SQL 로부터의 데이터, exec()로부터 등)에 관한 특수 문자 이스케이프

magic_quotes_sybase = Off
sybase 스타일의 특수 문자 이스케이프( '를 ' 대신에 '' 로 변환한다.)

auto_prepend_file =
auto_append_file =
PHP 문서의 전후에 파일을 자동적으로 추가한다.

default_mimetype = "text/html"
;default_charset = "iso-8859-1"
PHP 4.0b4 이상에서는 Content-type: 헤더로 항상 문자 인코딩을 출력한다.
charset 의 송신을 시키고 싶지 않으면, 설정값을 비운다. 디폴트는 text/html 이다.

;always_populate_raw_post_data = On
항상 $HTTP_RAW_POST_DATA 변수를 발생시킨다.


경로와 디렉토리(Path & Directory)

;include_path = ". :/php/includes"
UNIX: "/패스1:/패스 2"

;include_path = ". ;c:phpincludes"
Windows: "패스1;패스 2"

doc_root =
PHP 페이지의 root 디렉토리

user_dir =
/~username 로 액세스 되었을 경우에 PHP 가 스크립트를 실행한다

extension_dir = . /
확장 모듈이 있는 디렉토리

enable_dl = On
dl() 함수를 유효하게 할지를 설정한다.
dl() 함수는 IIS 나 Zeus 라고 하는 멀티 thread 서버에서는 올바르게 동작 하지 않고 자동적으로 무효가 된다.


파일 업로드(File Upload)

file_uploads = On
파일의 업로드를 허가할지를 설정한다.

;upload_tmp_dir =
HTTP 로 파일을 업 로드할 때의 임시 작업 디렉토리
(지정되지 않는 경우는 시스템의 디폴트(TEMP 디렉토리)가 사용된다)

upload_max_filesize = 2M
업 로드하려는 파일의 최대 사이즈


fopen 설정(Fopen)

allow_url_fopen = On
URL(http:// 나 ftp:// )을 파일로서 취급할지를 결정한다

;from="john@doe.com"
anonymous ftp 의 패스워드 지정(당신의 메일 주소)


동적 확장 기능(Dynamic Extension)

extension=modulename.extension
자동적으로 로드 되는 확장 기능을 사용하고 싶은 경우 지정한다.
지정하는 것은 모듈명에만 해야 한다. 여기에서는 디렉토리명을 지정할 필요는 없다.
확장 기능의 장소는 extension_dir 디렉토리로 지정한다.

Cache-Control 메커니즘

HTTP/1.1 의 기본적인 캐시 메커니즘(서버설정 만기시간 및 검증자)은 캐시에 내장된 지시자입니다. 때에 따라서는 서버나 클라이언트에게 HTTP 캐시를 위해 명시된 지시자 제공할 필요가 있습니다. Cache-Control 헤더를 이 목적으로 사용합니다.

Cache-Control 헤더는 클라이언트나 서버가 요구나 응답의 다양한 지시자를 전달할 수 있도록 합니다. 이 지시자는 대개의 경우 기본 캐시 알고리즘을 무시합니다. 보편적인 원칙으로 만약 헤더값 사이에 분명한 충돌이 있으면 가장 엄격한 - 가장 의미투명한 동작을 할 수 있는 - 해석을 하여야 합니다.

원서버가 응답할 수 있는 캐시 지시자

Cache-Control 일반 헤더 필드는 요구/응답 체인에 따라 모든 캐시 메커니즘이 반드시 따라야 하는 지시자를 표시하는데 사용합니다. 여기서는 응답에서 사용되는 캐시지시자(cache-directive)에 대하여 알아봅니다. 요구에서 사용되는 캐시 지시자에 대하여는 관련 문서를 참조바랍니다.


캐시 제한자(public, private, no-cache)

Cache-Control 응답 지시자 중에서 public, private, no-cache는 원서버가 응답의 캐시 가능성을 무시할 수 있도록 합니다.

• public
  보통은 비공유 캐시 내에서만 캐시할 수 있거나(private) 캐시할 수 없지만(no-cache) public은 모든 공유/비공유 캐시에서 응답을 캐시할 수 있도록 지정합니다.
  
  
• private
  응답 메시지의 전체 또는 일부분을 단일 사용자만이 사용하며 절대로 공유 캐시(shared cache)에 의해 캐시해서는 안됨을 표시합니다. 원서버가 응답의 특정 부분이 단일 사용자만을 위한 것이며 다른 사용자의 요구에 대한 유효한 응답은 아니라는 것을 명시할 수 있도록 합니다.
  
  
• no-cache
  응답의 전체 또는 부분을 캐시해서는 안된다는 것을 나타냅니다. 원서버가 클라이언트 요구에 낡은 응답(stale response)을 리턴하도록 설정된 캐시에 의해서도 캐시를 하지 못하도록 합니다. 대부분의 HTTP/1.0 캐시는 이 지침을 인지하지 못하거나 따르지 않을 것입니다.
  

캐시 저장 금지(no-store)

no-store 지시자의 목적은 부주의하게 민감한 정보를 백업테이프와 같은 곳에 보유하거나 배포하는 것을 방지하는 것입니다. no-store 지시자는 요구/응답 모두에 발송할 수 있습니다. 요구에 포함하여 발송하게 되면 캐시는 요구의 어떤 부분 또는 이 요구에 대한 어떠한 응답도 캐시해서는 안됩니다. 응답에 발송하게 되면 캐시는 이 응답의 어떤 부분 또는 응답을 이끌어 낸 요구를 저장해서는 안됩니다. 이 지시자는 비공유 및 공유 캐시에 모두 적용됩니다.


만기일 메커니즘의 변경(max-age)

원서버는 expires 헤더를 이용하여 엔터티의 만기시간을 명시합니다. 대안으로 응답에 max-age 지시자를 사용하여 표시할 수도 있습니다.

응 답에 expires 헤더 및 max-age 지시자가 모두 포함되어 있으면 max-age 지시자는 expires 헤더가 더 제한적이라 할지라도 이를 무시합니다. 이 원칙은 원서버가 HTTP/1.0 캐시에 HTTP/1.1 캐시(또는 이후 버전)보다 긴 만기시간을 응답에 부여할 수 있도록 합니다. HTTP/1.0 캐시가 동기화되지 않은(desynchronized) 시계때문에 부적절하게 경과시간이나 만기시간을 계산했을 때 유용합니다.

캐시된 사본을 원서버가 직접적으로 검증하도록 강요하여 응답을 명확히 하려면 아래와 같이 max-age 값을 0으로 지정합니다.



캐시의 재검증(must-revalidate)

규약은 원서버가 계속되는 캐시 사용에 대한 캐시 엔트리 검증을 요구할 수 있는 메커니즘을 포함하고 있습니다. must-revalidate 지시자가 캐시가 수신한 응답에 포함되어 있고 캐시가 계속되는 요구에 응답하기에는 낡아진 이후에 캐시는 먼저 원서버에 이를 재검증하기 전에는 엔트리를 사용해서는 안됩니다.

must-revalidate 지시자는 특정 규약 기능의 안정된 운영을 위해서 필요합니다. 어떠한 경우이든 HTTP/1.1 캐시는 must-revalidate 지시자를 반드시 따라야 합니다.


비변경 지시어(no-transform)

구현된 중간 캐시(프록시)에서 특정 엔터티 본문의 media type을 변환하는 것이 유용할 수 있습니다. 예를 들어 프록시는 캐시 공간을 절약하거나 느린 링크 상의 트래픽 양을 줄이기 위해 이미지의 포맷을 변환할 수 있습니다. 그러나 특정 종류의 애플리케이션에 사용할 엔터티 본문에 이러한 변환을 적용했을 때 심각한 운영 문제가 발생하게 됩니다. 예를 들어 의료 이미지 처리, 과학적 자료 분석 및 end-to-end 인증에 사용되는 애플리케이션은 모두 원서버의 엔터티 본문와 비트 단위까지 동일한 엔터티 본문을 수신하는 방식에 의존하고 있습니다.

따 라서 응답이 no-transform 지시자를 포함하고 있으면 중간 캐시나 프록시는 Content-Encoding, Content-Length, Content-Range, Content-Type와 같은 헤더 필드 값을 절대로 변경해서는 안됩니다.


캐시 제어 확장(cache-extension)

Cache-Control 헤더 필드는 하나 또는 그 이상의 cache-extension 토큰을 이용하여 각각 선택적으로 부여된 값을 가지고 확장할 수 있습니다. 정보 확장(informational extensions - 캐시 동작에 변화를 요구하지 않는)은 다른 지시자의 의미를 변화시키지 않고도 추가할 수 있습니다 동작 확장(behavioral extensions)은 캐시 지시자의 기본 베이스에 대한 변경자의 역할을 수행하도록 디자인 되었습니다. 새로운 지시자 및 표준 지시자 모두가 제공되었을 때 새로운 지시자를 이해하지 못하는 애플리케이션은 표준 지시자가 명시한 동작에 기본적으로 따르며 새로운 지시자를 이해하는 애플리케이션은 이를 표준 지시자와 관련된 필요 조건의 변경으로 인식합니다. 이러한 방식으로 지시자를 기본 규약에 대한 변경을 요구하지 않고도 확장할 수 있습니다.

인 지할 수 없는 캐시지시자는 무시해야 합니다. HTTP/1.1 캐시가 인지하지 못하는 모든 캐시지시자는 캐시가 확장을 이해하지 못하더라도 최소한도로 이러한 캐시 동작이 정학한 것으로 유지되도록 표준 지시자(또는 응답의 캐시 제한자)와 결합되어 있다고 가정합니다.


IE5에서의 캐시 제어 확장

post-check, pre-check 지시자는 익스플로러 5.0부터 제공되기 시작한 캐시 제어 메커니즘입니다. 이 헤더는 이전 버전의 익스플로러나 다른 브라우저에서는 무시됩니다. 이 2개의 헤더에 의해 문서는 캐시로부터 가져오기 때문에 문서를 빠르게 표시할 수 있습니다. 캐시는 웹서버의 최신의 문서를 기초로 갱신되므로, 다음에 사용자가 이 페이지를 방문헸을 때에는, 새로이 갱신된 문서가 표시됩니다.

post-check 및 pre-check에 대한 상세한 정보는 http://msdn.microsoft.com/workshop/aut ··· tips.asp를 참조하세요.

• post-check
  post -check에 설정된 시간(초)이 지나고 나서부터는 사용자에게 캐시문서를 보낸 후 엔터티가 신선한 지 확인합니다. 문서를 보낸 후(post)에 엔터티가 신선한 지 확인하는 고로 post-check라고 합니다. 이와 같은 이유로 인하여 금번에 받은 문서는 낡은 문서일 수 있습니다. 그러나 다음 방문 때는 새로이 갱신된 캐시문서를 분명히 보게 됩니다.
  
  
• pre-check
  pre-check에 설정된 시간(초)이 지나고 나서부터는 엔터티가 신선한 지 먼저 확인한 후 사용자에게 문서를 보냅니다. 문서를 사용자에게 보내기 전(pre)에 엔터티가 신선한 지 확인하는 고로 pre-check라고 합니다.
  

post-check 및 pre-check에 의한 캐시 동작

브 라우저가 캐시에 있는 문서를 가져오도록 요구할 때, HTTP 응답 헤더로 서버에서 클라이언트로 보내지는 캐시 엔트리에 캐시 제어 확장(cache-control extensions)가 포함되어 있으면, 브라우저는 서버로부터 가장 최신의 자료를 가져올 시기를 결정하기 위해 캐시 제어 확장과 다음 로직을 이용하게 됩니다.

• post-check 구간을 아직 지나지 않았다면, 간단하게 캐시로 부터 해당 페이지를 검색합니다.
  
  
• 마지막 요구가 있은 후 경과 시간이 post-check와 pre-check 구간 사이에 있다면 캐시로부터 해당 페이지를 보여주고, 갱신된 페이지를 가져와서 캐시에 저장합니다.
  
  
• 사용자가 해당 페이지를 재요구한 시간이 pre-check 구간을 지났다면, 우선 HTTP 서버에게 브라우저가 해당 페이지를 마지막으로 요구한 이래로 수정되었는지 확인합니다. 해당 페이지가 수정되었다면 가져와서 갱신된 페이지를 보여줍니다.
  

Refresh 버튼(F5 키를 포함하여)은 서버에게 항상 if-modified-since 요구를 보내기 때문에 위의 로직에 따라 동작하지는 않을 것입니다. 하이퍼링크(hyperlink)는 위의 로직에 따라 동작합니다.


IE5의 캐시 동작

post-check 및 pre-check 지시자를 지정하게 되면 검색 대상이 되고 있는 문서는 다음과 같은 순서로 캐시가 처리됩니다.

첫째, 사용자가 페이지를 처음으로 방문하면, 문서는 웹서버로부터 취득되어 캐시에 저장됩니다.

둘째, 사용자가 페이지를 2번째에 방문하면, 문서는 캐시로부터 표시되며, 캐시 내의 데이터는 웹서버를 기초로 갱신됩니다.

이후에 문서는 캐시로부터 취득되므로, 페이지는 단시간에 로드되어 그 후로 캐시가 서버의 문서를 기초로 갱신됩니다.

post-check, pre-check에 의한 캐시 제어 구조는 항상 변화를 계속하고 있는 주식 정보 등의 데이터에는 적합하지 않습니다만, 가끔 변경되는 따라서 매회 갱신할 필요가 없는 문서의 경우에는 잘 동작합니다. 예를 들어, MSN.com 사이트의 네비게이션 유저 인터페이스는 자주 바뀌지 않기 때문에, post-check 및 pre-check 설정으로 마크되어 있습니다.

다음은 각각의 캐시 제어 메커니즘에 적합한 조건을 나타내었습니다.

• 자주 갱신되는 컨텐트
  주식정보 : 컨텐츠를 즉시 기한 마감으로 한다. (예: Expires: 0)
  
  
• 가끔 갱신되는 컨텐트
  사이트 네비게이션 : post-check와 pre-check를 사용한다. (예: Cache-Control: post-check=50, pre-check=100)
  
  
• 비교적 정적인 컨텐트
  회사로고 : 유효기간을 먼 미래에 설정한다. (예: Expires: Thu, 01 Dec 2002 16:00:00 GMT)

Expires 헤더 필드

Expires 엔터티 헤더 필드에 지정된 시간이 지나면 응답이 낡았다고 간주해야 하는 날짜를 제공합니다. 캐시(프록시 캐시 또는 사용자 에이전트 캐시)는 대개 먼저 원서버(또는 엔터티의 신선한 복사본을 가지고 있는 중간 캐시)가 검증하지 않는 한 낡은 캐시 엔트리를 리턴하지 않습니다.

Expires 필드가 존재한다는 것이 그 시간 이전 또는 이후에 원래의 자원이 변경되거나 사라진다는 것을 의미하지는 않습니다.

Expires 필드는 RFC1123-date 포맷으로 작성된 절대 날짜와 시간입니다.


앞에서도 언급하였듯이 응답이 max-age 지시자를 포함한 Cache-Control 필드를 포함하고 있으면 expires 필드는 무시됩니다.

HTTP/1.1 클라이언트와 캐시는 반드시 다른 유효하지 않는 날짜 포맷을, 특히 "0" 값을 포함하고 있는 날짜 포맷을 지나간 날짜로 취급해야 합니다.(예를 들면 "벌써 만료된(already expired)"으로)

응답을 "벌써 만료된(already expired)" 것으로 표시하기 위해서 원서버는 expires 날짜를 Date 헤더 필드와 동일한 것으로 사용해야 합니다.

응 답을 "결코 만료되지 않는(never expires)" 것으로 표시하기 위해서 원서버는 expires 날짜를 대략 응답이 발송된 후 시점부터 1년 후를 지정합니다. HTTP/1.1 서버는 향후 1년 이상된 expires 날짜를 발송하지 말아야 합니다.

기본적으로 캐시할 수 없는 응답에 미래의 특정 시간의 시간값과 함께 expires 헤더 필드가 존재하면 Cache-Control 헤더 필드가 다른 식으로 표시하지 않는 한 응답을 캐시할 수 있다는 것을 표시합니다.


Last-Modified 헤더 필드

Last-Modified 엔터티 헤더 필드는 원서버가 변형자(variant)가 마지막으로 변경되었다고 믿는 날짜와 시간을 표시합니다.


원서버는 절대 서버의 메시지 발생 시간보다 늦은 Last-Modified 날짜를 발송해서는 안됩니다. 이처럼 자원의 최근 변경이 미래의 특정 시간을 표시하는 경우 서버는 그 날짜를 메시지 발생 날짜로 대체해야 합니다.

기본 서버는 엔터티의 Last-Modified 값을 응답의 Date 값을 생성한 시간과 가능한 한 가까운 것을 얻어야 합니다. 이것은 수신측이 특히 엔터티가 응답이 생성된 시간에 가깝게 변경되었을 때 정확하게 엔터티의 변경 시간을 평가할 수 있도록 합니다.

HTTP/1.1 서버는 가능할 때 마다 반드시 Last-Modified를 발송해야 합니다.


Pragma 헤더 필드

Pragma 일반 헤더 필드는 요구/응답 체인을 따라 어떤 수신측에도 적용할 수 있는 구현 방식에 한정된 지시자(implementation-specfic)를 포함하는데 사용합니다.


no-cache 지시자는 요구 메시지에 존재하면 애플리케이션은 요구되고 있는 것으 캐시 사본을 가지고 있다 하더라도 요구를 원서버에 전달해야 합니다. 이 Pragma 지시자는 no-cache 캐시지시자와 동일한 의미를 가지며 여기서는 HTTP/1.0과의 호환성 유지를 위해 규정하였습니다. 클라이언트는 no-cache 요구가 HTTP/1.1을 따르지 않는 것으로 알려진 서버로 전달되었을 때 두 헤더 필드를 모두 포함해야 합니다.

HTTP/1.0 에서 캐시 등을 제어하기 위해 사용되었으나 HTTP/1.1에서는 사용되지 않습니다. 따라서 HTTP/1.1 클라이언트는 Pragma 요구 헤더를 발송해서는 안됩니다. HTTP/1.1 캐시는 "Pragma: no-cache"를 클라이언트가 "Cache-Control: no-cache"를 발송한 것처럼 취급해야 합니다.