HTML 테그 정리

Cascading Style Sheets, level 1

CSS1 카스케이딩 스타일쉬트 규격

번역문

W3C 추천안

1996년 12월 17일, 1999년 1월 11일 수정

이 버전은 REC-CSS1-19990111

이 규격의 상태

이 규격은 W3C의 추천안이다. 이는 영문 W3C (http://www.w3.org/) 멤버들에 의하여 점검 되었고, 이 규격이 사용하는데 적당하다는 일반적으로 공감대가 형성되었다. 이는 안정적 문서로서 조회하고 다른 문서에서 인용할 수 있다. W3C는 이 추천안 발전을 널리 보급하도록 장려한다.

현재 W3C의 추천안들의 목록과 다른 기술적 문서들을 영문 http://www.w3.org/TR/에서 볼 수 있다.

이 규격은 당초 1996년 12월 17일 제시된 것으로 부터 개정된 버전이다.
당초의 버전으로부터의 개정 내용은 목록 영문 부록 F에 있다.
이 규격의 알려진 오류는
영문 http://www.w3.org/Style/CSS/Errata/REC-CSS1-19990111-errata에 있다.

요약

이 규격(CSS1)은 Cascading Style Sheet 기능의 level 1을 정의한다. CSS1은 제작자들과 문서를 보는 리더들이 스타일(예를 들어 글꼴, 색상과 간격 주기)을 HTML 문서들에 추가할 수 있도록 하는 단순한 스타일쉬트 기능이다. CSS1 언어는 일반적인 컴퓨터(desktop)에서 문서 작성 용어로, 인간이 읽고, 쓰고, 표현할 수 있는 것이다.

CSS의 하나의 기초적인 능력은 style sheets cascade이다.; 제작자들은 선호하는 스타일쉬트를 첨부할 수 있으며, 리더는 장애자등을 위하여 그가 원하는 스타일쉬트로 조정할 수 있다. 이 규격에는 다른 스타일쉬트 간의 충돌을 해결하는 규칙이 정의되어 있다.

이 추천안 W3C의 영문 Style Sheets 분야 활동의 결과물이다.

[1] 스타일쉬트에 대한 배경 정보를 참조하라.

목차

요약       용어

1           기본 개념
1.1         HTML 문서에 포함
1.2         구룹으로 묶기
1.3         전달(inherit)
1.4         선택자(selector)로서 클래스(class)
1.5         선택자(selector)로서 ID
1.6         복합 선택자(contextual selector)
1.7         코멘트(Comment)
2           가상 클래스(class)와 가상 엘레멘트
2.1         앤커(anchor) 가상 클래스(class)
2.2         인쇄(typographical) 가상 엘레멘트들
2.3         첫줄('first-line') 가상 엘레멘트
2.4         첫글자('first-letter') 가상 엘레멘트
2.5         선택자(selector) 안의 가상 엘레멘트
2.6         복수 가상 엘레멘트
3           카스케이드(cascade)
3.1         중요('important')
3.2         카스케이딩 순서
4           양식화(formatting) 모델
4.1         블럭레벨(block-level) 엘레멘트
4.1.1      수직 양식화
4.1.2      수평 양식화
4.1.3      목록(List-item) 엘레멘트들
4.1.4      유동(floating) 엘레멘트들
4.2         인라인(inline) 엘레멘트들
4.3         대체된(replaced) 엘레멘트들
4.4         줄의 높이
4.5         화면
4.6         'BR' 엘레멘트들
5            CSS1 속성들
5.1         속성값에 대한 주기
5.2         글자(font) 속성들
5.2.1       글자(font) 맞추기
5.2.2       글꼴들('font-family')
5.2.3       글꼴 스타일('font-style')
5.2.4       글꼴 변화('font-variant')
5.2.5       글꼴 굵기('font-weight')
5.2.6       글꼴 크기('font-size')
5.2.7       글꼴('font')
5.3          색상(color)과 배경(background) 속성
5.3.1       색상('color')
5.3.2        배경색('background-color')
5.3.3        배경 이미지('background-image')
5.3.4        배경 반복('background-repeat')
5.3.5        배경 첨부('background-attachment')
5.3.6        배경 위치('background-position')
5.3.7        배경('background')
5.4          텍스트(text) 속성들
5.4.1        단어 간격('word-spacing')
5.4.2        글자 간격('letter-spacing')
5.4.3        텍스트 장식('text-decoration')
5.4.4        수직 정렬('vertical-align')
5.4.5        텍스트 변환('text-transform')
5.4.6        텍스트 정렬('text-align')
5.4.7        텍스트 들여쓰기('text-indent')
5.4.8        줄높이('line-height')
5.5           박스(box) 속성들
5.5.1         위쪽 마진('margin-top')
5.5.2         오른쪽 마진('margin-right')
5.5.3         아래쪽 마진('margin-bottom')
5.5.4         왼쪽 마진('margin-left')
5.5.5         마진('margin')
5.5.6         위쪽 패딩('padding-top')
5.5.7         오른쪽 패딩('padding-right')
5.5.8         아래쪽 패딩('padding-bottom')
5.5.9         왼쪽 패딩('padding-left')
5.5.10         패딩('padding')
5.5.11         위쪽 테두리 두께('border-top-width')
5.5.12         오른쪽 테두리 두께('border-right-width')
5.5.13         아래쪽 테두리 두께('border-bottom-width')
5.5.14         왼쪽 테두리 두께('border-left-width')
5.5.15         테두리 두께('border-width')
5.5.16         테두리 색상('border-color')
5.5.17         테두리 스타일('border-style')
5.5.18         위쪽 테두리('border-top')
5.5.19         오른쪽 테두리('border-right')
5.5.20         아래쪽 테두리('border-bottom')
5.5.21         왼쪽 테두리('border-left')
5.5.22         테두리('border')
5.5.23         너비('width')
5.5.24         높이('height')
5.5.25         유동('float')
5.5.26         'clear'
5.6            속성들의 분류
5.6.1         'display'
5.6.2         공백('white-space')
5.6.3         목록 스타일 타입('list-style-type')
5.6.4         목록 스타일 이미지('list-style-image')
5.6.5         목록 스타일 위치('list-style-position')
5.6.6         목록 스타일('list-style')
6              단위(unit)들
6.1           길이 단위
6.2           백분율 단위(percentage unit)들
6.3           색상 단위(color unit)들
6.4           URL
7             CSS1에 부합
7.1           향 후 버전에 부합한 처리(parsing)
8             참고
9             문서를 구성한 인사들

부록 A: HTML 2.0을 위한 견본 스타일쉬트
부록 B: CSS1 문법
부록 C: 엔코딩(encoding)
부록 D: 감마(gamma) 수정
부록 E: CSS1의 적용성과 확장성
부록 F: 1996년 12월 17일 버전으로 부터의 변경들

용어

애트리뷰트

HTML 애트리뷰트

제작자

HTML 문서의 제작자

블럭레벨(block-level) 엘레멘트

이전과 이후에 줄바꿈이 일어난 부분의 한 엘레멘트(예를 들어 HTML의 'H1')

화면

문서들이 표현되는 사용도구의 부분

하위(child) 엘레멘트

SGML 용어[5]에서 하나의 하위 엘레멘트

복합 선택자(contextual selector)

해당하는 엘레멘트들 문서 구조에서의 위치에 기초한 선택자(selector). 하나의 복합 선택자(contextual selector)는 여러개의 단순한 선택자들(selectors)로 구성된다. 예를 들어, 'H1.initial B'의 복합 선택자(contextual selector)는 'H1.initial'과 'B' 두개의 단순한 선택자들(selectors)로 구성되어 있다.

CSS

캐스케이딩 스타일쉬트(Cascading Style Sheet)

CSS1

캐스케이딩 스타일쉬트(Cascading Style Sheet), level 1. 이 규격은 단순히 웹에서 스타일쉬트의 기능을 설명하는 CSS1을 정의한다.

CSS1 발전된 기능

이 규격에서 기술된 기능이지만, CSS1 핵심 기능으로 표시되지 않았다.

CSS1 핵심 기능

모든 CSS1 규격에 맞는 사용도구들에 필요한 CSS1 부분이다.

CSS1 처리자(parser)

CSS1 스타일쉬트를 읽는 사용도구

선언

속성(예를 들어 글꼴 크기('font-size'))과 이에 상응하는 값(예를 들어 '12pt')

설계자

스타일쉬트 설계자

문서

HTML 문서

엘레멘트

HTML 엘레멘트

엘레멘트 타입(type)

SGML 용어[5]에서 하나의 기본 인식자(generic identifier)

가상(fictional) 태그 순서

가상 클래스(class)와 가상 엘레멘트 행위를 기술하는 도구

글자 크기(font size)

글자의 크기를 지정한다. 전형적으로 그 글자 크기는 대략 아래로 튀어나온것(예:g)을 표함한 가장 낮은 글자의 바닥으로 부터 가장 키큰 글자의 위로 튀어나온 부분(예:h), 부호(예:Ü)를 포함한 맨위까지의 거리와 같다.

HTML

SGML의 하나인 Hypertext Markup Language: HTML 4 규격 번역문.

HTML 표현(extension)

사용도구에 의해 소개된 마크업(Markup)으로 대부분 보는 표현을 지원한다. "FONT", "CENTER"와 "BLINK" 엘레멘트과 "BGCOLOR" 애트리뷰트등은 HTML 표현의 예제들이다. CSS의 하나의 목표는 HTML 표현(extension)의 대용 기능을 주는 것이다.

인라인(inline) 엘레멘트

이전과 이후에 줄바꿈하지 않는 엘레멘트(예를 들어 HTML의 'STRONG')

원래의 규격(intrinsic dimension)

그 엘레멘트 자체에 의하여 지정된 너비(width)와 높이(height), 주위의 것을 포함하지 않는다. 이 규격에서 모든 대체된(replaced) 엘레멘트들 -- 그리고 대체된(replaced) 엘레멘트들 만 -- 원래의 규격(intrinsic dimension)들을 갖는 것으로 가정한다.

모체(parent) 엘레멘트

SGML 용어[5]에서 하나의 상위 엘레멘트

가상 엘레멘트

가상 엘레멘트는 가정적 항목을 지명하기 위하여 CSS 선택자(selector)에 사용된다.(예를 들어 구조적(structural) 엘레멘트 대신 엘레멘트의 첫번 줄)

가상 클래스(class)

가상 클래스는 HTML 자원의 외부 정보를 허용하기 위하여 CSS 선택자(selector)에 사용된다.(예를 들어 방문했던 앤커인가 방문하지 않았던 앤커인가의 엘레멘트 분류)

속성(property)

CSS를 통하여 영향을 주는 스타일 성질(parameter). 이 규격은 속성들의 목록과 그에 상응하는 값을 정의한 것이다.

리더(reader)

문서를 읽어 보는 사람

대체된(replaced) 엘레멘트

CSS 양식자(formatter)가 그 intrinsic dimensions을 알 때 하나의 엘레멘트. HTML의 'IMG', 'INPUT', 'TEXTAREA', 'SELECT', 'OBJECT' 엘레멘트들이 대체된(replaced) 엘레멘트의 예제가 될 수 있다. 예를 들어, 'IMG' 엘레멘트의 내용은 자주 그 SRC 애트리뷰트가 지시하는 이미지로 대체된다. CSS1은 어떻게 그 intrinsic dimensions을 찾는가를 정의하지 않는다.

명령(rule)

하나의 선언(예를 들어 'font-family: helvetica')와 그 선택자(selector)(예를 들어 'H1')

선택자(selector)

어떤 엘레멘트에 해당 명령(rule)이 적용되는가를 지정하는 하나의 문자열. 하나의 선택자(selector)는 단순한 선택자가 될 수 있고(예를 들어 'H1'), 또는 여러개의 단순 선택자로 구성된 복합 선택자(contextual selector:예를 들어 'H1 B')가 될 수 있다.

SGML

HTML도 이 적용의 하나인 Standard Generalized Markup Language[5]

단순 선택자(selector)

문서 구조 안에서 엘레멘트의 위치가 아닌, 엘레멘트 type과 애트리뷰트에 기초한 해당하는 엘레멘트의 하나의 선택자(selector), 예를 들어, 'H1.initial'는 하나의 단순 선택자

(selector)이다.

스타일쉬트(style sheet)

여러 명령(rule)들의 집합체

사용도구

웹문서를 표현하는 도구로 웹브라우저를 포함하는 기타 메디아 브라우저

사용자

리어(reader)와 동의어

우선순위(weight)

명령(rule)의 우선순위

이 규격의 텍스트안에서, 단일 따옴표('...') 안의 내용은 HTML과 CSS 문장이다.

1. 기본 개념

단일 스타일 쉬트를 설계하는 것은 간단하다. 누구나 을 간단히 알고 기본적인 편집을 알면된다.

예를 들어, 'H1' 엘레멘트의 색상을 청색으로 설정하려면, 쉽게 아래와 같이 표시하면 된다. H1 { color: blue }

위예제는 단일 CSS 명령(rule)이다. 명령(rule)은 두 부분으로 구성되는데: 선택자(selector) ('H1')와 선언('color: blue')이다. 선언은 두 부분으로 구성되는데: 속성 ('color')과 값('blue')이다. While the 위 예제에서는 HTML 문서를 표현하는데 한가지 속성 만 지정 했는데, 이로서 자신의 스타일쉬트가 되는 것이다. 다른 백여종의 기본 기능의 스타일쉬트들과 조합하여 최종적인 문서의 표현을 하게 되는 것이다.

선택자(selector)는 HTML 문서와 스타일쉬트를 연결시고, 모든 HTML 엘레멘트들이 선택자(selector)가 될 수 있다.
HTML 엘레멘트들은 HTML 규격을 참조하라.

색상('color') 속성은 약 50 속성들 중의 하나로 HTML 문서 표현을 결정한다. 속성들과 가능한 값들의 목록이 이 규격에 정의되어 있다.

HTML 제작자들은 그의 문서에서 특정 스타일을 제시하기를 원할 때 만 스타일쉬트를 사용할 필요가 있다. 각 사용도구는 문서의 합리적인 표현을 위한 디폴트 스타일쉬트를 가지고 있다. 그러나 제각기 다르다. 부록 A는 HTML 문서들을 표현하기 위해 제안된 [3] HTML 2.0 규격의 단순 스타일쉬트를 포함하고 있다.

공식적인 CSS1 언어의 문법은 부록 B에 정의되어 있다.

1-1.  HTML 문서에 포함

스타일쉬트가 문서의 표현에 영향을 주기 위해서는, 사용도구는 그 존재를 알아야 한다. HTML 규격은 HTML를 어떻게 스타일쉬트와 연결시키는가를 정의하고 있다. 따라서 이 항목은 정보를 제공하는 것이며, 지명적인 것은 아니다. <HTML> <HEAD> <TITLE>title</TITLE> <LINK REL=STYLESHEET TYPE="text/css" HREF="http://style.com/cool" TITLE="Cool"> <STYLE TYPE="text/css"> @import url(http://style.com/basic); H1 { color: blue } </STYLE> </HEAD> <BODY> <H1>Headline is blue</H1> <P STYLE="color: green">While the paragraph is green. </BODY> </HTML>

예제는 스타일과 HTML을 결합하는 네가지 방법을 보여준다.
1. 'LINK' 엘레멘트로 외부 스타일쉬트와 연결
2. 'HEAD' 엘레멘트 안에서 'STYLE' 엘레멘트 지정
3. CSS '@import'의 기술로 스타일 쉬트 도입(import)
4. 'BODY' 안에서 엘레멘트에 'STYLE' 애트리뷰트로
마지막 선택은 스타일과 내용을 섞어 사용하여 전통적인 스타일쉬트의 해당 잇점을 감소시킨다.

'LINK' 엘레멘트는 리더가 선택할 수 있는 대체 가능한 스타일쉬트를 조회하고, 도입(import)은 스타일쉬트를 자동적으로 불러 나머지 스타일쉬트와 통합한다.

전통적으로 사용도구는 조용히 알지 못하는 태그를 무시하여 왔다. 그 결과, 옛 사용도구들은 'STYLE' 엘레멘트를 무시한다. 그러나 그 내용들이 문서 본체(body)의 부분으로 처리되어 그렇게 표현된다. 이전 단계에서는, 'STYLE' 엘레멘트 내용은 SGML 코멘트(Comment)를 사용하여 감춰질 수 있다. <STYLE TYPE="text/css"> <!-- H1 { color: green } --> </STYLE>

'STYLE' 엘레멘트는 문서 타입 정의(DTD)에서 "CDATA"로 정의 되므로, 규격에 맞는 SGML 처리자(parser)는 위의 스타일쉬트를 스타일쉬트로 고려하지 않고 코멘트로 해석하여 표현하지 않을 것이다.

1-2.  그룹으로 묶기

스타일쉬트의 크기를 줄이기 위하여 선택자을 컴마로 분리하여 구룹으로 묶어 목록을 만들 수 있다. H1, H2, H3 { font-family: helvetica }

같은 방법으로 선언도 구룹으로 묶을 수 있다. H1 { font-weight: bold; font-size: 12pt; line-height: 14pt; font-family: helvetica; font-variant: normal; font-style: normal; }

추가적으로 일부 속성들은 그들 자체로 구룹으로 묶기를 할 수 있는데 문법은 H1 { font: bold 12pt/14pt helvetica }

이는 위의 예제와 같다.

1-3.  전달(inherit)

첫번째 예제에서, 'H1' 엘레멘트의 색상을 청색으로 지정하였다. 'H1' 엘레멘트에 강조된 엘레멘트가 있다고 가정하면 <H1>제목 중에 <EM>이 부분이</EM> 중요하다.</H1>

만일 'EM' 엘레멘트에 색상이 지정되지 않았으면, 강조된 "이 부분이"는 모체(parent) 엘레멘트 본래의 색상을 가질 것이다. 여기서 예를 들면 역시 청색으로 나타난다. 예를 들어 'font-family'와 글꼴 크기('font-size')등 다른 스타일 속성들은 같은 방식으로 전달된다.

한 문서의 디폴트("default") 스타일 속성을 설정하려면, 모든 보이는 엘레멘트들의 속성을 설정할 수 있다. HTML 문서들에서, 'BODY' 엘레멘트는 여러가지 이런 기능을 할 수 있다. BODY { color: black; background: url(texture.gif) white; }

제작자가 만일 'BODY' 태그를 생략하여도 HTML 표현기는 누락된 태그를 삽입하여 이것은 작용된다. 위 예제에서 텍스트의 색상을 검정으로하고 배경에 이미지를 넣었다. 이미지가 없으면 배경색은 백색으로 된다.(항목 5.3을 참조하라.)

일부 스타일 속성들은 모체(parent) 엘레멘트로 부터 하위(child) 엘레멘트로 전달되지 않는다. 대부분의 경우 그렇지 않은지는 쉽게 이해할 수 있다. 예를 들어, 배경('background') 속성은 전달되지 않으나, 모체(parent) 엘레멘트의 배경(background)은 디폴트로 전체적으로 적용된다.

자주 속성값이 백분율로 되는데, 이는 다른 속성(property)을 참조한다. P { font-size: 10pt } P { line-height: 120% } /* 글꼴 크기('font-size')의 상대적인 값, 여기서는 12pt */

백분율 값들을 허용하는 각 속성은, 그것이 어떤 속성을 참조하는지 정의한다. 'P'의 하위 엘레멘트들은 줄높이('line-height')의 전달된 값에서 백분율이 아니라 계산된 값이 된다(말하자면 12pt).

1-4.  선택자(selector)로 클래스(class)

엘레멘트들에 대한 점진적인 제어를 향상시키기 위하여, 'CLASS'라는 새로운 애트리뷰트가 HTML에 글라스(class)로 추가 되었다. 'BODY' 엘레멘트 안의 모든 엘레멘트들은 클래스(class)화될 수 있고, 클래스(class)는 스타일쉬트에 지정될 수 있다. <HTML> <HEAD> <TITLE>Title</TITLE> <STYLE TYPE="text/css"> H1.pastoral { color: #00FF00 } </STYLE> </HEAD> <BODY> <H1 class=pastoral>녹색을 표현하는 방법</H1> </BODY> </HTML>

일반적인 전달 명령(rule)들은 클래스(class)화된 엘레멘트들에 적용된다. 문서 구조안에서 모체로 부터 값이 전달된다.

모든 엘레멘트들에 같은 클래스(class)를 선택자(selector)를 생략하고 사용할 수 있다. .pastoral { color: green } /* 모든 엘레멘트들을 CLASS pastoral로 */

선택자(selector) 마다 하나의 클래스(class) 만을 지정할 수도 있다. 'P.pastoral.marine'는 CSS1에서 개별 선택자(selector)이다. 복합 선택자(contextual selector)들은 아래 설명하는데, 단일 선택자(selector)가 하나의 클래스(class)를 갖는다.

CSS는 CLASS 애트리뷰트에 큰 능력을 제공하지 않는다, 이것은 많은 경우 어떤 HTML 엘레멘트의 클래스(class)가 설정되었는가 문제가 되지 않고 어떤 엘레멘트에도 사용될 수 있기 때문이다. 이 기능에 의존하는 것은 추천되지 않는데, 이는 HTML 엘레멘트들의 공통적인 구조의 의미를 희석시키기 때문이다. CLASS에 기초한 구조는 클래스(class)의 의미가 상호 합의된 제한된 도메인에서 만 유용하다.

1-5.  선택자(selector)로서 ID

HTML('id' 지정자)은 또한 전 문서를 통한 유일한 값을 보증하는 'ID' 애트리뷰트를 도입했다. 따라서 이는 스타일쉬트 선택자(selector)에서 특별히 중요한며, '#'로 시작하도록 지정한다. #z98y { letter-spacing: 0.3em } H1#z98y { letter-spacing: 0.5em } <P ID=z98y>Wide text</P>

위 예제에서, 첫번째 선택자(selector)는 'P' 엘레멘트는 'ID' 애트리뷰트 값 때문에 맞는다. 두번째 선택자(selector)에서는 엘레멘트 type ('H1')와 ID 값 두가지를 다 지정 했으므로, 'P' 엘레멘트에 맞지 않는다.

ID 애트리뷰트를 선택자(selector)로 사용함에 있어서, 스타일 속성들을 엘레멘트 단위를 기준으로 설정할 수 있다. 스타일쉬트을은 문서 구조를 위하여 설계되었기 때문에, 이 기능은 제작자들이 HTML의 구조적 엘레멘트들의 잇점을 이용하지 않고 화면에 잘 표현되는 문서를 만들도록 한다. 스타일쉬트의 이와 같은 사용은 피하는 것이 좋다.

1-6.  복합 선택자(contextual selector)

전달은 CSS 설계자들의 입력을 절약 해 준다. 모든 스타일 속성들을 지정하는 대신, 디폴트(default)를 만들고 제외되는 목록를 만들 수 있다. 'H1' 안의 'EM' 엘레멘트들을 다른 색상으로 지정하기 위하여 다음과 같이 할 수 있다. H1 { color: blue } EM { color: red }

이 스타일쉬트가 작용하면'H1'의 안에 있던 밖에 있던 모든 강조 부분이 붉은색이 된다. 'H1' 안에 있는 'EM' 엘레멘트들만 붉게 하려면 다음과 같이 하면 된다. H1 EM { color: red }

이 선택자(selector)는 이제 검색 형태를 가지고 열린 엘레멘트들을 검정한다. 이와 같은 선택자(selector)를 복합 선택자(contextual selector)라 한다. 복합 선택자들은 몇개의 단순 선택자들을 빈칸으로 구분하여 지정한 것이다(지금까지 설명한 것은 모두 단순 선택자들이었다). 마지막 단순 선택자에 맞는 엘레멘트들 만('EM' 엘레멘트) 그리고 이 검색 과정에 맞는 것 만이 표현된다. CSS1에서 복합 선택자(contextual selector)들은 원형적 관계를 검색한다. 그러나 다른 관계들(예를 들어 모체-하위)은 향 후 버전에 반영된다. 위의 예제에서, 검색 과정은 만일 'EM'이 'H1' 안에 있을 때 적용된다. UL LI { font-size: small } UL UL LI { font-size: x-small }

여기에서, 첫번째 선택자(selector)가 'LI' 엘레멘트들과 맞으면 최소의 하나의 'UL' 조상을 갖는다. 두번째 예제에서 선택자는 맞으면 첫째의 하위 'LI' 엘레멘트는 최소 두개의 'UL' 조상을 갖는다. 두번째 선택자의 보다 긴 검색 구조 때문에 구체적으로 되어 이 혼동은 해결된다. 항목 3.2 카스케이딩 순서를 참조하라.

복합 선택자(contextual selector)들은 엘레멘트 타입(type)들, CLASS 애트리뷰트들, ID 애트리뷰트들 또는 이들의 조합을 검정할 수 있다. DIV P { font: small sans-serif } .reddish H1 { color: red } #x78y CODE { background: blue } DIV.sidenote H1 { font-size: large }

첫번째 선택자(selector)는 'DIV' 조상들 중에서 모든 'P' 엘레멘트들이 맞는 것을, 두번째 선택자 클래스(class) 'reddish' 조상을 갖는 모든 'H1' 엘레멘트들이 맞는 것을, 세번째 선택자는 'ID=x78y'를 갖는 것들 중 모든 'CODE' 엘레멘트들을, 그리고 네번째 선택자는 'DIV' 조상에 클래스(class) 'sidenote'를 가진 모든 'H1' 엘레멘트들에 맞는 것이다.

여러 복합 선택자(contextual selector)들도 구룹지워 질 수 있다. H1 B, H2 B, H1 EM, H2 EM { color: red }

이는 아래와 같은 것이다. H1 B { color: red } H2 B { color: red } H1 EM { color: red } H2 EM { color: red }

1-7.  코멘트(Comment)

CSS 스타일쉬트에서 코멘트(Comment) 텍스트는[7] 프로그램 언어 C에서와 비슷하다. EM { color: red } /* red, 이는 적색이다 */

코멘트(Comment)는 네스트될 수 없다. CSS1 표현기에서 코멘트(Comment)는 공간과 같다.

2.  가상 클래스(class)와 가상 엘레멘트

CSS1에서, 스타일은 일반적으로 문서 구조의 해당 위치의 엘레멘트에 추가된다. 이 단순한 모델은 다양한 스타일들에 충분하나, 일부 보편적인 효과를 해결하지 못한다. 가상 클래스(class)와 가상 엘레멘트의 개념이 CSS1에서 양식화 과정에 외부 정보를 허용하도록 확장한다.

가상 클래스(class)들과 가상 엘레멘트들이 CSS 선택자(selector)로 사용될 수 있다. 그러나 이들은 HTML 자원에는 존재하지 않는다. 오히려 이들은 어떤 경우에 스타일쉬트로 사용될 수 있도록 사용도구에 의하여 삽입된다. 이들은 "글래스"와 "엘레멘트"로 불리우는데, 이는 그들의 행동을 기술하는데 편리하기 때문이다. 더 구체적으로, 이들의 행동은 가상 태그 기능으로 정의된다.

가상 엘레멘트들은 엘레멘트들의 하위 부분을 지명하는데 사용된다. 가상 클래스(class)들에서 스타일쉬트가 다른 엘레멘트 타입(type)들을 다르게 처리하기 때문이다.

2-1.  앤커(anchor) 가상 클래스(class)

사용도구들은 일반적으로 새롭게 방문한 앤커를 과거에 방문한 것과 다르게 표현한다. CSS1에서 이것이 'A' 엘레멘트의 가상 클래스(class)를 통하여 처리된다. A:link { color: red } /* 방문하지 않은 연결 */ A:visited { color: blue } /* 방문했던(visited) 연결 */ A:active { color: lime } /* 활성(active) 연결 */

'HREF' 애트리뷰트를 갖는 모든 'A' 엘레멘트들은 하나의, 단지 하나의, 이들 구룹으로 된다(말하자면 목표(target) 앤커들은 영향을 받지 않는다). 사용도구들은 방문했던('visited')에서 일반 연결('link')로 일정한 시간 후에 변화시키는 것을 선택할 수 있다. 활성('active') 연결은 리더에 의하여 마우스 단추 느름 등으로 현재 선택한 연결을 말한다.

앤커(anchor) 가상 클래스(class)의 양식화는 클래스(class)가 수동적으로 삽입되는 것과 같이 이루어 진다. 사용도구는 현재 표현된 문서를 앤커(anchor) 가상 클래스(class) 활동 때문에 다시 양식화할 필요는 없다. 예를 들어, 스타일쉬트는 문법에 맞게 지정할 수 있다. 활성('active') 연결의 글꼴 크기('font-size')를 방문 했던('visited') 연결보다 크게 지정할 수 있다. 그러나 사용도구는 리더가 방문했던( 'visited') 연결을 선택했을 때 탄력성있게 그 문서를 재 양식화할 필요는 없다.

가상 클래스(class) 선택자들은 일반 클래스(class)들과 맞지 않으며 그 역도 마찬가지이다. 따라서 아래 예제의 스타일 명령(rule) 아무 영향이 없다. A:link { color: red } <A class=link NAME=target5> ... </A>

CSS1에서 앤커(anchor) 가상 클래스(class)들은 'A' 엘레멘트 이외의 엘레멘트에는 영향이 없다. 따라서, 엘레멘트 type이 선택자에서 생략될 수 있다. A:link { color: red } :link { color: red }

CSS1에서 위의 두 선택자들은 같은 엘레멘트들을 선택한다.

가상 클래스(class)의 이름(name)들은 대소분자를 구별하지 않는다.

가상 클래스(class)들은 다른 복합 선택자(contextual selector)들 안에서 사용될 수 있다. A:link IMG { border: solid blue }

또한, 가상 클래스(class)들은 일반 클래스(class)들과 조합될 수 있다. A.external:visited { color: blue } <A class=external HREF="http://out.side/">external link</A>

위의 예제에서 연결이 방문했던(visited) 것이면 청색으로 표현된다. 일반 클래스(class) 이름(name)들이 선택자의 가상 클래스(class)들보다 선행한다는 점에 주의하라.

2-2.  인쇄(typographical) 가상 엘레멘트들

일부 보통 인쇄(typographical) 효과들은 구조적 엘레멘트들과 연관되지 않고, 화면에 양식화되는 인쇄(typographical) 항목들에 연관된다. CSS1에서, 두가지 이런 인쇄(typographical) 항목들을 가상 엘레멘트들을 통하여 지정할 수 있는데, 엘레멘트의 첫 줄과 첫 글자이다.

CSS1 핵심: 사용도구들은 모든 명령(rule)들에서 선택자의 첫 줄(':first-line') 혹은 첫 글자(':first-letter')을 무시할 수 있다. 또는 이들 가상 엘레멘트들 속성들의 하위 설정 만을 지원할 수 있다(항목 7 참조).

2-3.  첫줄('first-line') 가상 엘레멘트

첫줄('first-line') 가상 엘레멘트는 화면에서 첫줄에 특수한 스타일을 적용하기 위하여 사용된다. <STYLE TYPE="text/css"> P:first-line { font-variant: small-caps } </STYLE> <P>The first line of an article in Newsweek.

텍스트 기준 사용도구에서 이는 다음과 같이 양식화된다. THE FIRST LINE OF AN article in Newsweek.

위 예제의 가상 태그 기능은 <P> <P:first-line>The first line of an </P:first-line> article in Newsweek. </P>

첫줄('first-line') 종료태그는 첫줄 끝에 삽입한다.

첫줄('first-line') 가상 엘레멘트는 블럭레벨(block-level) 엘레멘트에 만 사용될 수 있다.

첫줄('first-line') 가상 엘레멘트는 인라인(inline) 엘레멘트와 비슷하다. 그러나 제한들이 있다. 첫줄('first-line') 엘레멘트에는 다음 속성들 만이 적용된다.
(5.2 글자(font) 속성들), (5.3 색상과 배경 속성들), (5.4.1 단어 간격('word-spacing')), (5.4.2 글자 간격('letter-spacing')), (5.4.3 텍스트 장식('text-decoration')),(5.4.4 수직 정렬('vertical-align') ), (5.4.5 텍스트 변환('text-transform')), (5.4.8 줄높이('line-height')), (5.5.26 'clear').

2-4.  첫글자('first-letter') 가상 엘레멘트

첫글자('first-letter') 가상 엘레멘트는 일반적인 인쇄(typographical) 효과를 갖는 "initial caps" 와 "drop caps"에 사용된다. 이는 유동('float') 속성이 'none'이면 인라인(inline) 엘레멘트와 유사하고, 아니면 유동(floating) 엘레멘트와 유사하다. 첫글자('first-letter') 가상 엘레멘트들에 적용되는 속성들은:
(5.2 글자(font) 속성들), (5.3 색상(color)과 배경(background) 속성), (5.4.3 텍스트 장식('text-decoration')), (유동('float')가 'none' 일 때 만, 5.4.4 수직 정렬('vertical-align')), (5.4.5 텍스트 변환('text-transform')), (5.4.8 줄높이('line-height')), (5.5.1 margin 속성들-5.5.5), (5.5.6 padding 속성들-5.5.10), (5.5.11 border 속성들-5.5.22), (5.5.25 유동('float')), (5.5.26 'clear').

이것은 드롭캡(dropcap) 최초 글자 스판(span) 두 줄을 만드는 것이다. <HTML> <HEAD> <TITLE>Title</TITLE> <STYLE TYPE="text/css"> P { font-size: 12pt; line-height: 12pt } P:first-letter { font-size: 200%; float: left } SPAN { text-transform: uppercase } </STYLE> </HEAD> <BODY> <P><SPAN>The first</SPAN> few words of an article in The Economist.</P> </BODY> </HTML>

만일 택스트 기준 사용도구가 첫글자('first-letter') 가상 엘레멘트를 지원하면(아마 아닐 것이다), 이는 다음과 같이 양식화된다. ___ | HE FIRST few | words of an article in the Economist.

가상 태그 기능으로 <P><SPAN><P:first-letter> T </P:first-letter>he first</SPAN> few words of an article in the Economist.</P>

첫글자('first-letter') 가상 엘레멘트 택그들은 내용(말하자면 첫 글자)에 인접하고, 첫글자('first-letter') 가상 엘레멘트 시작태그는 그것이 첨부된 엘레멘트 시작태그 바로 다음에 삽입된다는 점을 주시하라.

사용도구는 어떤 글자들이 첫글자('first-letter') 엘레멘트 안에 있는가를 판정한다. 일반적으로 첫글자 앞에 따옴으로 첫글자가 포함되어야 한다. || /\ bird in / \ the hand /----\ is worth / \ two in the bush," says an old proverb.

문단이 다른 구둣점으로 시작되거나(예를 들어 괄호와 구둣점들) 일반적으로 글자로 간주되지 않는 다른 글자들로 시작되면(예를 들어 숫자와 수학기호들), 첫글자('first-letter') 가상 엘레멘트들은 일반적으로 무시된다.

일부 언어들에서 어떤 문자 조합을 어떻게 처리할 것인지 특정 명령(rule)들을 지정할 수 있다. 예를 들어 홀랜드어에서, 단어의 시작에서 만일 글자 조합 "ij"가 나타나면, 이들은 두 글자 모두 첫글자('first-letter') 가상 엘레멘트로 고려되어야 한다.

첫글자('first-letter') 가상 엘레멘트는 블럭레벨(block-level) 엘레멘트에 만 사용할 수 있다.

2-5.  선택자(selector)들 안에서 가상 엘레멘트

복합 선택자(contextual selector)에서, 가상 엘레멘트들은 그 선택자(selector) 맨 뒤에 만 허용된다. BODY P:first-letter { color: purple }

가상 엘레멘트들은 선택자(selector)들 안에서 클래스(class)들과 조합할 수 있다. P.initial:first-letter { color: red } <P class=initial>First paragraph</A>

위 예제는 'CLASS=initial'을 갖는 모든 'P' 엘레멘트들의 첫글자를 붉은색으로 만들 것이다. 클래스(class)들 또는 가상 클래스(class)들이 조합되면, 가상 엘레멘트들은 선택자(selector) 맨 뒤에 지정되어야 한다. 선택자마다 하나의 가상 엘레멘트 만 지정할 수 있다.

2-6.  복수 가상 엘레멘트

복수의 가상 엘레멘트들이 조합될 수 있다. P { color: red; font-size: 12pt } P:first-letter { color: green; font-size: 200% } P:first-line { color: blue } <P>Some text that ends up on two lines</P>

이 예제에서, 각 'P' 엘레멘트의 첫글자는 녹색이며 글자 크기는 24pt이다. 나머지 첫줄은(화면에 양식화되는) 청색이고, 나머지 문단은 붉은색이 된다. 단어 "ends" 전에 줄바꿈이 발생되었다고 가정하면, 가상 택그 기능은 <P> <P:first-line> <P:first-letter> S </P:first-letter>ome text that </P:first-line> ends up on two lines </P>

첫글자('first-letter') 엘레멘트는 첫줄('first-line') 엘레멘트 안에 있다 점에 유의하라. 첫줄('first-line')에 설정된 속성들 첫글자('first-letter')로 부터 전달된다. 그러나 같은 첫글자('first-letter') 속성이 설정되면 덮어씌우기(override)가 된다.

만일 가상 엘레멘트가 본래 엘레멘트를 붕괴되면, 필요한 추가 태그들이 가상 태그 기능에서 다시 생성되어야 한다. 예를 들어, 만일 SPAN 엘레멘트가 </P:first-line> 태그 밖으로 확장되면, 종료태그와 시작태그가 다시 생성되어야 하며 가상 태그 기능은 다음과 같이 된다. <P><P:first-line><SPAN>This text is inside a long</SPAN></P:first-line> <SPAN>span 엘레멘트</SPAN>

3.  카스케이드(cascade)

CSS에서, 하나이상의 스타일쉬트가 표현에 동시에 영향을 줄 수 있다. 이는 두가지 주된 이유가 있는데 하나는 모듈화 속성이고 다른 하나는 제작자/리더 바란스이다.

모듈화 속성(modularity)

스타일쉬트는 복잡성을 피하기 위하여 여러개의 부분적인 스타일쉬트들을 조합하도록 설계되었다. @import url(http://www.style.org/pastoral); @import url(http://www.style.org/marine); H1 { color: red } /* 도입된(imported) 스타일을 덮어씌움(override) */

제작자/리더 바란스

리더와 제작자들이 스타일쉬트를 통하여 표현에 영향을 줄 수 있다. 이를 위해 그들은 같은 스타일쉬트 언어를 사용하여 웹의 기초 기능을 반영하여야 한다. 누구나 문서 발행자가 될 수 있다. 사숑도구는 개인적인 스타일쉬트 표현 기능의 선택이 자유이다.

때로는 스타일쉬트들이 표현에 영항하는데 모순이 일어난다. 모순의 해결은 각 스타일 명령(rule)에 기초하여 우선순위(weight)를 갖는다. 디폴트로 리더의 명령(rule)들 보다 제작자 문서의 명령(rule)들이 우선 적용된다. 말하자면, 만일 들어오는 문서와 리더의 개별 스타일쉬트 간의 마찰이 생기면, 제작자의 명령(rule)들이 사용된다. 리더나 제작자 명령(rule)들이 모두 사용도구의 디폴트 값을 덮어씌운다.

도입된(imported) 스타일쉬트 또한 서로 카스케이드(cascade)된다. 도입된 순서에 따라, 카스케이드(cascade) 명령(rule)은 아래 설명한다. 스타이쉬트에 지정된 어떤 명령(rule)들은 자체가 도입된(imported) 스타일쉬트의 명령(rule)들를 덮어씌운다. 이는 도입된 스타일쉬트가 지체 스타일쉬트에 있는 명령(rule)보다 낮은 카스케이딩 순서를 갖는다는 뜻이다. 도입된 스타일쉬트는 반복적으로 도입하고 다른 스타일쉬트를 덮어씌울 수 있다.

CSS1에서, 모든 '@import' 선언은 스타일쉬트 시작부분에 나와야 하며 선언 이전에 이루어 져야한다. 이는 보기 쉽게하며, 스타일쉬트 자체의 명령(rule)들이 도입된 스타일쉬트의 명령들을 덮어씌우게 한다.

3-1.  중요('important')

스타일쉬트 설계자는 그들 선언의 중요도를 증가시킬 수 있다. H1 { color: black ! important; background: white ! important } P { font-size: 12pt ! important; font-style: italic }

위 예제에서, 첫 세가지 선언은 중요도를 증가시킨 선언들이고, 마지막 것은 보통의 중요도이다.

사용자의 중요 선언 명령(rule)은 제작자 보통 선언 명령(rule)을 덮어씌운다(override). 제작자 중요 선언 명령(rule)은 사용자의 중요 선언 명령(rule)을 덮어씌운다.

3-2.  카스케이딩 순서

모순되는 명령(rule)들은 CSS 기능의 원칙에 따른다. 엘레멘트/속성 조합의 값을 찾기위하여 다음 순서의 기능을 따라야 한다.

1. 문제의 모든 엘레멘트/속성에 적용되는 모든 선언들을 찾는다. 문제의 엘레멘트가 그 선택자(selector)와 맞으면 선언(declaration)들을 적용한다. 선언이 적용되지 않으면 전달된(inherited) 값이 사용된다. 전달된 값이 없으면('HTML' 엘레멘트와 속성들이 전달되지 않은 경우) 최초값이 적용된다.
2. 표현 중요도에 따라 선언(declaration)들이 정렬된다. 중요한 표시('!important')가 된 것이 선언되지 않은 것 보다 우선한다.
3. 원본의 순서에 따라 정렬된다. 제작자의 스타일쉬트가 리더 스타일쉬트를 덮어씌우고(override), 리더 스타일쉬트는 사용도구의 디폴트 값들을 덮어씌운다. 도입된(imported) 스타일쉬트는 그 스타일쉬트가 도입된 자원과 같은 원본이다.
4. 지정된 선택자(selector)로 정렬된다. 보다 구체적인 선택자(selector)가 일반적인 선택자를 덮어씌운다. 보다 구체적으로 찾기 위해, ID 애트리뷰트들의 선택자(a) 갯수를 세고, CLASS 애트리뷰트들의 선택자(b) 갯수를 세고, 선택자 안의 태그 이름(c)의 갯수를 센다. 이 세 갯수들의 연쇄(큰 베이스의 수치 시스템 안에서)는 구체적으로 주어진다. 예제를 보면 LI {...} /* a=0 b=0 c=1 -> 구체화수 = 1 */ UL LI {...} /* a=0 b=0 c=2 -> 구체화수 = 2 */ UL OL LI {...} /* a=0 b=0 c=3 -> 구체화수 = 3 */ LI.red {...} /* a=0 b=1 c=1 -> 구체화수 = 11 */ UL OL LI.red {...} /* a=0 b=1 c=3 -> 구체화수 = 13 */ #x34y {...} /* a=1 b=0 c=0 -> 구체화수 = 100 */

   가상 엘레멘트들과 가상 클래스(class)들은 각각 일반 엘레멘트들과 클래스(class)들로 합산된다.

5. 지정된 우선순위로 정렬한다. 만일 두가지 명령(rule)이 같은 우선순위를 가지면, 나중에 지정된 것이 적용된다. 도입된(imported) 스타일쉬트의 명령(rule)들은 스타일쉬트 자체의 어떤 명령들 이전의 것으로 간주된다.

속성값의 검색은 한 명령(rule)이 같은 엘레멘트/속성 조합에 적용되는 다른 명령들보다 높은 우선순위를 갖는 것을 만나면 종료된다.

이 원칙은 제작자의 스타일쉬트가 리더의 스타일쉬트보다 상당히 높은 우선순위를 갖게한다. 따라서 리더는 어떤 스타일쉬트의 영향을 중지시킬 수 있게하는 것이 중요하다. 예를 들어 풀다운(pull-down) 메뉴를 통하여

어떤 엘레멘트의 'STYLE' 애트리뷰트에서 선언(예제는 항목 1.1 참조)은 스타일쉬트 맨 뒤에 지정한 ID 선택자(selector)와 같은 우선순위를 갖는다. <STYLE TYPE="text/css"> #x97z { color: blue } </STYLE> <P ID=x97z STYLE="color: red">

위 예제에서, 'P' 엘레멘트의 색상은 붉은색일 것이다. 두 선언에서 같은 구체화수를 갖지만, 'STYLE' 애트리뷰트의 선언이 'STYLE' 엘레멘트의 선언을 덮어씌울 것이다. 이는 위의 카스케이딩 원칙 5번을 따르기 때문이다.

사용도구는 다른 스타일적 HTML 애트리뷰트들 선택할 수 있다. 예를 들어 'ALIGN'. 그런 경우, 이들 애트리뷰트들은 해당 CSS 명령(rule)들로 해석하여, 구체화수는 1이 된다. 이 명령(rule)들은 제작자 스타일쉬트의 시작부분에 있는 것으로 간주된어 후속 스타일 명령들에 의하여 덮우씌우게 된다. 과도적 단계에서 이 정책은 스타일적 애트리뷰트들을 스타일쉬트와 동시에 사용하기 쉽게 한다.

4.  양식화(formatting) 모델

CSS1은 단순 박스형(box-oriented) 양식 모델을 가정한다. 거기서 각 양식화된 엘레멘트가 하나이상의 사각형 박스들을 만드는 것이다. 'display' 값이 'none'인 엘레멘트들은 양식화되지 않고, 따라서 박스를 만들지 않을 것이다. 모든 박스(box)들은 중심 내용 지역(area)과 주위 패딩(padding), 테두리(border)와 마진(margin) 지역을 갖는다. _______________________________________ | | | margin (마진: 투명) | | _________________________________ | | | | | | | border (테두리) | | | | ___________________________ | | | | | | | | | | | padding (패딩) | | | | | | _____________________ | | | | | | | | | | | | | | | content (내용) | | | | | | | |_____________________| | | | | | |___________________________| | | | |_________________________________| | |_______________________________________| | 엘레멘트 너비 | | 박스(box) 너비 |

마진(margin), 태두리(border) 그리고 패딩(padding)의 크기(size)는 각각 (5.5.1 margin-5.5.5), (5.5.6 padding-5.5.10) 와 (5.5.11 border-5.5.22) 속성들이 설명되어 있다. 패딩(padding) 지역은 엘레멘트 자체와 같은 배경을 사용한다. (5.3.2 background 속성들-5.3.7 참조). 테두리의 색상(color)과 스타일은 테두리(border) 속성들과 함께 설정한다. 마진은 항상 투명하여, 모체 엘레멘트가 잘 표현된다.

박스의 크기는 엘레멘트(말하자면 양식화된 택스트나 이미지) 너비와 패딩, 테두리, 마진 지역들의 합산이다.

양식화 견지에서 엘레멘트들의 두가지 주된 타입(type)들이 있는데, 블럭레벨(block-level)과 인라인(inline)이다.

4-1.  블럭레벨(block-level) 엘레멘트

'display' 값이 블럭('block') 또는 목록('list-item') 인 엘레멘트들은 블럭레벨(block-level) 엘레멘트들이다. 또한, 유동('float') 값이 'none'이 아닌 다른 값을 가진 엘레멘트들인 유동(floating) 엘레멘트들도 블럭레벨(block-level) 엘레멘트들로 간주된다.

다음 예제는 2개의 하위 구조를 가진 'UL' 엘레멘트의 마진(margin)과 패딩(padding)이 어떻게 양식화되는지를 보여준다. 간단히 하기 위하여 도표는 테두리(border)들이 없다. 또한 이 예제에서 CSS1 분법에는 맞지 않으나, 스타일쉬트의 값들을 도표에 표시하도록 편이상 단일 글자 내용("constants")를 사용하였다. <STYLE TYPE="text/css"> UL { background: red; margin: A B C D; padding: E F G H; } LI { color: white; background: blue; /* 청색바탕에 흰색 글씨 */ margin: a b c d; padding: e f g h; } </STYLE> .. <UL> <LI>목록의 1번 엘레멘트 <LI>목록의 2번 엘레멘트 </UL> _______________________________________________________ | | | A UL 마진(margin: 투명) | | _______________________________________________ | | D | | B | | | E UL 패딩(padding: 적색) | | | | _______________________________________ | | | | H | | F | | | | | a LI 마진(margin: 투명, | | | | | | 적색이 비침) | | | | | | _______________________________ | | | | | | d | | b | | | | | | | e LI 패딩(padding: 청색) | | | | | | | | | | | | | | | | h 목록의 1번 엘레멘트 f | | | | | | | | | | | | | | | | g | | | | | | | |_______________________________ | | | | | | | | | | | | | max(a, c) <- 최대 부분 | | | | | | _______________________________ | | | | | | | | | | | | | | d | e LI 패딩(padding: 청색) | | | | | | | | | | | | | | | | h 목록의 2번 엘레멘트 f | | | | | | | | | | | | | | | | g | | | | | | | |_______________________________ | | | | | | | | | | | | | c LI 마진(margin: 투명, | | | | | | 적색이 비침) | | | | | |_______________________________________ | | | | | | | | | G | | | |_______________________________________________ | | | | | C | |_______________________________________________________ |

전형적으로, 패딩(padding)과 마진(margin) 속성들은 전달(inherit)되지 않는다. 그러나, 예제에서 본바와 같이, 엘레멘트의 대체는 모체들과 형제들에 상대적으로 이루어 진다. 따라서 이들 엘레멘트들의 패딩(padding)과 마진(margin) 속성들이 그들의 하위 항목에서 영향을 받는다.

만일 위의 예제에 테두리(border)들이 있다면, 이 테두리들은 패딩과 마진들사이에 나타 날 것이다.

다음 도표는 유용한 용어들을 설명한다. ----------------------- <-- 맨위(top) 위쪽 마진(top margin) ----------------------- 위쪽 테두리(top border) ----------------------- 위쪽 패딩(top padding) +-----------+ <-- 내부 맨위(inner top) | | | | | | | | |-왼쪽-|-왼쪽-|-왼쪽--|-- 내용 --|-오른쪽-|-오른쪽-|-오른쪽-| | 마진 |태두리| 패딩 | | 패딩 | 태두리 | 마진 | |-left-|-left-|-left--|- content -|-right--|-right--|-right--| |margin|border|padding| |padding | border | margin | | | | | | | | | +-----------+ <-- 내부 맨아래(inner bottom) ^ ^ ^ ^ 왼쪽 왼쪽 오른쪽 오른쪽 외부틀 내부틀 내부틀 외부틀 left left right right outer inner inner outer edge edge edge edge 아래쪽 패딩(bottom padding) ----------------------- 아래쪽 테두리(bottom border) ----------------------- 아래쪽 마진(bottom margin) ----------------------- <-- 맨아래(bottom)

왼쪽 외부틀(left outer edge)은 그의 패딩(padding), 테두리(border)와 마진(margin)을 포함한 엘레멘트의 틀이다.
왼쪽 내부틀(left inner edge)는 어느 패딩(padding), 테두리(border)와 마진(margin) 안에 있는 내용(content) 만의 틀이다.
맨위(top)는 패딩(padding), 테두리(border)와 마진(margin)을 포함한 그 엘레멘트의 맨 위이다. 이는 인라인(inline)이며 유동(floating) 엘레멘트들에 만 지정되며, 유동하지 않는(non-floating) 블럭레벨(block-level) 엘레멘트들에는 지정되지 않는다.
내부 맨위(inner top)는 어느 패딩(padding), 테두리(border)와 마진(margin) 안에 있는 내용의 맨위이다.
맨아래(bottom)는 패딩(padding), 테두리(border)와 마진(margin)을 포함한 그 엘레멘트의 맨아래이다. 이는 인라인(inline)이며 유동(floating) 엘레멘트들에 만 지정되며, 유동하지 않는(non-floating) 블럭레벨(block-level) 엘레멘트들에는 지정되지 않는다.
내부 맨아래(inner bottom)는 어느 패딩(padding), 테두리(border)와 마진(margin) 안에 있는 내용의 맨아래이다.

엘레멘트의 너비(width)는 내용(content)의 너비이며, 말하자면, 왼쪽 내부틀(left inner edge)과 오른쪽 내부틀(right inner edge)과의 거리이고, 높이(height)는 내용(content)의 높이로 내부 맨위(inner top)와 내부 맨아래(inner bottom)와의 거리이다.

4-1-1.  수직 양식화

유동 않는(non-floating) 블럭레벨(block-level) 엘레멘트들의 마진(margin) 너비는 주위 박스(box)의 틀(edge)들사이의 최소 거리이다. 두개 혹은 그이상의 인접한 수직 마진들은 패딩(padding), 테두리(border)가 없거나 그사이의 내용(content)이 없을 때 마진의 값을 최대로 사용하기 위하여 붕괴된다. 대부분의 경우에는, 수직 마진들이 붕괴된 후, 실제로 설계자가 기대하는 것에 가깝고 편하게 보이는 결과를 가져다 준다. 위의 예제에서, 1번 LI 엘레멘트의 아래쪽 마진('margin-bottom')과 2번 LI 엘레멘트의 위쪽 마진('margin-top')의 최대 사용으로, 두 'LI' 엘레멘트들은 붕괴된다. 같은 방식으로 만일 'UL' 과 1번 'LI' 엘레멘트(내용 "E")사이의 패딩이 0이 되면, UL 과 1번 LI 엘레멘트들의 마진들은 붕괴된다.

마진들이 음수인 경우, 음수 절대 최대 인접 마진들은 양수 절대 최대 인접 마진들로 부터 빼진다. 만일 양수 마진들이 없으면, 음수 절대 최대 인접 마진들은 0에서 빼진다.

4-1-2.  수평 양식화

유동 않는(non-floating) 블럭레벨(block-level) 엘레멘트의 수평 위치와 크기(size)는 7가지 속성들에 의하여 결정된다.

• 왼쪽 마진('margin-left')
• 왼쪽 테두리('border-left')
• 왼쪽 패딩('padding-left')
• 너비('width')
• 오른쪽 패딩('padding-right')
• 오른쪽 테두리('border-right')
• 오른쪽 마진('margin-right')

디폴트로, 어떤 엘레멘트의 너비('width')는 자동('auto')이다. 만일 그 엘레멘트가 대체된(replaced) 엘레멘트가 아니면, 이는 언급한 7 가지 속성들의 합산이 모체 너비과 같도록 너비('width')가 사용도구에 의해 계산된다는 의미한다. 만일 그 엘레멘트가 대체된(replaced) 엘레멘트이면, 너비 값 자동('auto')은 자동적으로 본래의(intrinsic) 그 엘레멘트의 너비로 대체된다.

7 가지 속성들 중 왼쪽 마진('margin-left'), 너비('width') 와 오른쪽 마진('margin-right') 3 가지는 자동('auto')으로 설정될 수 있다. 대체된(replaced) 엘레멘트들에서, 너비 값 'auto'는 본래의 너비로 대체되고 두가지 만 'auto' 값을 가질 수 있게 된다.

너비('width')가 음수가 아닌 경우, 엘레멘트에 따라 다르고 나아가 다른 속성들에 따라 다르지만 사용도구가 정의한 최소값이 된다. 만일 너비가 지명적으로 그렇게 지시하였거나, 자동('auto')을로 되었는데 그 명령(rule)이 너무 작게 요구하여, 그 한계 이하이면 그 대신 그 값은 최소값으로 대체된다.

만일 왼쪽 마진('margin-left'), 너비('width'), 오른쪽 마진('margin-right') 중 하나만 자동('auto')이면, 사용도구는 7 가지 합산이 모체의 너비와 같게 되도록 속성값을 지정한다.

만일, 아무 속성도 'auto'로 지정되지 않았으면, 오른쪽 마진('margin-right') 값이 'auto'가 설정된다.

만일 세개 중 한개이상이 'auto'이면, 그리고 그 중 하나가 너비('width')이면, 그러면 다른 것들은(왼쪽 마진('margin-left') 그리고/혹은 오른쪽 마진('margin-right')) 0으로 설정되고, 너비('width')는 7 가지 합산이 모체의 너비가 되도록 필요한 값을 갖게 된다.

아니면, 만일 왼쪽 마진('margin-left')와 오른쪽 마진('margin-right')가 'auto'이면, 같은 값들이 설정된다. 따라서 그의 모체 안에서 그 엘레멘트가 중앙에 위치하게 된다.

만일 'auto'가 7 가지 속성들 중 하나가 인라인(inline) 또는 유동(floating) 엘레멘트에 설정되면, 그것은 0으로 설정된 것으로 간주된다.

수직 마진(margin)들과는 달리, 수평 마진들은 붕괴되지 않는다.

4-1-3.  목록(list-item) 엘레멘트들

'display' 속성의 목록('list-item') 값을 가진 엘레멘트들은 블럭레벨(block-level) 엘레멘트들로 양식화된다. 그러나 목록(list-item) 메이커(marker)가 먼저 나온다. 메이커(marker)의 타입(type)은 목록 스타일('list-style') 속성(property)에 의허여 결정된다. 메이커(marker)는 목록 스타일('list-style') 속성(property)값에 따라 위치한다. <STYLE TYPE="text/css"> UL { list-style: outside } UL.compact { list-style: inside } </STYLE> <UL> <LI>1번 목록 1번 항목 <LI>1번 목록 2번 항목 </UL> <UL class=COMPACT> <LI>2번 목록 1번 항목 <LI>2번 목록 2번 항목 </UL>

위 예제는 다음과 같이 양식화된다. * 1번 목록 1번 항목 * 1번 목록 2번 항목 * 2번 목록 1번 항목 * 2번 목록 2번 항목

오른쪽에서 왼쪽으로 쓰는 텍스트에서는, 그 메이커(marker)들은 박스의 오른쪽에 나온다.

HTML의 목록 설명을 참조하라

4-1-4.  유동(floating) 엘레멘트

유동('float') 속성(property)을 사용하여, 한 엘레멘트는 엘레멘트들의 정상 유동(flow)인 외부(outside)로 선언될 수 있다. 그리고 그 것은 블럭레벨(block-level) 엘레멘트로 양식화된다. 예를 들어, 이미지(image)를 왼쪽('left')으로 유동('float') 속성을 지정하면, 그 이미지는 다른 블럭레벨(block-level) 엘레멘트의 마진(margin), 패딩(padding) 또는 테두리(border)에 도달할 때까지 왼쪽으로 이동한다. 일반적인 유동(flow)은 오른쪽에서 줄바꿈을 한다. 그 엘레멘트 지체의 margin, border 와 padding들은 그대로 표현될 것이고, 그 마진(margin)들은 인접 엘레멘트들의 마진들과 절대로 붕괴되지 않는다.

한 유동(floating) 엘레멘트는 다음의 내용에 따라 위치한다(section 4.1 블럭레벨 엘레멘트를 참조하라).

1. 왼쪽 유동(left-floating) 엘레멘트의 왼쪽 외부틀(left outer edge)은 모체 엘레멘트의 왼쪽 내부틀(left inner edge) 왼쪽에 오지 않을 수 있다. 오른쪽 유동(right floating) 엘레멘트들도 마찬가지이다.
2. 왼쪽 유동(left-floating) 엘레멘트의 왼쪽 외부틀(left outer edge)은 각 먼저(HTML 문서에서) 왼쪽 유동(left-floating) 엘레멘트의 오른쪽 외부틀(right outer edge) 보다 오른쪽에 있어야 한다. 또한 이전의 맨위(top)는 나중의 맨아래(bottom)보다 낮아야 한다. 오른쪽 유동(right floating) 엘레멘트들에서도 같은 원칙이 적용된다.
3. 왼쪽 유동(left-floating) 엘레멘트의 오른쪽 외부틀(right outer edge)은 그 오른쪽에 있는 오른쪽 유동(right floating) 엘레멘트 왼쪽 외부틀(left outer edge)의 오른쪽이 아닐 수 있다. 오른쪽 유동(right floating) 엘레멘트들에서도 같은 원칙이 적용된다.
4. 유동(floating) 엘레멘트의 맨위(top)는 그 모체의 내부 맨위(inner top)보다 높지 않을 수 있다.
5. 유동(floating) 엘레멘트의 맨위(top)는 먼저의 유동 혹은 블럭레벨(block-level) 엘레멘트의 맨위(top)보다 높지 않을 수 있다.
6. 유동(floating) 엘레멘트의 맨위(top)는 어떤 HTML에서 유동(floating) 엘레멘트보다 먼저의 내용 인라인 박스(line-box)(항목 4.4 참조)의 맨위보다 높지 않을 수 있다.
7. 유동(floating) 엘레멘트는 가능한한 높게 위치하여야 한다.
8. 왼쪽 유동(left-floating) 엘레멘트는 가급적 왼쪽에 멀리 위치하여야 하고, 오른쪽 유동(right floating) 엘레멘트는 가급적 오른쪽에 멀리 위치하여야 한다. 높은 위치가 왼쪽/오른쪽으로 멀리 나가는 것보다 선호된다.

위의 예제는 다음과 같이 양식화된다. ________________________________________ | | 최대(BODY 마진(margin), P 마진) | ______________________________ | | | 간단한 설명 택스트 | B | P | IMG margins 유동(floating) 엘레멘트 | O | | _____ 설명 목적 외에는 | D | m | | | 다른 목적이 없다. | Y | a | | IMG | 유동 엘레멘트는 모체 | | r | | | 엘레멘트 쪽으로 | m | g | |_____| 마진(margin)들, | a | i | 테두리(border)들 | r | n | 그리고 패딩(padding)을 | g | | 유지하면서 이동하였다. | i | |인접 수직 마진들이 비유동(non-floating) | n | |블럭레벨(block-level) 엘레멘트들과의 | | |사이에서 어떻게 붕괴되는가를 주시하라.

'P' 엘레멘트의 마진이 유동(floating) 'IMG' 엘레멘트를 닫는다 점을 주시하라.

유동(floating) 엘레멘트들이 다른 엘레멘트들의 margin, border 그리고 padding 지역과 중복될 수 있는 2 가지 경우가 있다.

• 유동(floating) 엘레멘트가 음수 마진을 가질 때: 유동(floating) 엘레멘트들의 음수 마진들은 다른 블럭레벨(block-level) 엘레멘트들에 표현된다.
• 유동(floating) 엘레멘트가 안에 있는 엘레멘트보다 넓거나 높을 때

4-2.  인라인(inline) 엘레멘트들

블럭레벨(block-level) 엘레멘트들로 양식화되지 않는 엘레멘트들은인라인(inline) 엘레멘트들이다. 인라인(inline) 엘레멘트는 라인 지역(space)을 다른 엘레멘트들과 공유할 수 있다. 다음 예제를 보라. <P>몇개의 <EM>강조된</EM> 단어들이 <STRONG>나타난다</STRONG>.</P>

'P' 엘레멘트는 보통의 블럭레벨(block-level)이고, 'EM'과 'STRONG'는 인라인(inline) 엘레멘트들이다. 만일 'P' 엘레멘트가 모든 엘레멘트들을 한 줄에 양식화하기에 충분히 넓으면, 두개의 인라인(inline) 엘레멘트들이 한 줄에 오게 된다. 몇개의 강조된 단어들이 나타난다.

만일 한 줄에 한 인라인(inline) 엘레멘트의 공간이 충분하지 않으면, 몇개의 박스(box)들로 나누게 된다. <P>몇개의 <EM>강조된 단어들이</EM> 여기에 나타난다.</P>

위 예제는 다음과 같이 양식화된다. 몇개의 강조된 단어들이 여기에 나타난다.

만일 인라인(inline) 엘레멘트가 마진(margin)들, 테두리(border)들, 패딩(padding) 또는 첨부된 텍스트 장식들을 가지면, 이들은 엘레멘트가 깨져서(broken) 아무 효과도 없을 것이다. ---------- 몇개의|강조된 ---------- ----- 단어들이| 여기에 나타난다. -----

위의 모양("figure")이 약간 찌그러 졌는데, 이는 ASCII 그래팩을 사용했기 때문이다. 항목 4.4 높이 계산 방식을 참조하라.

4-3.  대체된(Replaced) 엘레멘트들

대체된(replaced) 엘레멘트는 하나의 그 엘레멘트가 지정하는 내용이 대체된(replaced) 엘레멘트이다. 예를 들어, HTML에서, 'IMG' 엘레멘트가 'SRC' 애트리뷰트가 지시하는 이미지로 대체된다(replaced). 대체된(replaced) 엘레멘트들은 그들 본연(intrinsic)의 규격(dimension)을 갖는다고 가정할 수 있다. 만일 너비('width') 속성값이 'auto'이면, 본연(intrinsic)의 너비를 그 엘레멘트의 너비로 사용한다. 만일 스타일쉬트에 지정한 그 값이 'auto'가 아니면, 이 값이 사용고, 그 대체된(replaced) 엘레멘트는 이에 따라 재싸이징(resize)된다. 재싸이징(resize) 방법은 메디아에 따라 다르다. 높이('height') 속성은 다음과 같은 방식으로 사용된다.

대체된(replaced) 엘레멘트들은 블럭레벨(block-level) 이나 인라인(inline)이 될 수 있다.

4-4.  줄의 높이

모든 엘레멘트들은 줄높이('line-height') 속성은 갖느데, 이는 원칙적으로, 택스트의 총 높이를 준다. 공간이 택스트의 상부와 하부에 추가되어 줄높이를 현성한다. 예를 들어, 만일 텍스트가 12pt 높이이고 줄높이('line-height')가 '14pt'로 설정되면, 줄에 2pt의 공백이 상부에 1pt, 하부에 1pt가 추가된다. 빈 엘레멘트들은 내용을 가지고 있는 엘레멘트들과 꼭 같은 계산으로 영향을 준다.

글자크기(font size)와 줄높이('line-height')의 차이는 선행(leading)이라 불리운다. 선행(leading)의 반을 선행의 반(half-leading)이라 부른다. 양식화 이후에 각 줄은 사각형 줄박스(line-box)를 형성한다.

만일 택스트를 갖는 줄에 다른 줄높이('line-height') 값이있으면(줄에 다른 인라인(inline) 엘레멘트들이 있어서), 이들 각 부분들은 각각의 선행의 반(half-leading)을 아래, 위에 갖는다. 줄박스(line-box)의 높이는 가장 높은 부분의 맨위에서 가장 낮은 부분의 맨아래까지의 거리가 된다. 맨위와 맨아래는 반드시 가장 키가 큰 엘레멘트에 상응하는 것이 아님을 주시하라. 왜냐하면 엘레멘트들은 수직정렬('vertical-align') 속성(property)으로 수직적으로 배치되기 때문이다. 문단(paragraph)을 구성하기 위하여 각 줄박스(line-box)들은 전 줄의 바로 밑에 차곡 차곡 쌓여진다.

대체 안된(non-replaced) 인라인(inline) 엘레멘트들 위와 아래 어떤 패딩(padding), 테두리(border) 또는 마진(margin)은 줄높이에 영향을 주지 않는다 점에 주의하라. 다른 말로 줄높이('line-height')가 선택된 패딩이나 테두리를 위해 너무 작으면, 이 것들은 다른 줄들의 텍스트에 넘쳐 중복(overlap)된다.

줄에 있는 대체된(replaced) 엘레멘트들(예를 들어 이미지들)은 줄박스(line-box)를 크게 만들 수 있다. 만일 대체된(replaced) 엘레멘트의 맨위(top), 이를테면, 모든 그의 패딩(padding), 태두리(border), 마진(margin)을 포함하여, 가장 키가 큰 텍스트 맨위보다 높거나, 가장 낮은 맨아래 보다 낮을 수 있기 때문이다.

보통의 경우, 전 문단에 하나의 줄높이('line-height') 값 만 가지고 있는 경우, 그리고 키 큰 이미지들이 없는 경우, 위의 정의가 그대로 적용되어 후속 줄들의 기초라인(baseline)들이 정확히 줄높이('line-height') 만큼씩 떨어지는 것이 확실하다. 이는 예를 들어 표(table)에서 텍스트의 컬럼(column)들에서 다른 글자들 정렬(align)되는데 중요하다.

이는 두 인접 라인들에 있는 텍스트들이 서로 중복되는 것을 제외하지 않는다 점에 주의하라. 줄높이('line-height')는 텍스트 높이보다 작을 수 있는데, 이런 경우 선행(leading)은 음수가 된다. 이것이 텍스트가 모두 대문자이어 기준선 밑으로 튀어나오는 것이 없슴이 확실할 때 줄들이 서로 가깝게 나오게 할 때, 유용하다. 

4-5.  화 면

화면은 표면에 문서들이 표현되는 사용도구의 한 부분이다. 화면에 해당하는 문서의 구조적 엘레멘트는 없다. 이는 문서의 양식화에 두가지 과제를 제공한다.

• 어디서 부터 화면의 크기(dimension)를 산정할 것인가 ?
• 문서가 전 화면을 커버(cover)하지 못 할 때, 어떻게 그 지역을 표현할 것인가 ?

첫번째 문제에 대한 합당한 대답은 최초의 화면의 너비는 윈도우 창 크기이다. 그러나 CSS1은 이 문제를 사용도구가 결정하도록 남겨두었다. 이 또한 사용도구가 창을 재싸이징(resize)할 때 화면의 너비를 변경하는 것을 기대하는 것이 합리적이다. 그러나 이 또한 CSS1 범위 밖이다.

HTML 표현(extension)들은 두번째 과제에 중점을 주었다. 'BODY' 엘레멘트에 설정하는 배경(background) 애트리뷰트들는 전체 화면에 배경을 깐다. 설계자의 기대를 지원하기 위하여, CSS1는 화면의 배경(background)을 찾기 위하여 특수 명령(rule)을 소개하였다.

만일 'HTML' 엘레멘트의 배경('background') 값이 투명('transparent')과 다르면 그것을 사용하고, 아니면 'BODY' 엘레멘트의 배경('background') 값을 사용한다. 만일 그 결과 값이 투명('transparent')이면, 표현은 정의되지 않은 것이다.

이 명령은 아래와 같은 사용을 허용한다. <HTML STYLE="background: url(http://style.com/marble.png)"> <BODY STYLE="background: red">

위의 예제에서, 화면은 대리석("marble") 이미지로 배경이 된다. 'BODY' 엘레멘트의 배경색은 전체 화면을 덮을 수도 있고 그렇지 않을 수도 있지만 붉은 색이다.

화면 지정에 대한 다른 방법이 유용하게 될 때까지는, 화면 속성들을 'BODY' 엘레멘트에 설정하는 것을 추천한다.

4-6.  'BR' 엘레멘트들

현재의 CSS1 속성들과 그 값들은 'BR' 엘레멘트의 기능을 설명할 수 없다. HTML에서, 'BR' 엘레멘트는 단어사이에서 줄바꿈(line break)을 지정한다. 실제, 이 엘레멘트는 줄바꿈(line break)에 의해 대체된(replaced) 것이다. 향후 CSS 버전에서는 추가(added)와 대체된(replaced) 내용을 다루게 된다. 그러나 CSS1 기준 양식화에서는 'BR'를 특별히 취급하여야 한다.

5.  CSS1 속성들

스타일쉬트(style sheet)들은 스타일(style) 속성들의 값을 설정하므로서 문서들의 표현에 영향을 준다. 이 장에서는 CSS1의 스타일(style) 속성들의 정의된 목록과 그에 해당하는 가능한 값의 목록을 다룬다.

5-1.  속성값에 대한 주기

아래 텍스트는, 각 속성에 대한 허용된 값의 목록과 아래와 같이 문법을 기재하였다.

값: N | NW | NE
값: [ <길이> | thick | thin ]{1,4}
값: [<family-name>, ]* <family-name>
값: <url>? <color> [ / <color> ]?
값: <url> || <color>

• "<"와 ">"사이의 단어들은 값의 타입(type)을 제공한다.
• 가장 일반적인 타입들은 <길이>, <백분율>, <url>, <수치>와 <color>이며, 이들은 항목 6 단위에 기술 되었다.
• 좀 더 전문화된 타입들(예를 들어 <font-family>와 <border-style>)은 해당 속성(property)에 지정하였다.
• 다른 단어들은 키워드(keyword)들인데, 따옴표 없는 글자로 표시되었다.
• 슬래쉬(/) 와 컴마(,) 또한 글자로 표시되었다.
• 여러가지 나란히 된 수단은 그들 모든 것이 그 순서로 나와야 만 하는 것이다.
• 그들 중 하나가 나타나야 하는 선택적 항목은 바(|)로 구분하였다.
• 이중 바(A || B)는 A 또는 B 또는 둘 다, 명시된 순서로, 나타나야 하는 것을 의미한다.
• 괄호들([])은 구룹으로 묶기한 것이다.
• 나란히 나온 것은 이중 바들 보다 우선하고, 이중 바들은 다른 바보다 우선한다.
• 따라서 "a b | c || d e"는 "[ a b ] | [ c || [ d e ]]"와 같다.

각 타입(type), 키워드(keyword), 또는 괄호 안의 구룹은 다음과 같은 것들 중 하나의 수정자(modifier)가 따라 나올 수 있다.

• 별표 (*)는 앞의 타입(type), 단어(word) 또는 구룹이 0번 혹은 여러번 나올 수 있슴을 나타낸다.
• 더하기표(+)는 앞의 타입(type), 단어(word) 또는 구룹이 한번이상 나옴을 나타낸다.
• 물음표(?)는 앞의 타입(type), 단어(word) 또는 구룹이 선택적임을 나타낸다.
• 괄호 안 수치들({A,B})의 짝은 앞의 타입(type), 단어(word) 또는 구룹이 최소 A번 최대 B번 반복 됨을 나타낸다.

5-2.  글자(font) 속성들

글자(font) 속성들을 설정하는 것은 스타일쉬트 사용들 중 가장 보편적인 것이다. 불행햐게도, 잘 정의된 세계 공통적으로 수용되는 글꼴들의 분류가 없다는 것이다. 한가지 글꼴 가족(font family)에 적용되는 것이 다른것에서는 적용되지 않을 수 있다. 예를 들어 'italic'은 일반적인 기울어진 글자를 위하여 사용되나, 기울어진 글자들이 또한 Oblique, Slanted, Incline, Cursive 또는 Kursiv등으로 표시되기도 한다. 따라서 특정 글꼴(font) 선택 속성들로 특정 font를 지정하는 것이 간단치 않다.

CSS1는 그 속성들 글꼴들('font-family'), 글꼴 스타일('font-style'), 글꼴 변화('font-variant'), 글꼴 굵기('font-weight'), 글꼴 크기('font-size'), 'font'를 정의하고 있다.

5-2-1.  글자(font) 맞추기

글자(font) 속성들의 세계 공통적으로 수용되는 글꼴들의 분류가 없기 때문에, 글꼴(font face)들에 속성들을 맞추는(matching) 것을 주의 깊게 하여야 한다. 그 속성들은 그 마춤 과정의 결과들이 가능한 한 여러 사용도구들(같은 글꼴이 같이 표현됨을 가정하면서) 간에 일정하게 할 수 있도록 잘 정의된 순서로 맞춰줘야 한다.

1. 사용도구는 사용도구가 알고 있는 CSS1에 상응하는 모든 글자(font)들의 속성들의 데이터베이스를 만들고 접속한다. 사용도구는, 그 것이 지역적(locally)으로 설치(install)되었기 때문에, 혹은, 이전에 웹으로 부터 다운로드 받았가 때문에, 글자를 알고 있을 수 있다. 만일 두가지 글자가 꼭 같은 속성들을 가지면 하나는 무시한다.
2. 주어진 엘레멘트에서 그리고 그 엘레멘트의 각 속성은, 사용도구는 그 엘레멘트에 적용할 수 있는 글자 속성들을 조합한다(assemble). 완전한 속성들의 세트(set)를 사용하여, 사용도구들은 그 글꼴들('font-family') 속성을 임시적인 글꼴(font family)로 선택하여 사용한다. 나머지 속성들은 각 속성(property)에 설정된 마춤(matching) 기준(criteria)에 따라 그 family에 대하여 검정한다. 만일 이 맞춤이 모든 나머지 속성들에 맞으면, 그것이 주어진 엘레멘트의 맞는 글꼴(font face)이 된다.
3. 만일 글꼴들('font-family')들 중에 맞는 글꼴(font face)이 없으면, 두번째 단계로 진행한다. 만일 다음 가능한(alternative) 글꼴들('font-family')들 중에 맞는 글꼴이 있는가의 두번째 단계를 반복한다.
4. 만일 맞는 글꼴이 있으나, 현재의 글자를 표현할 수 없고, 추가적인 가능한 글꼴이 있으면, 다음 글꼴로 두번째 단계를 반복한다. 부록 C 글꼴와 글자 엔코딩을 참조하라.
5. 만일 두번째 단계에서 맞는 글꼴이 발견되지 않으면, 사용도구에 따른 디폴트 글꼴들('font-family')을 사용하여 두번째 단계를 반복하여 디폴트 글꼴 중에서 가장 잘 맞는 것을 찾기위하여 반복한다.

(위의 기능이 CSS1 속성들의 각 글자마다 재방문을 회피하기 위하여 적정화(optimized)될 수 있다.)

위 두번째 속성 맞춤(matching) 과정은 다음과 같다.

1. 글꼴 스타일('font-style')이 제일 먼저 시도된다. 사용도구의 글꼴(font) 데이터베이스에서 CSS 키워드(keyword) 'italic' (선호 됨) 또는 'oblique'로 라벨된 글꼴이 있으면 'italic'이 만족스러워 진다. 아니면 그 값들 꼭 맞는 것이 찾아져야 하고 그렇지 않으면 font-style 실패가 된다.
2. 다음 글꼴 변화('font-variant')가 시도된다. 'normal'을 'small-caps'로 라벨되지않는 글꼴과 맞춘다. 'small-caps'을 'small-caps'로 라벨된 글꼴과 맞춘다 matches(1). (2)는 small caps의 합성된(synthesized) 글꼴이다. 또는 (3)는 모든 소문자들이 대문자로 대체된(replaced) 글꼴이다. small-caps 글꼴은 정상 글꼴의 대문자들로 부터 전기적으로 비례적으로 합성(synthesized)할 수 있다.
3. 다음은 글꼴 굵기('font-weight')를 점검한다. 이는 실패하지 않는다.(아래 글꼴 굵기('font-weight')를 참조하라)
4. 글꼴 크기('font-size')는 사용도구에 따른 마진(margin)의 허용 범위(tolerance)에 맞춘다. (전형적으로, 크기(size)들을 비례적으로 변화시키는데(scale)는 가장 가까운 픽셀(pixel)로 반올림한다. 비트 단위로 구성된(bitmapped) 글꼴은 20%까지 크게 할 수 있다.) 다른 내용들, 예를 들어 'em'등 다른 속성들에서 값은 그 것이 사용하는 글꼴 크기('font-size') 값에 기초하고, 지정된 값으로 하지 않는다.

5-2-2.  글꼴들('font-family')

값: [[<family-name> | <generic-family>],]* [<family-name> | <generic-family>]
최초값:사용도구에 따라 다름
적용: 모든 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

이 값은 글꼴 가족(font family name) 그리고/또는 일반 글꼴(generic family name)의 적용 우선순위를 열거한 목록이다. 다른 CSS1 속성들과는 달리, 그 값은 컴마로 분리하고, 이는 서로 대체(alternative)한다는 것을 나타낸다. BODY { font-family: gill, helvetica, sans-serif }

두가지의 타입(type)들의 목록 값들이 있다.

<family-name>

선택된 글꼴들의 이름이다. 마지막 예제에서, "gill"과 "helvetica"는 긁꼴들(font family)이다.

<generic-family>

위의 예제에서, 마지막 값은 일반 글꼴(generic family) name이다. 다음 일반 글꼴(generic family)들이 정의 되었다.

• 'serif' (예를 들어 Times)
• 'sans-serif' (예를 들어 Helvetica)
• 'cursive' (예를 들어 Zapf-Chancery)
• 'fantasy' (예를 들어 Western)
• 'monospace' (예를 들어 Courier)

스타일쉬트는 설계자는 일반 글꼴(generic font family)을 마지막 대체(alternative) 글꼴로 제시하도록 추천한다.

글꼴 이름에 공백이 있으면 반드시 따옴표로 묶어야 한다. BODY { font-family: "new century schoolbook", serif } <BODY STYLE="font-family: 'My own font', fantasy">

만일 따옴표가 생략되면, 글꼴 이름의 앞과 뒤에나오는 공간을 무시고, 하나이상의 빈 공간은 하나의 빈 공간으로 간주된다.

font-family 표현 예제

5-2-3.  글꼴 스타일('font-style')

값: normal | italic | oblique
최초값: normal
적용: 모든 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

글꼴 스타일('font-style') 속성은 글꼴(font family) 안에서 normal(때로는 "roman" 또는 "upright"로 불리운다), 'italic'과 'oblique' 중에서 선택한다.

값 'normal'은 사용도구의 글꼴 데이터베이스에서 'normal'로 분류된 글자를 선택한다. 'oblique'는 'oblique'로 라벨된 글꼴을, 'italic'은 'italic'으로 라벨된 글꼴을 찾으며 없으면 'oblique'로 라벨된 것을 찾는다.

사용도구의 글꼴 데이터베이스에서 'oblique'로 라벨된 글꼴은 실제적으로 정상 글자를 전자적으로 기우려서 생성할 수 있다.

Oblique, Slanted 또는 Incline으로 이름지워진 글꼴들는 사용도구의 글꼴 데이터베이스에서 전형적으로 'Ioblique'로 라벨된다. Italic, Cursive 또는 Kursiv로 이름 지워 진 글꼴들은 전형적으로 'italic'으로 라벨된다. H1, H2, H3 { font-style: italic } H1 EM { font-style: normal }

위의 예제에서, 'H1' 안의 강조된 텍스트는 보통 글꼴로 나타 날 것이다.

5-2-4.  글꼴 변화('font-variant')

값: normal | small-caps
최초값: normal
적용: 모든 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

글꼴 안에서 다른 변형은 small-caps이다. small-caps 글꼴에서 소문자들은 대문자 비슷하게 나타난다. 그러나 작은 글꼴 크기에서는 약간 다른 비율들을 갖는다. 글꼴 변화('font-variant') 속성은 그 글꼴를 선택한다.

'normal' 값은 small-caps 글꼴을 선택하지 않고, 'small-caps'은 small-caps 글꼴을 선택한다. small-caps가 정상 글꼴로 부터 소문자를 대문자로 비율적(scale)으로 변환하여 만드는 것을 CSS1에서 수용(acceptable)한다. 그러나 필요한 것은 아니다. 마지막으로, 대문자들이 small-caps 글꼴을 위하여 사용될 수 있다.

다음 예제는 'H3' 엘레멘트 안에 small-caps로, 강조된 글자를 기울어진 oblique small-caps로 나타난다. H3 { font-variant: small-caps } EM { font-style: oblique }

글꼴 안에 old-style numerals, small-caps numerals, condensed 또는 expanded letters, 등 다른 종류의 변종(variant)들이 더 있을 수 있다. CSS1에는 이들을 선택하기 위한 속성들이 없다.

CSS1 핵심: 이 속성이 텍스트를 대문자로 변환을 설명한 바와 같이, 이와 같은 텍스트 변환('text-transform')의 적용이 고려된다.

5-2-5.  글꼴 굵기('font-weight')

값: normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900
최초값: normal
적용: 모든 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

글꼴 굵기('font-weight') 속성으 글꼴의 굵기를 선택한다. '100'에서 '900'의 그 값들은 순서대로 각 수치는 굵기를 지정하는데 뒤의 것이 앞의 것보다 더 어둡다. 키워드(keyword) 'normal'은 값 '400'에 해당하며, 'bold'는 값 '700'과 같다. 키워드(keyword) 'normal'과 'bold'는 글꼴 이름들과 수치 값과 자주 혼동되므로 위의 9 단계 값의 목록으로 하였다. P { font-weight: normal } /* 400 */ H1 { font-weight: 700 } /* bold */

'bolder' 와 'lighter' 값은 글꼴 굵기(weight)를 모체로 부터 전달된(inherited) 값에 상대적으로 선택한다. STRONG { font-weight: bolder }

하위(child) 엘레멘트들은 결과 굵기(weight)를 전달한다. 그러나 키워드 값을 전달하는 것은 아니다.

글꼴 데이터들은 전형적으로 하나이상의 속성들을 갖는데, 글꼴의 두께("weight")를 설명하도록 주어진 이름들의 값을 갖는다. 이들 두께(weight) 이름들은 세계 공통적으로 수용되는 것은 없다. 그 일차적인 임무는한 글꼴 안에서 다른 검은 정도로 글꼴를 구별하는 것이다. 여러 글꼴들사이에서는 대단히 변이가 많다. 예를 들어 굵은(bold) 것으로 생각되는 글꼴이, 그 디자인 안에서 그 글꼴의 보통("normal")이 얼마나 검은가에 따라, Regular, Roman, Book, Medium, Semi-, DemiBold, Bold, 또는 Black로 지정된다. 이름들의 사용에 표준이 없으므로, 이 굵기(weight) 속성값들은 CSS1에서 수치 값으로 주어졌다. 여기서 값 '400' (='normal')이 그 글꼴의 보통("normal") 글꼴에 해당하는 것이다. 이 굵기(weight) 이름은 그 글꼴에서 전형적으로 Book, Regular, Roman, Normal 또는 때로는 Medium과 같이 주어진다.

그 글꼴에서 다른 굵기들과의 연관은 그 수치 굵기(weight)의 값들의 검은 정도의 순서를 유지하는 것 만을 목표로 하였다. 그러나 다음 체계는 전형적인 경우에 어떻게 지정하는가를 보여준다.

• 만일 글꼴이 이미 9 단계(예를 들어 OpenType에서와 같이) 수치 값들을 사용하면, 그 글꼴의 두께(weight)는 직접 그에 의해 표현하여야 한다.
• 만일 글꼴에 Medium으로 라벨된 것과 Book, Regular, Roman 또는 Normal로 라벨된 것이 있으면, 그 Medium은 일반적으로 값 '500'으로 할당한다.
• 글꼴이 "Bold"로 라벨된 것은 자주 그 굵기(weight) 값 '700'에 상응한다.
• 만일 글꼴 안에서 9 단계 보다 적은 단계로 되어있으면, 빈 것("holes")을 채우는 디폴트 기능은 다음에 따른다. 만일 '500'이 지정되지 않았으면, 이것은 같은 글꼴에서 '400'으로 설정한다. 만일 그 값들이 '600', '700', '800' 또는 '900' 중 어느 것도 지정되지 않았으면, 같은 글꼴에서 다음번 검은 키워드(keyword)를 지정한다. 그 중 어느 것이 지정되어 있지 않으면, 그 다음 엷은(lighter) 것이 된다. '300', '200' 또는 '100' 값이 지정되지 않았으면, 그 다음 엷은(lighter) 것의 키워드(keyword)를 지정한다. 지정되었으면 그 다음 검은 것이 지정된다.

다음 두가지 예제들은 이 과정을 설명한다. "예제1" 글꼴에서 4 가지 굵기 단계를 가정한다. 엷은 것에서 검은(어두운) 것으로의 순서는 Regular, Medium, Bold, Heavy이다. "예제2" 글꼴에서 6 가지 굵기 단계를 가정한다. 여기서는 Book, Medium, Bold, Heavy, Black, ExtraBlack 순서가 된다. 두번째 예제에서 "예제2 ExtraBlack"를 지정하지 않기로 결정하였음을 주시하라. 가능한 글꼴 |지정 | 기타 ------------------+-----+------------------- "예제1 Regular" | 400 | 100, 200, 300 "예제1 Medium" | 500 | "예제1 Bold" | 700 | 600 "예제1 Heavy" | 800 | 900 가능한 글꼴 |지정 | 기타 ------------------+-----+------------------- "예제2 Book" | 400 | 100, 200, 300 "예제2 Medium" | 500 | "예제2 Bold" | 700 | 600 "예제2 Heavy" | 800 | "예제2 Black" | 900 | "예제2 ExtraBlack"|none |

상대 키워드(keyword) 'bolder'와 'lighter'이 더 검은(darken, 어두운) 또는 더 엷은(lighten) 표면으로 그 글꼴 안에서 지정하는 것을 의도하였으므로, 또한 한 글꼴이 이 모든 굵기의 기호적 값들을 가지고 있지 않을 수 있기 때문에, 'bolder'에 마춤은 사용자에게 그 글꼴 안에서 가능한 그 다음 검은 표면을 사용하게 하였다. 그리고 'lighter'로 그 글꼴 안에서 그 다음 엷은 표면과 맞추게(matching) 하였다. 상대적(relative)인 키워드(keyword) 'bolder'와 'lighter'의 의미는 정확하게 다음과 같다.

• 'bolder'는 전달된(inherited) 값보다 한 단계 더 검은 다음 번 두께(weight)를 선택한다. 만일 그런 두께(weight)가 없으면, 단순히 글꼴의 변동없이 다음 번 검은 수치 값을 지정한다. 전달된 값이 '900'인 경우에는 결과도 '900'이다.
• 'lighter'도 이와 유사하다. 그러나 반대 방향으로 작용한다. 전달된(inherited) 값보다 한 단계 더 엷은 다음 번 두께(weight)를 선택한다. 만일 그런 두께(weight)가 없으면, 단순히 글꼴의 변동없이 다음 번 검은 수치 값을 지정한다.

각 글꼴 굵기('font-weight') 값이 더 검은 표면를 표현한다는 보장은 없다. 예를 들어, 일부 글꼴들은 정상(normal)과 굵은(bold) 표면 만을 갖는다. 다른 것들은 8 단계 다른 표면을 두께(weight)들은 갖는다. 사용도구가 글꼴 안에서 어떤 두께(weight) 값을 어떻게 글꼴 표면으로 표현할 것이라는 보증은 없다. 보증은 단지, 더 엷은 값들로 주어진 표면보다, 주어진 값의 표면이 덜 검지 않다는 것이다.

5-2-6.  글꼴 크기('font-size')

값: <absolute-size> | <relative-size> | <길이> | <백분율>
최초값: medium
적용: 모든 엘레멘트들
전달: 전달 됨
백분율 값들: 모체 엘레멘트의 글꼴 크기(font size)에 대해

절대 크기(<absolute-size>)

키워드(keyword) <absolute-size>는 사용도구에 의하여 계산되고 유지되는 글꼴 크기 표(table)의 색인이다. 가능한 값은: [ xx-small | x-small | small | medium | large | x-large | xx-large ]이다. 컴퓨터 화면에서 인접 색인들 가운데 1.5 배율(scaling factor)이 암시된다. 만일 보통('medium') 크기가 10pt이면 'large' 글꼴는 15pt가 된다는 것이다. 다른 메디아(media)에서는 다른 배율(scaling factor)이 될 수 있다. 또한 사용도구는 그 표(table)를 계산하는데 가능한 글꼴들과 그들의 품질을 고려하여야 한다. 그 표는 글꼴에 따라 다를 수 있다.

상대 크기(<relative-size>)

키워드(keyword) <relative-size>는 모체 엘레멘트의 글꼴 크기와 글꼴 크기 표(table)의 상대적인 관계이다. 가능한 값은: [ larger | smaller ]이다. 예를 들어, 만일 모체 엘레멘트가 글꼴 크기 'medium'을 가지면, 'larger'는 현재 엘레멘트의 글꼴 크기를 'large'로 만들 것이다. 만일 모체 엘레멘트의 크기가 표(table)의 글자들의 크기와 비슷하지 않으면, 사용도구가 글자들 간의 비율 또는 가장 가까운 것을 택하는 것은 자유이다. 사용도구는 만일 수치 값이 키워드(keyword) 범위를 벋어나면, 추가적으로 표의 값을 계산해야 할 수 있다.

엘레멘트의 글꼴 크기를 계산하는데 길이와 백분율 값들은 글꼴 크기 표(table)에서 고려하지 않는다.

음수는 허용되지 않는다.

모든 다른 속성들에서, 'em' 과 'ex' 길이 값들은 현재 엘레멘트의 글꼴 크기를 참조한다. 그 글꼴 크기('font-size') 속성(property)에서, 이들 길이 단위들은 모체 엘레멘트의 글꼴 크기를 참조한다.

문장에 따라서 적용될 때 지정한 크기를 다시 해석할 수 있슴을 주지하라. 예를 들어, 비디오(VR)에서 글꼴는 틀어짐을 고려하여 다른 글꼴 크기를 가질 수 있다.

글꼴 크기의 예제 P { font-size: 12pt; } BLOCKQUOTE { font-size: larger } EM { font-size: 150% } EM { font-size: 1.5em }

만일 암시된 배율(scaling factor) 1.5를 사용한다면 뒤의 3 가지는 모두 같다.

5-2-7.  글꼴('font')

값: [ <font-style> || <font-variant> || <font-weight> ]? <font-size> [ / <line-height> ]? <font-family>
최초값: 약식속성들에는 정의되지 않음
적용: 모든 엘레멘트들
전달: 전달 됨
백분율 값들: <font-size>와 <line-height>에 허용됨

글꼴('font') 속성은 같은 스타일쉬트에서 글꼴 스타일('font-style'), 글꼴 변화('font-variant'), 글꼴 굵기('font-weight'), 글꼴 크기('font-size'), 줄높이('line-height'), 글꼴들('font-family')를 설정하기 위한 약식속성이다. 이 속성의 문법은 관계된 글꼴들의 복수 속성들을 지정하는 전통적인 문구에 기초한다.

가능한 값과 최초값을 지정하기 위하여 이전에 정의된 속성들을 참조하라. 값이 주어지지 않는 속성들은 최초값으로 지정된다. P { font: 12pt/14pt sans-serif } P { font: 80% sans-serif } P { font: x-large/110% "new century schoolbook", serif } P { font: bold italic large Palatino, serif } P { font: normal small-caps 120%/120% fantasy }

두번째 명령(rule)에서, 글꼴 크기(font size) 백분율 값 ('80%')은 모체 엘레멘트의 글꼴 크기를 참조한다. 세번째 명령에서, 줄높이 백분율은 그 엘레멘트 자체의 글꼴 크기를 참조한다.

앞 3 개의 명령에서, 글꼴 스타일('font-style'), 글꼴 변화('font-variant')와 글꼴 굵기('font-weight')는 명시적으로 지정하지 않았다. 이는 모든 3 개의 예제에서 그들의 최초값 ('normal')이 설정되어 있다는 의미이다. 네번째 명령(rule)에서 글꼴 굵기('font-weight')가 'bold'로 설정되었는데, 그 글꼴 스타일('font-style')을 'italic'과 글꼴 변화('font-variant')를 'normal'로 명시적으로 설정하였다.

다섯번째 예제는 글꼴 변화('font-variant')를 ('small-caps')로 설정하였는데, 그 글꼴 크기('font-size')는 모체 글꼴의 120%, 줄높이('line-height')는 글꼴 크기의 120%, 그리고 글꼴들('font-family')는 'fantasy'이다. 키워드(keyword) 'normal'이 나머지 두가지 속성들, 글꼴 스타일('font-style')과 글꼴 굵기('font-weight')에 설정된다.

5-3.  색상(color)과 엘레멘트의 배경(background) 속성

이들 속성들은 색상(자주 foreground color로 불리운다)과 배경(background:내용이 표현되는 표면)을 지정한다. 배경에 배경색 그리고/또는 배경 이미지를 설정할 수 있다. 또한 그 이미지의 위치, 반복, 고정되는지 굴리는지(scroll)를 그 화면에 상대적으로 설정할 수 있다.

색상('color') 속성은 일반적으로 전달(inherit)되며, 배경(background) 속성들은 전달되지 않는다. 그러나 그 모체 엘레멘트의 배경(background)은 배경색('background-color')에 최초값 투명('transparent')이 설정되어 있기 때문에 디폴트로 전체에 나타난다.

5-3-1.  색상('color')

값: 색상(<color>)
최초값:사용도구에 따라 다름
적용: 모든 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

이 속성은 엘레멘트의 텍스트 색상(자주 foreground color 로 불리움)을 지정한다. 여러가지로 적색을 지정할 수 있다. EM { color: red } /* 자연 언어 */ EM { color: rgb(255,0,0) } /* RGB 범위 0-255 */

항목 6.3 가능한 색상값들을 참조하라. HTML 색상표도 참조하라.

5-3-2.  배경색('background-color')

값: <color> | transparent
최초값: transparent(투명)
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

이 속성은 엘레멘트의 배경색(background color)을 지정한다. H1 { background-color: #F00 }

5-3-3.  배경 이미지('background-image')

값: <url> | none
최초값: none
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

이 속성은 엘레멘트의 배경 이미지(background image)를 설정한다. 배경 이미지가 설정되면, 그 이미지가 없을 때를 대비하여 표현될 배경색을 동시에 지정하여야 한다. 이미지가 유효하면 배경색 위에 표현된다. BODY { background-image: url(marble.gif) } P { background-image: none }

5-3-4.  배경 반복('background-repeat')

값: repeat | repeat-x | repeat-y | no-repeat
최초값: repeat(반복)
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

만일 배경 이미지가 지정되면, 배경 반복('background-repeat')의 값은 어떻게 그 이미지를 반복할 것인가 혹은 반복하지 않을 것인가를 지정한다.

값 'repeat'는 이미지가 수평, 수직 양 방향으로 반복되는 것을 의미한다. 값 'repeat-x' ('repeat-y')는 이미지가 수평(수직) 방향으로 반복되는 것으로 이미지가 한 방향으로 띠를 형성한다. 값 'no-repeat'로는 반복 없이 한번 만 표현된다. BODY { background: red url(pendant.gif); background-repeat: repeat-y; }

위의 예제에서, 이미지는 수직적으로 반복된다.

5-3-5.  배경 첨부('background-attachment')

값: scroll | fixed
최초값: scroll(굴림)
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

만일 배경 이미지가 지정되면, 배경 첨부('background-attachment') 값은 지정한다. 이미지를 화면에 고정시킬 것인가 내용에 따라 굴릴(scroll) 것인가를 지정한다. BODY { background: red url(pendant.gif); background-repeat: repeat-y; background-attachment: fixed; }

CSS1 핵심: 사용도구들은 'fixed'를 'scroll'로 처리할 수 있다. 그러나, 제작자가 'fixed' 만을 지원하는 브라우저들에게 이미지를 제공할 수 있는 방법이 없으므로, 최소한 HTML과 BODY 엘레멘트들에서 바르게 'fixed'로 처리할 것을 추천한다. (항목 7 참조.)

5-3-6.  배경 위치('background-position')

값: [<백분율> | <길이>]{1,2} | [top | center | bottom] || [left | center | right]
최초값: 0% 0%
적용: 블럭레벨(block-level)과 대체된(replaced) 엘레멘트들
전달: 안됨
백분율 값들: 그 엘레멘트 자체의 크기를 참조하라

만일 배경 이미지가 지정되면, 배경 위치('background-position') 값은 최초 위치를 지정한다.

값이 '0% 0%'이면, 이미지의 위 왼쪽 모퉁이가 그 엘레멘트의 내용이 들어가는 박스(box)의 위 왼쪽 모퉁이에 위치 한다 (말하자면, 그 padding, border 또는 margin에 의하여 둘려 쌓인 박스가 아님). 값 '100% 100%'는 이미지의 아래 오른쪽 모퉁이가 그 엘레멘트의 아래 오른쪽 모퉁이에 위치 시킨다. 값 '14% 84%'는 이미지의 가로 14% 아래로 84% 지점에 그 엘레멘트의 가로 14% 아래로 84% 지점을 위치시킨다.

값 '2cm 2cm'는 이미지의 왼쪽 맨 위 지점을 그 엘레멘트의 왼쪽 끝에서 오른쪽으로 2cm, 맨 위에서 아래로 2cm 지점에 위치시킨다.

만일 백분율 또는 길이 값이 하나 만 지정되면, 수평 지점 만 설정되고 수직 위치는 50%로 설정된다. 두 값이 설정될 때 수평 위치가 먼저 나온다. 예를 들어 '50% 2cm'와 같이 길이와 백분율 값의 조합도 가능하다. 위치 값의 음수도 허용된다.

배경 이미지의 위치를 지정하기 위하여 키워드(keyword) 값들을 사용할 수도 있다. 키워드는 백분율 값이나 길이 값과 조합할 수 없다. 가능한 키워드들과 그 해석은 다음과 같다.

• 'top left', 'left top' 모두 '0% 0%'와 같다.
• 'top', 'top center', 'center top' 모두 '50% 0%'와 같다.
• 'right top', 'top right' 모두 '100% 0%'와 같다.
• 'left', 'left center', 'center left' 모두 '0% 50%'와 같다.
• 'center', 'center center' 모두 '50% 50%'와 같다.
• 'right', 'right center', 'center right' 모두 '100% 50%'와 같다.
• 'bottom left', 'left bottom' 모두 '0% 100%'와 같다.
• 'bottom', 'bottom center', 'center bottom' 모두 '50% 100%'와 같다.
• 'bottom right', 'right bottom' 모두 '100% 100%'와 같다.

예제: BODY { background: url(banner.jpeg) right top } /* 100% 0% */ BODY { background: url(banner.jpeg) top center } /* 50% 0% */ BODY { background: url(banner.jpeg) center } /* 50% 50% */ BODY { background: url(banner.jpeg) bottom } /* 50% 100% */

만일 배경 이미지가 그 화면에 대해 고정(fixed)되면(위 배경 첨부('background-attachment') 속성 참조), 그 이미지는 그 엘레멘트 대신 그 화면에 대해 위치한다. 예를 들어: BODY { background-image: url(logo.png); background-attachment: fixed; background-position: 100% 100%; }

위의 예제에서, 그 이미지는 그 화면의 오른쪽 맨 아래 위치한다.

5-3-7.  배경('background')

값: <background-color> || <background-image> || <background-repeat> || <background-attachment> || <background-position>
최초값: 약식속성들에는 정의되지 않음
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: <background-position>에 허용됨

그 배경('background') 속성은 개별 배경 속성들, 말하자면, 배경색('background-color'), 배경 이미지('background-image'), 배경 반복('background-repeat'), 배경 첨부('background-attachment'), 배경 위치('background-position')을 한 곳에 지정하는 약식속성이다.

이 배경('background') 속성들의 가능한 값들은 개별 속성들의 모든 가능한 값들이다. BODY { background: red } P { background: url(chess.png) gray 50% repeat fixed }

이 배경('background') 속성은 항상 모든 개별 배경 속성들을 설정한다. 위 예제에서 첫번째 명령(rule)은 배경색('background-color') 값 만 갖고, 다른 개별 속성들은 그들의 최초값에 의하여 설정된다. 두번째 명령(rule)에는 모든 개별 속성들이 지정되었다.

5-4.  텍스트(text) 속성들

5-4-1.  단어 간격('word-spacing')

값: normal | <길이>
최초값: normal
적용: 모든 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

이 길이 단위는 단어 간격의 디폴트 공간에 추가하여 단어 간격의 공간을 지정한다. 값은 음수가 될 수 있으나, 적용에 따른 범위가 있을 수 있다. 사용도구는 정확한 간격 띄우기 기능을 선택하는데 방법은 자유이다. 단어 간격은 또한 정렬에 의하여 영향 받을 수 있다. 텍스트 정렬('text-align') 속성(property)값 참조. H1 { word-spacing: 1em }

여기서, 'H1' 엘레멘트들 안에서 단어 간격('word-spacing')은 '1em' 만큼 증가된다.

CSS1 핵심: 사용도구들은 단어 간격('word-spacing')의 어떤 값을 'normal'로 해석할 수 있다. (항목 7 참조.)

5-4-2.  글자 간격('letter-spacing')

값: normal | <길이>
최초값: normal
적용: 모든 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

이 길이 단위는 글자 간격의 디폴트 공간에 추가하여 글자 간격의 공간을 지정한다. 값은 음수가 될 수 있으나, 적용에 따른 범위가 있을 수 있다. 사용도구는 정확한 간격 띄우기 기능을 선택하는데 방법은 자유이다. 글자 간격은 또한 정렬('align' 속성값)에 의하여 영향 받을 수 있다. BLOCKQUOTE { letter-spacing: 0.1em }

여기서 'BLOCKQUOTE' 엘레멘트들 안에서 각 글자의 글자 간격('letter-spacing')은 '0.1em' 만큼씩 증가된다.

값 'normal'로, 사용도구들은 글자들의 간격을 적당히 수정할 수 있다. 그러나 만일 글자 간격('letter-spacing')을 <길이> 값으로 명시하면 그렇지 않다. BLOCKQUOTE { letter-spacing: 0 } BLOCKQUOTE { letter-spacing: 0cm }

결과적인 글자 간격이 디폴트 간격과 같지 않으면 사용도구들은 그 것을 사용하지 말아야 한다.

CSS1 핵심: 사용도구들은 글자 간격('letter-spacing')의 어떤 값을 'normal'로 해석할 수 있다. (항목 7 참조.)

5-4-3.  텍스트 장식('text-decoration')

값: none | [ underline || overline || line-through || blink ]
최초값: none
적용: 모든 엘레멘트들
전달: 안됨, 그러나 아래 설명을 보라
백분율 값들: 없슴

이 속성은 엘레멘트의 텍스트에 추가하는 장식(decoration)을 지정한다. 만일 이 엘레멘트가 텍스트를 가지고 있지 않으면(예를 들어 HTML에서 'IMG' 엘레멘트), 또는 이 것이 빈(empty) 엘레멘트(예를 들어 '<EM></EM>')이면, 이 속성은 아무 효과도 없다. 값 'blink'는 텍스트을 깜빡(blink)거리게 한다.

텍스트 장식을 위하여 색상이 필요하면, 'color' 속성값이 되어야 한다.

이 속성은 전달(inherit)되지 않는다. 그러나 엘레멘트들은 그 모체와 일치하여야 한다. 예를 들어, 만일 엘레멘트가 밑줄그어(underlined) 졌으면, 그 줄이 하위(child) 엘레멘트들로 확장되어야 한다. 밑줄의 색상은, 엘레멘트들이 다른 색상('color') 값을 가지고 있더라도 택스트 색상과 같다. A:link, A:visited, A:active { text-decoration: underline }

위 예제에서 'A' 엘레멘트들로서 'HREF' 애트리뷰트를 가진 모든 연결들 텍스트는 밑줄 쳐진다.

사용도구들은 키워드(keyword) 'blink'를 인식하여 하나, 깜빡이는 효과를 반드시 지원할 필요는 없다.

5-4-4.  수직 정렬('vertical-align')

값: baseline | sub | super | top | text-top | middle | bottom | text-bottom | <백분율>
최초값: baseline
적용: 인라인(inline) 엘레멘트들
전달: 안됨
백분율 값들: 그 엘레멘트 자체의 줄높이('line-height') 참조

이 속성은 엘레멘트의 수직 위치에 영향을 준다. 키워드(keyword)가 설정되면 모체 엘레멘트에 상대적이다.

'baseline'

그 모체의 baseline으로 그 엘레멘트의 기초라인(baseline: 또는 그 엘레멘트가 baseline을 갖고 있지 않으면 맨아래( bottom) 정렬(align)한다.

'middle'

그 모체의 기초라인(baseline) 더하기 x-height의 반에 그 엘레멘트의 중심선을 수직으로 정렬한다(image에서 전형적).

'sub'

그 엘레멘트 아래첨자(subscript)

'super'

그 엘레멘트의 위첨자(superscript)

'text-top'

모체 엘레멘트의 글꼴 맨 위(top)에 그 엘레멘트의 맨 위에 정렬한다.

'text-bottom'

모체 엘레멘트의 글꼴 맨 아래(bottom)에 그 엘레멘트의 맨 위에 정렬한다.

다른 일단의 속성들은 그 엘레멘트의 일 부분인 양식화(formatted) 라인에 상대적이다.

'top'

그 줄에서 가장 키 큰(tallest) 엘레멘트를 그 엘레멘트의 맨 위(top)에 정렬한다.

'bottom'

그 줄에서 가장 낮은(lowest) 엘레멘트를 그 엘레멘트의 맨 아래(bottom)에 정렬한다.

'top'과 'bottom' 정렬은 사용하는데 있어서, 엘레멘트에 관련된 루프(loop) 형성하는데서, 해결하지 못하는 상황들이 발생할 수 있다.

백분율 값들은 그 엘레멘트 자체의 줄높이('line-height') 속성값을 참조한다. 이들은 엘레멘트의 기초라인(baseline)을, 그 모체의 기초라인에서부터, 지정한 양(amount) 만큼 끌어 올린다. 기초라인(baseline)이 없으면 바닥(bottom)라인에 적용한다. 음수값이 가능하다. 예를 들어, 값 '-100%'는 그 엘레멘트의 기초라인이 다음 줄의 텍스트가 와야하는 기초라인에서 끝나도록 그 엘레멘트를 낮춘다. 이것은 기초라인을 갖고 있지 않는 엘레멘트들(글자들 위치에서 사용되는 이미지들 등)의 수직 위치에 정밀한 제어를 허용한다.

향후 CSS 버전에서는 이 속성(property)값으로 <길이>가 허용될 것으로 기대된다.

5-4-5.  텍스트 변환('text-transform')

값: capitalize | uppercase | lowercase | none
최초값: none
적용: 모든 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

'capitalize'

각 단어의 첫글자을 대문자(uppercase)로 바꿈

'uppercase'

엘레멘트의 모든 글자들을 대문자(uppercase)로 바꿈

'lowercase'

엘레멘트의 모든 글자들을 소문자(lowercase)로 바꿈

'none'

전달(inherit)된 값을 그 대로

실제적인 대소문자 변환은 인간언어에 따라 다르다. [4] 엘레멘트의 언어 찾기를 참조하라. HTML의 언어정보와 글자방향도 참조하라. H1 { text-transform: uppercase }

위의 예제에서 'H1' 엘레멘트들에서 텍스트을 대문자로 변환한다.

CSS1 핵심: 영어(Latin-1) 레파토리(repertoire)의 글자들이 아닌 경우와, 엘레멘트들이 언어들에서 그 변환이 Unicode [8]의 대소문자 변환 표(case-conversion table)에 의해 지정된 것과 다른 경우에, 사용도구들은 텍스트 변환('text-transform')을 처리하지 않고 무시할 수 있다.

5-4-6.  텍스트 정렬('text-align')

값: left | right | center | justify
최초값:사용도구에 따라 다름
적용: 블럭레벨(block-level) 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

이 속성은 엘레멘트 안에서 텍스트가 어떻게 정렬(align)할 것인가를 지정한다. 실제적인 적용 기능은 사용도구와 인간언어에 따라 다르다.

예제: DIV.center { text-align: center }

텍스트 정렬('text-align')이 전달(inherit)되기 때문에, 'CLASS=center'를 갖고 있는 'DIV' 엘레멘트 안에 있는 모든 블럭레벨(block-level) 엘레멘트들 가운데(center) 위치한다. 정렬은 그 화면에 대한 것이 아니고, 그 엘레멘트의 너비(width)에 상대적인 것이다. 만일 'justify'가 지원되지 않으면, 사용도구는 대안을 제공할 것이다. 전형적으로 서구 언어에서 이것은 'left'가 된다.

CSS1 핵심: 그 엘레멘트의 디폴트 쓰는 방향이 왼쪽에서 오른쪽으로(left-to-right)인지 오른쪽에서 왼쪽으로(right-to-left)인지에 따라, 사용도구들은 'justify'를 'left' 또는 'right'로 취급할 수 있다.

5-4-7.  텍스트 들여쓰기('text-indent')

값: <길이> | <백분율>
최초값: 0
적용: 블럭레벨(block-level) 엘레멘트들
전달: 전달 됨
백분율 값들: 모체 엘레멘트의 너비(width) 참조

이 속성은 양식화된 줄의 앞에 나타도록 들여쓰기(indent)를 지정한다. 텍스트 들여쓰기('text-indent')의 값은 음수가 될 수 있으나 적용에 따라 한계가 있을 수 있다. 들여쓰기는 HTML의 'BR'와 같은 줄바꿈과 같이 다른 것에 의하여 줄바꿈하는 엘레멘트의 중간에 삽입되는 것은 아니다.

예제: P { text-indent: 3em }

5-4-8.  줄높이('line-height')

값: normal | <수치> | <길이> | <백분율>
최초값: normal
적용: 모든 엘레멘트들
전달: 전달 됨
백분율 값들: 그 엘레멘트 자체의 글꼴 크기(font size)에 상대적이다.

이 속성은 인접한 라인들의 기초라인(baseline)들 간의 거리를 지정한다.

수치 값이 지정되면, 그 줄높이는 현재 엘레멘트의 글꼴 트기(font size) 곱하기 수치 값이 된다. 이는 백분율 값과는 전달(inherit)에서 다르다. 수치 값이 지정되면, 하위(child) 엘레멘트들은, 해당 값이 전달되는 것이 아니고, 그 자체의 배율(factor)이 전달(inherit)된다. 백분율과 다른 단위들을 참조하라.

음수는 허용되지 않는다.

아래 예제에서 이 세가지는 같은 줄높이 결과를 준다. DIV { line-height: 1.2; font-size: 10pt } /* 수치 */ DIV { line-height: 1.2em; font-size: 10pt } /* 길이 */ DIV { line-height: 120%; font-size: 10pt } /* 백분율 */

값 'normal'은 줄높이('line-height')를 그 엘레멘트 글꼴의 합리적인 값을 설정한다. 사용도구들은 값 'normal'로 수치 범위 1.0과 1.2사이의 수치 설정을 암시한다.

어떻게 줄높이가 블럭레벨(block-level) 엘레멘트의 양식화에 영향하는가(항목 4.4)를 참조하라.

5-5.  박스(box) 속성들

이 박스(box) 속성들은 엘레멘트들을 대표하는 박스들의 크기(size), circumference, 위치(position)를 지정한다. 양식화 모델(항목 4)에서 박스(box) 속성들의 사용 방법의 예를 참조하라.

margin 속성들은 엘레멘트의 마진을 설정한다. 다른 마진 속성들은 그 해당 면(side) 만을 설정하는데 반해, 이 'margin' 속성은 모든 4 면들을 위하여 마진(margin)들을 설정한다.

padding 속성들은 테두리(border)와 내용(content: 예를 들어, text 또는 image)사이에 얼마나 많은 공백을 삽입할 것인가를 지정한다. 다른 padding 속성들은 해당 면(side) 만을 설정하는데 반해, 패딩('padding') 속성은 모든 4 면의 padding들을 설정한다.

border 속성들은 엘레멘트의 테두리(border)들을 설저한다. 각 엘레멘트는 4개의 테두리들를 갖으며, 각 면(side)에 하나씩 갖고, 너비(width), 색상(color), 스타일(style)이 지정된다.

너비('width')와 높이('height') 속성들은 그 박스(box) 크기를 지정하며, 유동('float')과 'clear' 속성들이 엘레멘트들의 위치를 변경시킬 수 있다.

5-5-1.  위쪽 마진('margin-top')

값: <길이> | <백분율> | auto
최초값: 0
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 가장 가까운 조상(ancestor) 블럭레벨(block-level)의 너비를 참조한다.

이 속성은 엘레멘트의 위쪽 마진(top margin)을 설정한다. H1 { margin-top: 2em }

음수가 허용되나 적용에 따라 한계가 있을 수 있다.

5-5-2.  오른쪽 마진('margin-right')

값: <길이> | <백분율> | auto
최초값: 0
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 가장 가까운 조상(ancestor) 블럭레벨(block-level)의 너비를 참조한다.

이 속성은 엘레멘트의 오른쪽 마진을 설정한다. H1 { margin-right: 12.3% }

음수가 허용되나 적용에 따라 한계가 있을 수 있다.

5-5-3.  아래쪽 마진('margin-bottom')

값: <길이> | <백분율> | auto
최초값: 0
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 가장 가까운 조상(ancestor) 블럭레벨(block-level)의 너비를 참조한다.

이 속성은 엘레멘트의 아래쪽 마진을 설정한다. H1 { margin-bottom: 3px }

음수가 허용되나 적용에 따라 한계가 있을 수 있다.

5-5-4.  왼쪽 마진('margin-left')

값: <길이> | <백분율> | auto
최초값: 0
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 가장 가까운 조상(ancestor) 블럭레벨(block-level)의 너비를 참조한다.

이 속성은 엘레멘트의 왼쪽 마진을 설정한다. H1 { margin-left: 2em }

음수가 허용되나 적용에 따라 한계가 있을 수 있다.

5-5-5.  마진('margin')

값: [ <길이> | <백분율> | auto ]{1,4}
최초값: 약식속성들에는 정의되지 않음
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 가장 가까운 조상(ancestor) 블럭레벨(block-level)의 너비를 참조한다.

'margin' 속성은 같은 스타일쉬트에서 위쪽 마진('margin-top'), 오른쪽 마진('margin-right'), 아래쪽 마진('margin-bottom'), 왼쪽 마진('margin-left')를 설정하는 약식속성이다.

만일 4 길이의 값들이 지정되면, 각 값은 top, right, bottom, left에 각각 적용된다. 하나의 값 만 지정되면 모든 면(side)들에 적용되고, 두 값이나 세 값들이 지정되면, 지정되지 않은 값은 반대편 면에서 택한다. BODY { margin: 2em } /* 모든 마진(margin)들을 2em로 */ BODY { margin: 1em 2em } /* top & bottom=1em, right & left = 2em */ BODY { margin: 1em 2em 3em } /* top=1em, right=2em, bottom=3em, left=2em */

위의 마지막 예제는 아래 예제와 같다. BODY { margin-top: 1em; margin-right: 2em; margin-bottom: 3em; margin-left: 2em; /* 반대편(right) 면에서 복사 */ }

음수가 허용되나 적용에 따라 한계가 있을 수 있다.

5-5-6.  위쪽 패딩('padding-top')

값: <길이> | <백분율>
최초값: 0
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 가장 가까운 조상(ancestor) 블럭레벨(block-level)의 너비를 참조한다.

이 속성은 엘레멘트의 위쪽 패딩을 설정한다. BLOCKQUOTE { padding-top: 0.3em }

Padding 값들은 음수가 될 수 없다.

5-5-7.  오른쪽 패딩('padding-right')

값: <길이> | <백분율>
최초값: 0
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 가장 가까운 조상(ancestor) 블럭레벨(block-level)의 너비를 참조한다.

이 속성은 엘레멘트의 오른쪽 패딩을 설정한다. BLOCKQUOTE { padding-right: 10px }

Padding의 음수값은 허용되지 않는다.

5-5-8.  아래쪽 패딩('padding-bottom')

값: <길이> | <백분율>
최초값: 0
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 가장 가까운 조상(ancestor) 블럭레벨(block-level)의 너비를 참조한다.

이 속성은 엘레멘트의 아래쪽 패딩을 설정한다. BLOCKQUOTE { padding-bottom: 2em }

Padding 음수값은 허용되지 않는다.

5-5-9.  왼쪽 패딩('padding-left')

값: <길이> | <백분율>
최초값: 0
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 가장 가까운 조상(ancestor) 블럭레벨(block-level)의 너비를 참조한다.

이 속성은 엘레멘트의 왼쪽 패딩을 설정한다. BLOCKQUOTE { padding-left: 20% }

Padding은 음수값은 허용되지 않는다.

5-5-10.  패딩('padding')

값: [ <길이> | <백분율> ]{1,4}
최초값: 약식속성들에서는 허용되지 않음
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 가장 가까운 조상(ancestor) 블럭레벨(block-level)의 너비를 참조한다.

패딩('padding') 속성은 한 스타일쉬트에서 위쪽 패딩('padding-top'), 오른쪽 패딩('padding-right'), 아래쪽 패딩('padding-bottom'), 왼쪽 패딩('padding-left')을 지정하는 약식속성이다.

만일 4 길이의 값들이 지정되면, 각 값은 top, right, bottom, left에 각각 적용된다. 하나의 값 만 지정되면 모든 면(side)들에 적용되고, 두 값이나 세 값들이 지정되면, 지정되지 않은 값은 반대편 면에서 택한다.

padding 지역의 표면은 배경('background') 속성(property)으로 지정한다. H1 { background: white; padding: 1em 2em; }

위 예제에서 '1em'이 수직 padding(위쪽 패딩('padding-top'), 아래쪽 패딩('padding-bottom'))에, '2em'이 수평(오른쪽 패딩('padding-right'), 왼쪽 패딩('padding-left'))에 설정된다. 'em' 단위는 엘레멘트의 글꼴 크기(font size)에 상대적이며 '1em'은 사용하고 있는 글꼴 크기와 같다.

Padding 음수값은 허용되지 않는다.

5-5-11.  위쪽 테두리 두께('border-top-width')

값: thin | medium | thick | <길이>
최초값: 'medium'
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

이 속성은 엘레멘트 너비의 위쪽 테두리(border)를 설정한다. 너비의 키워드(keyword) 값들은 사용도구에 따라 다르나, 'thin' <= 'medium' <= 'thick' 공식이 성립된다.

이 키워드(keyword) 너비들는 한 문서 전체에 고정되어 적용된다. H1 { border: solid thick red } P { border: solid thick blue }

위의 예제에서, 'H1'과 'P' 엘레멘트들은 글꼴 크기에 관계없이 같은 테두리를 가질 것이다. 상대 너비들을 얻기 위해, 'em' 단위를 사용할 수 있다. H1 { border: solid 0.5em }

Border의 너비(width)들은 음수가 될 수 없다.

5-5-12.  오른쪽 테두리 두께('border-right-width')

값: thin | medium | thick | <길이>
최초값: 'medium'
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

이 속성은 엘레멘트의 오른쪽 테두리의 두께를 지정한다. 지정하지 않으면 이는 위쪽 테두리 두께('border-top-width')와 같다.

5-5-13.  아래쪽 테두리 두께('border-bottom-width')

값: thin | medium | thick | <길이>
최초값: 'medium'
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

이 속성은 엘레멘트의 아래쪽 테두리의 두께를 지정한다. 지정하지 않으면 이는 위쪽 테두리 두께('border-top-width')와 같다.

5-5-14.  왼쪽 테두리 두께('border-left-width')

값: thin | medium | thick | <길이>
최초값: 'medium'
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

이 속성은 엘레멘트의 왼쪽 테두리의 두께를 지정한다. 지정하지 않으면 이는 위쪽 테두리 두께('border-top-width')와 같다.

5-5-15.  테두리 두께('border-width')

값: [thin | medium | thick | <길이>]{1,4}
최초값: 약식속성들에는 정의되지 않음
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

이 속성은 한 스타일쉬트에서 'border-width-top', 'border-width-right', 'border-width-bottom', 'border-width-left'를 지정하는 약식속성이다.

값이 1 개 부터 4 개가 될 수 있으며 다음과 같이 적용된다.

• 하나의 값: 모든 4 개의 테두리(border)의 너비들이 이 값이 된다.
• 두개의 값: top, bottom 테두리(border)의 너비들이 첫번째 값이되고, right, left가 두번째 값이 된다.
• 세개의 값: top은 첫번째 값이, right, left는 두번째 값이, bottom은 세번째 값이 된다.
• 네개의 값: 각각 top, right, bottom, left를 지정한다.

아래 예제에서, 코멘트(Comment)는 결과적인 top, right, bottom, left 테두리들 각각의 두께를 나타낸다. H1 { border-width: thin } /* thin thin thin thin */ H1 { border-width: thin thick } /* thin thick thin thick */ H1 { border-width: thin thick medium } /* thin thick medium thin */ H1 { border-width: thin thick medium thin } /* thin thick medium thin */

Border의 너비(width)들은 음수가 될 수 없다.

5-5-16.  테두리 색상('border-color')

값: <color>{1,4}
최초값: 'color' 속성(property)값
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

테두리 색상('border-color') 속성은 4 개의 테두리(border) 색상을 설정한다. 테두리 색상('border-color')은 1 개 부터 4 개사이의 값들을 가질수 있고, 그 값들은 위의 테두리 두께('border-width')에서와 같이 다른 면(side)들의 값들을 설정한다.

색상이 지정되지 않으면, 그 엘레멘트 지체의 색상('color') 속성값이 적용된다. P { color: black; background: white; border: solid; }

위 예제에서, 테두리(border)는 굵은 검정 줄이 된다.

5-5-17.  테두리 스타일('border-style')

값: none | dotted | dashed | solid | double | groove | ridge | inset | outset
최초값: none
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

테두리 스타일('border-style') 속성은 4 개의 테두리 스타일(border style)들를 설정한다. 값은 1 개 부터 4 개사이의 값들을 가질수 있고, 그 값들은 위의 테두리 두께('border-width')에서와 같이 다른 면(side)들의 값들을 설정한다. #xy34 { border-style: solid dotted }

위 예제에서, 수평 테두리들은 'solid', 수직 테두리들은 점선('dotted')이 된다.

테두리 스타일의 최초값이 'none'이므로, 테두리 스타일이 설정되지 않으면 테두리가 보이지 않을 것이다.

테두리 스타일들은 다음의 의미를 갖는다.

none

테두리 두께('border-width') 값에 관계 없이 테두리가 보이지 않는다.

dotted

테두리는 점선(dotted line)으로 그 엘레멘트의 배경 맨 위(top)에 그려진다.

dashed

테두리는 사선(dashed line)으로 그 엘레멘트의 배경 맨 위(top)에 그려진다.

solid

테두리는 연속(solid line)

double

테두리는 이중선(double line)으로 그 엘레멘트의 배경 맨 위(top)에 그려진다. 두개의 단일 선들의 합과 그사이의 공간은 <border-width>의 값과 같다.

groove

<color> 값에 기초한 색상으로 3D groove가 그려진다.

ridge

<color> 값에 기초한 색상으로 3D ridge가 그려진다.

inset

<color> 값에 기초한 색상으로 3D inset가 그려진다.

outset

<color> 값에 기초한 색상으로 3D outset가 그려진다.

CSS1 핵심: 사용도구들은 'dotted', 'dashed', 'double', 'groove', 'ridge', 'inset', 'outset' 모두를 'solid'로 해석할 수 있다.

5-5-18.  위쪽 테두리('border-top')

값: <border-top-width> || <border-style> || <color>
최초값: 약식속성들에는 정의되지 않음
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

엘레멘트의 위쪽 테두리(top border)의 width, style, color을 설정하는 약식속성이다. H1 { border-bottom: thick solid red }

위의 예제는 H1 엘레멘트 아래 테두리의 width, style, color를 설정한다. 생략된 값들은 그들의 최초값들로 설정된다. H1 { border-bottom: thick solid }

위의 예제에서 색상 값이 생략되었으므로, 그 border color은 그 엘레멘트 자체의 색상('color') 값과 같다.

테두리 스타일('border-style') 속성은 4 개까지의 값들을 받을 수 있는데 반해, 이 속성은 하나의 값 만을 받을 수 있슴을 저시하라.

5-5-19.  오른쪽 테두리('border-right')

값: <border-right-width> || <border-style> || <color>
최초값: 약식속성들에는 정의되지 않음
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

엘레멘트의 오른쪽 테두리(righ border)의 width, style, color을 설정하는 약식속성이다. 지정하지 않으면 위쪽 테두리('border-top')와 같다.

5-5-20.  아래쪽 테두리('border-bottom')

값: <border-bottom-width> || <border-style> || <color>
최초값: 약식속성들에는 정의되지 않음
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

엘레멘트의 아래쪽 테두리(bottom border)의 width, style, color을 설정하는 약식속성이다. 지정하지 않으면 위쪽 테두리('border-top')와 같다.

5-5-21.  왼쪽 테두리('border-left')

값: <border-left-width> || <border-style> || <color>
최초값: 약식속성들에는 정의되지 않음
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

엘레멘트의 왼쪽 테두리(left border)의 width, style, color을 설정하는 약식속성이다. 지정하지 않으면 위쪽 테두리('border-top')와 같다.

5-5-22.  테두리('border')

값: <border-width> || <border-style> || <color>
최초값: 약식속성들에는 정의되지 않음
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

테두리('border') 속성은 엘레멘트 모든 4 개의 테두리의 같은 width, color, style를 설정하기 위한 단축 속성이다. 예를 들어, 첫번째 명령(rule)은 그 다음 4 개에서 각각 설정한 것과 같다. P { border: solid red } P { border-top: solid red; border-right: solid red; border-bottom: solid red; border-left: solid red }

마진('margin'), 패딩('padding') 약식속성들과는 달리, 테두리('border') 속성은 4 개의 테두리를 다른 값들로 설정할 수 없다. 이를 위해 하나이상의 다른 border 속성들을 사용하여야 한다.

이속성들이 기능적으로 일부 중복을 하므로 이들을 지정하는 순서가 중요하게 된다. 예제를 보면: BLOCKQUOTE { border-color: red; border-left: double color: black; }

위 예제에서, 왼쪽 테두리의 색상은 검정(black)이 될 것이고, 다른 테두리들은 적색(red)이 된다. 이는 왼쪽 테두리('border-left')에 width, style, color가 설정 되었기 때문이다. 왼쪽 테두리('border-left') 속성(property)에 색상이 설정되지 않았으므로, 이는 'color' 속성(property)에서 값을 받을 것이다. 실제로 'color' 속성이 나중에 설정 되었으므로, 왼쪽 테두리('border-left') 속성이 적용되지 않는다.

테두리 두께('border-width') 속성은 4 개 길이의 값들을 지정할 수 있지만, 이 속성은 하나 만 받을 수 있슴을 주시하라.

5-5-23.  너비('width')

값: <길이> | <백분율> | auto
최초값: auto
적용: 블럭레벨(block-level)과 대체된(replaced) 엘레멘트들
전달: 안됨
백분율 값들: 모체 엘레멘트의 너비(width) 참조

이 속성은 text 엘레멘트들에 적용될 수 있으나, 이미지(image)들과 같은 대체된(replaced) 엘레멘트들에 가장 유용하게 사용된다. 너비(width)는 필요할 때, 배율(scale)을 조절하여 보완할 수 있다. 배율을 조절할 때, 이미지의 변경 비율(ratio)은 높이('height') 속성이 'auto'이면 그대로 유지된다.

예제: IMG.icon { width: 100px }

만일 대체된(replaced) 엘레멘트 너비('width')와 높이('height')가 둘 다 'auto'이면, 이들 속성들 그 엘레멘트의 규격을 그 대로 설정한다.

음수는 허용되지 않는다.

이 속성과 마진(margin), 패딩(padding)의 관계를 위하여 양식화 모델(항목 4)을 참조하라.

5-5-24.  높이('height')

값: <길이> | auto
최초값: auto
적용: 블럭레벨(block-level)과 대체된(replaced) 엘레멘트들
전달: 안됨
백분율 값들: 없슴

이 속성은 text 엘레멘트들에 적용될 수 있으나, 이미지(image)들과 같은 대체된(replaced) 엘레멘트들에 가장 유용하게 사용된다. 높이(height)는 필요할 때, 배율(scale)을 조절하여 보완할 수 있다. 배율을 조절할 때, 이미지의 변경 비율(ratio)은 너비('width') 속성이 'auto'이면 그대로 유지된다.

예제: IMG.icon { height: 100px }

만일 대체된(replaced) 엘레멘트 너비('width')와 높이('height')가 둘 다 'auto'이면, 이들 속성들 그 엘레멘트의 규격을 그 대로 설정한다.

텍스트 엘레멘트에 적용되면, 높이(height)는 예를 들어 화면 굴리기(scrollbar)등으로 보완될 수 있다.

음수는 허용되지 않는다.

CSS1 핵심: 사용도구들은, 그 엘레멘트가 대체된(replaced) 엘레멘트가 아니면, 높이('height') 속성을 무시('auto' 처리)할 수도 있다.

5-5-25.  유동('float')

값: left | right | none
최초값: none
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

값 'none'로, 그 엘레멘트는 그 텍스트(text) 안에서 나타 날 곳에 표현(display)된다. 값 'left' ('right')로 그 엘레멘트는 left (right)으로 이동하여, 그 텍스트(text)는 그 엘레멘트의 right (left) 면(side)에 줄바꿈(wrap)한다. 값 'left' 또는 'right'로, 그 엘레멘트는 블럭레벨(block-level)로 처리된다('display' 속성이 무시된다). 항목 4.1.4의 설명을 참조하라. IMG.icon { float: left; margin-left: 0; }

위 예제는 'CLASS=icon'를 갖는 모든 IMG 엘레멘트들은 그 모체 엘레멘트의 왼쪽(left )을 따라 위치시킨다.

이 속성은 인라인(inline) 이미지들에서 가장 자주 사용되나, 텍스트(text) 엘레멘트들에도 적용된다.

5-5-26.  'clear'

값: none | left | right | both
최초값: none
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

이 속성은 엘레멘트를 유동(floating) 엘레멘트들의 옆면(side)들에 허용할 것인가를 지정한다. 더 구체적으로, 이 속성값은 유동(floating) 엘레멘트들이 허용되지 않는 면(side)들의 목록(list)이다. 'clear'가 'left'를 설정하면, 엘레멘트는 어떤 유동(floating) 엘레멘트 밑의 왼쪽으로 이동한다. 'clear'가 'none'으로 설정되면, 유동(floating) 엘레멘트들은 모든 면(side)들에 허용된다. 예제를 보면: H1 { clear: left }

5-6.  속성들의 분류

이들 속성들은 엘레멘트들을 특정 보이는 파라메터(parameter)들를 설정하는 것에 추가하여 카테고리들(categories)로 분류한다.

이 목록 스타일(list-style) 속성들은 어떻게 목록 항목들(목록 항목('list-item')의 'display' 값을 갖는 엘레멘트들)을 기술하는가를 양식화한다. 이 목록 스타일(list-style) 속성들은 어떤 엘레멘트에도 설정될 수 있고, 이는 일반적으로 계통도(tree) 하부로 전달(inherit)된다. 그러나, 이들은 목록 항목('list-item')의 값이 'display' 일 때 만 엘레멘트들에 효과를 줄 것이다. HTML에서 이는 전형적으로 'LI' 엘레멘트의 경우이다.

5-6-1.  'display'

값: block | inline | list-item | none
최초값: block
적용: 모든 엘레멘트들
전달: 안됨
백분율 값들: 없슴

이 속성은 엘레멘트가 화면에 표현(display)될 것인가, 그렇다면 어떻게 디스플레이될 것인가를 기술한다. 이는 인쇄에서나 컴퓨터 화면등이 될 수 있다.

엘레멘트가 'display' 값 'block'을 가지면 새로운 박스(box)를 연다. 그 박스는 CSS 양식화 모델에 따라 인접 박스들에 상대적으로 위치한다. 전형적으로, 'H1'와 'P'와 같은 엘레멘트들은 블럭('block') 타입니다. 값 목록 항목('list-item')은 목록(list-item) 메이커(marker)가 추가된다는 것 이외에는 블럭('block')과 유사하다. HTML에서, 'LI'는 전형적으로 이 값을 갖는다.

엘레멘트의 'display' 값 'inline'은 이전의 내용(content)이 있는 것과 같은 줄에 새로운 인라인(inline) 박스(box)를 생성한다. 이 박스(box)는 양식화(formatted)된 내용의 크기에 따라 크기(dimension)가 결정된다. 만일 내용이 텍스트이면, 이는 여러 줄들에 확장(span)할 수 있으며, 또한 그들은 각 줄에 하나의 박스가 있는 것이다. 마진(margin), 테두리(border), 패딩(padding) 속성들은 '인라인(inline)' 엘레멘트들에 적용되나, 줄바꿈들에서는 아무 효과도 없다.

값 'none'은 엘레멘트의 하위(child) 엘레멘트들과 주위 박스(box)을 포함하여 디스플레이를 중지시킨다. P { display: block } EM { display: inline } LI { display: list-item } IMG { display: none }

마지막 명령(rule)은 이미지들의 디스플레이를 중지시킨다.

'display'의 최초값은 'block'이지만, 사용도구는 모든 HTML 엘레멘트들을 위하여, HTML 규격에서 엘레멘트들의 표현을 위하여 제시된 바에 따라, 전형적인 디폴트 값들 가진다.

CSS1 핵심: 사용도구들은 'display'를 무시하고, 사용도구의 디폴트(default) 값들 만을 사용할 수 있다.(항목 7를 참조하라.)

5-6-2.  공백('white-space')

값: normal | pre | nowrap
최초값: normal
적용: 블럭레벨(block-level) 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

이 속성은 엘레멘트 안에서 어떻게 공간(whitespace)을 처리할 것인가를 기술한다. 방법은 'normal' (공간이 붕괴 됨), 'pre' (HTML의 'PRE' 엘레멘트처럼 작용) 또는 'nowrap'(BR 엘레멘트들가 있을 때만 줄바꿈 함)이 있다. PRE { white-space: pre } P { white-space: normal }

공백('white-space')의 최초값이 'normal'이지만, 사용도구는 모든 HTML 엘레멘트들을 위하여, HTML 규격에서 엘레멘트들의 표현을 위하여 제시된 바에 따라, 전형적인 디폴트 값들을 갖는다.

CSS1 핵심: 사용도구들은 제작자와 리더의 스타일쉬트에서 공백('white-space') 속성 무시하고, 사용도구의 디폴트(default) 값들 만을 사용할 수 있다.(항목 7를 참조하라.)

5-6-3.  목록 스타일 타입('list-style-type')

값: disc | circle | square | decimal | lower-roman | upper-roman | lower-alpha | upper-alpha | none
최초값: disc
적용: 목록('list-item') 값 'display'를 갖는 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

이 속성은 목록(list-item) 메이커(marker)의 모양을 결정하는데, 목록 스타일 이미지('list-style-image')가 'none'이거나, URL에 의하여 지정되는 이미지가 표현될 수 없를 때 사용된다. OL { list-style-type: decimal } /* 1 2 3 4 5 ... */ OL { list-style-type: lower-alpha } /* a b c d e ... */ OL { list-style-type: lower-roman } /* i ii iii iv v ... */

5-6-4.  목록 스타일 이미지('list-style-image')

값: <url> | none
최초값: none
적용: 목록('list-item') 값 'display'를 갖는 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

이 속성은 목록(list-item) 메이커(marker)에 사용될 이미지를 설정한다. 이미지가 유효하면 이 이미지는 목록 스타일 타입('list-style-type') 메이커(marker)가 설정한 것을 대체한다. UL { list-style-image: url(http://png.com/ellipse.png) }

5-6-5.  목록 스타일 위치('list-style-position')

값: inside | outside
최초값: outside
적용: 목록('list-item') 값 'display'를 갖는 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

목록 스타일 위치('list-style-position') 값은 목록(list-item) 메이커(marker)가 내용에 대하여 어떻게 그려 지는가를 결정한다. 양식화(formatting) 예제는 목록 엘레멘트(항목 4.1.3)를 참조하라.

5-6-6.  목록 스타일('list-style')

값: [disc | circle | square | decimal | lower-roman | upper-roman | lower-alpha | upper-alpha | none] || [inside | outside] || [<url> | none]
최초값: 약식속성들에는 정의되지 않음
적용: 목록('list-item') 값 'display'를 갖는 엘레멘트들
전달: 전달 됨
백분율 값들: 없슴

목록 스타일('list-style') 속성은 목록 스타일 타입('list-style-type'), 목록 스타일 이미지('list-style-image'), 목록 스타일 위치('list-style-position') 세가지 속성을 한 스타일쉬트에서 지정하는약식속성이다. UL { list-style: upper-roman inside } UL UL { list-style: circle outside } LI.square { list-style: square }

'LI' 엘레멘트들에 직접 목록 스타일('list-style')를 설정하는 것은 기대하지 않은 결과를 초래할 수 있다. 예제를 보라: <STYLE TYPE="text/css"> OL.alpha LI { list-style: lower-alpha } UL LI { list-style: disc } </STYLE> <BODY> <OL class=alpha> <LI>수준 1 <UL> <LI>수준 2 </UL> </OL> </BODY>

위의 예제에서 스타일쉬트 안의 첫번째 명령(rule)이 높은 우선순위(카스케이딩 순서에 정의된 것과 같이)를 갖기 때문에, 이는 모든 'LI' 엘레멘트들의 두번째 명령(rule)을 덮어씌울(override) 것이며, 'lower-alpha' 목록 스타일 만이 사용될 것니다. 따라서 목록 스타일('list-style')는 목록 타입(list type) 엘레멘트들에 만 지정할 것을 추천한다. OL.alpha { list-style: lower-alpha } UL { list-style: disc }

위 예제에서, 목록 스타일('list-style') 값들은 'OL' 과 'UL' 엘레멘트들로 부터 'LI' 엘레멘트들로 전달된다.

URL 값은 다른 어떤 값의 조합될 수 있다. UL { list-style: url(http://png.com/ellipse.png) disc }

위의 예제에서, 이미지가 우효하지 않으면 'disc'가 사용된다.

6.  단위들(Units)

6-1.  길이 단위

길이 값의 양식은 선택적 부호('+' 또는 '-', 디폴트는 '+')와 그 뒤 바로 따라오는 수치(소수점이 있거나 없거나) 그리고 그 바로 뒤에 두 글자로 간단히 된 단위 인식자(identifier)로 된다. 수치 0 뒤의 단위 지정자는 선택적이다.

일부 속성들은 음수의 길이 단위들을 허용하나, 이는 양식화 모델을 복잡하게 하고 적용에 따라 한계가 있을 수 있다. 만일 음수 길이 값이 지원되지 않으면, 지원되는 값 중에서 가장 가까운 값으로 대체된다.

길이의 단위들에는 상대적(relative)인 것과 절대적(absolute)인 것 두가지가 있다. 상대적인 단위들은 다른 길이 속성(property)에 상대적으로 나타낸다. 상대적인 단위들을 사용하는 스타일쉬트들은 한 메디아에서 다른 메디아로(예를 들어 컴퓨터 화면에서 레이저 프린터로) 스테일(scale)하는 것이 보다 용이하다. 아래 설명하는 백분율 단위(percentage unit)들과 키워드(keyword) 값(예를 들어 'x-large')들은 이와 비슷한 잇점들이 있다.

아래와 같은 상대(relative) 단위들이 지원된다. H1 { margin: 0.5em } /* em, 엘레멘트의 글꼴(font) 높이 */ H1 { margin: 1ex } /* x-height, 글자 'x'의 높이 */ P { font-size: 12px } /* pixels, 화면에 상대적으로 */

상대적인 단위 'em'과 'ex'는 그 엘레멘트 자체의 글꼴 크기(font size)에 상대적이다. CSS1에서 한가지 예외는 글꼴 크기('font-size') 속성인데, 여기서는 'em'과 'ex' 값은 모체 엘레멘트의 글꼴 크기(font size)를 참조한다.

예제의 마지막 줄에서 사용된 픽셀(pixel) 단위는, 그 화면의 해상도(resolution), 말하자면 대부분의 경우 컴퓨터 디스플레이에 상대적이다. 만일 출력 장티의 픽셀(pixel) 밀도(density)가 일반적인 컴퓨터 디스플레이에서와 다르면, 사용도구는 픽셀(pixel) 값들을 재 스케일(rescale)하여야 한다. 암시된 참조 픽셀(pixel)은 픽셀 밀도 90dpi(dots per inch) 장치에서 리더가 한 팔 거리에서 한개의 픽셀의 볼 수 있는 시각의 각도이다. 일반적인 한 팔 거리는 28인치이고 보는 각도는 약 0.0227도이다.

하위(Child) 엘레멘트들에는 상대값이 아닌 계산된 값이 전달(inherit)된다. BODY { font-size: 12pt; text-indent: 3em; /* 말하자면 36pt */ } H1 { font-size: 15pt }

위의 예제에서, 'H1' 엘레멘트들의 텍스트 들여쓰기('text-indent') 값은 45pt가 아니라 36pt이다.

절대(Absolute) 길이 단위들은 출력 장치의 물리적 속성들이 알려졌을 때에 만 유용하다. 이들 절대(absolute) 단위들은 아래와 같이 지원된다. H1 { margin: 0.5in } /* 인치(inche), 1in = 2.54cm */ H2 { line-height: 3cm } /* cm, centimeter */ H3 { word-spacing: 4mm } /* mm, millimeters */ H4 { font-size: 12pt } /* 포인트(point), 1pt = 1/72 in */ H4 { font-size: 1pc } /* 피카(pica), 1pc = 12pt */

특정 길이가 지원되지 않으면, 사용도구들은 대략적으로 시도하여야 한다. 모든 CSS1 속성들에서, 추가적인 계산과 전달은 이 대략적인 값을 기준으로 하여야 한다.

6-2.  백분율 단위(percentage unit)들

백분율 값의 양식은 선택적 기호('+' 또는 '-', 디폴트는 '+')와 그 뒤에 바로 따라오는 수치(소수점 있거나 없거나) 그리고 바로 뒤에 '%'로 된다.

백분율 값들은 항상, 예를 들어 길이 단위등, 다른 값에 대해 상대적이다. 백분율 단위(percentage unit)들이 허용되는 각 속성은 그 백분율 값이 무엇을 참조하는가가 정의되어 있다. 그 엘레멘트 자체의 글꼴 크기(font size)를 참조하는 경우가 가장 많다. P { line-height: 120% } /* 엘레멘트의 글꼴 크기('font-size')의 120% */

모든 전달(inherit)된 CSS1 속성들이 백분율 값을 가지면, 하위(Child) 엘레멘트들에는 그 백분율 값이 아닌 계산된 값이 전달(inherit)된다.

6-3.  색상 단위(color unit)들

색상(color)은 키워드(keyword) 또는 수치적 RGB 규격이다.

암시된 색상 이름들의 키워드(keyword) 목록은 aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, yellow등이다. 이들 16 색상(color)들은 윈도우즈(Windows) VGA palette로부터 온 것이고, 그 들 RGB 값들은 이 규격에 정의되어 있지 않다. BODY {color: black; background: white } H1 { color: maroon } H2 { color: olive }

RGB 색상 모델은 수치 색상 규격으로 사용된다. 아래 예제에서 모두 같은 색상을 나타낸다. EM { color: #f00 } /* #rgb */ EM { color: #ff0000 } /* #rrggbb */ EM { color: rgb(255,0,0) } /* 정수 범위: 0 - 255 */ EM { color: rgb(100%, 0%, 0%) } /* 유동(float) 범위: 0.0% - 100.0% */

RGB 값의 양식은 '#'로 시작하는 16 진수(hexadecimal) 표현이다. '#' 다음에 바로 3 자 혹은 6 자 16진수 글자(0,1,2,3...,a,b,c,d,e,f)들이 나온다. 3 자 RGB 표현(#rgb)은 각 글자를 복사하여(0을 더하는 것이 아니고) 6 자 (#rrggbb) 양식을 만든다. 예를 들어, #fb0는 #ffbb00로 된다. 이 것으로 흰색(#ffffff)을 약식(#fff)으로, 색상 깊이 등 부속 변화를 생략하고, 확실히 표현할 수 있다.

RGB 값은 기능적 표현 양식으로 기술할 수 있는데, 'rgb(' 다음에 컴마(,)로 분리한 세가지 색상 값을 목록화 하고 ')'로 닫는다. 여기서 세가지 색상의 각 색상 값은 정수 0-255 범위의 수치, 또는 0.0%에서 100.0%까지 범위의 세개의 백분율 값들이 된다. 수치 앞과 뒤에 공백(whitespace)이 허용된다.

수치 범위 밖의 수치 값들은 잘려진다. 아래 예제에서 세가지는 모두 같다. EM { color: rgb(255,0,0) } /* 정수 범위: 0 - 255 */ EM { color: rgb(300,0,0) } /* 255로 잘림 */ EM { color: rgb(110%, 0%, 0%) } /* 100%로 잘림 */

RGB 색상(color)들은 [9] sRGB color space에 정의되어 있다. 사용도구들은 색상들을 표현하는 주파수(fidelity)가 서로 다를 수 있으나, sRGB 사용은 모호하지 않고, 어떤 색상이 되어야 한다는 것이 확실히 양적으로 국제적인 규격들[10]에 정의되어 있다.

사용도구들은 색상들을 디스플레이 하는데 색상 보정(gamma-correction) 수행을 위한 그들의 노력을 생략할 수 있다. sRGB는 지정된 보이는 상황에서 디스플레이 감마(gamma)를 2.2로 정의하고 있다. 사용도구들은 CSS에서 주어진 색상들을 출력 장치의 자연("natural") 디스플레이 감마(gamma)와 조합하여, 실효 디스플레이 감마(gamma)가 2.2가 되도록 보정(부록 D)한다. CSS에서 정의한 색상들 에서 만 영향을 받는다는 점을 주시하라. 예를 들어 이미지들은 그들 자신의 색상 정보를 표현할 것으로 기대된다.

6-4.  URL

URL(Uniform Resource Locator:공통 자원 지정자)는 기능적 표현으로 지정한다. BODY { background: url(http://www.bg.com/pinkish.gif) }

URL 값은 'url('로 시작하고 바로 뒤에 선택적 공백, 그 다음 선택적 단일 따옴(') 또는 이중 따옴("), 그 다음에 ([11] URL 자체에서 정의된 것과 같이)가 나온다. 그리고 다시 선택적 단일 따옴(') 또는 이중 따옴("), 그 다음 선택적 공백, 그리고 ')'로 닫는다. 따옴표는 URL 자체의 부분은 아니며 반드시 짝을 맞춰야 한다.

URL 안의 괄호, 컴마, 공백, 단일 따옴('), 이중 따옴(")들은 역슬래쉬(\)를 사용하여 '\(', '\)', '\,' 등으로 에스케이프(escape)되어야 한다.

부분적 URL들은, 그 문서에 상대적이 아니라, 스타일쉬트 자원(source)에 상대적으로 해석된다. BODY { background: url(yellow) }HTML의 URI 설명을 참조하라.

7.  CSS1에 부합

문서들을 표현하는 CSS1를 사용하는 사용도구는 다음 경우 CSS1 규격에 부합한다.

• 이 규격에 따라 모든 참조 스타일쉬트를 가져오도록 시도하고 해석(parse)하도록 시도한다.
• 카스케이딩 순서에 따라 선언들을 정렬(sort)한다.
• 표현 도구의 능력 범위 안에서 CSS1 기능을 적용한다.(아래 설명 참고)

CSS1 스타일쉬트 출력 사용도구가 CSS1 규격에 부합하려면

• 유효한 CSS1 스타일쉬트 출력

문서들을 디스플레이 하는데 CSS1를 사용하는, 그리고, CSS1 스타일쉬트를 출력(output)하는, 두가지 부합 필요 조건을 충족시키는 사용도구는 CSS1 규격에 부합하는 것이다.

사용도구는 CSS1의 모든 기능들을 적용해야 하는 것은 아니다. 핵심 기능들을 적용하면 CSS1에 부합하는 것이 될 수 있다. 제외된 부분이라는 명시된 것을 제외하고, 핵심(core) 기능(functionality)이 CSS1 규격의 전체를 구성한다. 이 규격에서는 "CSS1 핵심:"이라고 표시하고, 그 뒤에 어떤 기능이 핵심 기능 밖에 있는가의 설명이 따른다. 핵심 기능 밖의 것들을 CSS1 발전된 기능이라 한다.

이 항목에서는 단지 CSS1 부합성을 정의한다. 향 후 CSS 수준에서 부합하기 위하여 사용도구는 다른 기능들의 수행이 필요하게 된다.

메디아의 표현에서 제한적인 예제들은, 제한된 자원들(fonts, color)과 제한된 해상도(resolution), 따라서 테두리(margin)들이 정확하지 않은 것 등이다. 이런 경우 사용도구는 스타일쉬트 값들의 대략을 사용하여야 한다. 또한, 다른 사용자 인터페이스(interface) 기준에서 그 들 자신의 제한을 가질 수 있는데 예를 들어 비디오(VR) 브라우저에서 사용자와의 "거리"에 따라 스케일을 다시(rescale)할 수 있다.

사용도구들은 리더(for reader)에게 표현의 추가적인 선택을 제공할 수 있다. 예를 들어, 사용도구가 리더에게 시각 장애자 선택 또는 깜빡거림(blink) 중지 선택을 줄 수 있다.

CSS1은 양식화의 모든 견지들을 정의하지 않는다는 점을 주시하라. 예를 들어, 사용도구는 글자 간격(letter-spacing)이 기능 방법(algorithm) 선택은 자유이다.

이 규격은 사용도구에, 요구하지 않으나, 추천하는 것들이 있다.

• 리더(reader)에게 개인적인 스타일쉬트를 지정할 수 있게 허용
• 개별 스타일쉬트를 켜고, 끌 수 있게 허용

위의 부합성 설명은. 사용자에게 표현(user interface)되는 것이 아니고. 그 기능적 면 만을 설명한 것이다.

7-1.  향후 버전에 부합한 처리(parsing)

이 규격은 CSS 수준(level) 1을 정의한다. 추가적인 기능들를 갖는 CSS의 높은 수준이 기대되며 이는 향후 정의될 것이다. 사용도구들이 단순히 CSS1를 지원하지 않고, 향 후 더 높은 수준의 스타일쉬트를 읽을 수 있도록 지원을 확실히 하기 위하여, 이 항목은 사용도구가 CSS1에서 유효하지 않은 구조를 만나면, 어떻게 하여야 하는가를 정의한다.

• 모르는 속성의 선언은 무시한다. 예를 들어, 스타일쉬트가 H1 { color: red; rotation: 70deg }

  사용도구는 이를 아래와 같은 스타일쉬트로 처리한다. H1 { color: red; }

• 유효하지 않은 값들, 또는 유효하지 않은 부분을 갖는 값들은 그 선언이 없는 것으로 처리한다. IMG { float: left } /* CSS1 */ IMG { float: left top } /* "top"은 유동('float')의 값이 아님 */ IMG { background: "red" } /* CSS1의 키워드(keyword)에는 따옴표가 없슴 */ IMG { border-width: 3 } /* 단위는 길이의 값으로 지정하여야 함 */

  위 예제에서, CSS1 처리자(parser)는 첫 명령(rule) 만 인정하고 나머지는 무시 하여 다음과 같아 질 것이다. IMG { float: left } IMG { } IMG { } IMG { }

  향 후 CSS 규격에 부합하는 사용도구는 하나이상의 다른 규칙도 받아 드릴 수 있어야 한다.

• 개별 무효(invalid) at-keyword는, 그 이후에 따라나오는 것을 쎄미콜론(;), 또는 ({...}) 짝 중에서 먼저 나오는 것까지 포함하여 모두 무시된다. 예를 들어, 다음을 보면: @three-dee { @background-lighting { azimuth: 30deg; elevation: 190deg; } H1 { color: red } } H1 {color: blue}

  CSS1에서 '@three-dee'는 무효 코드이다. 따라서 모든 at-rule( 세번째 '}'를 포함하여 그 것까지) 무시된다. CSS1 사용도구는 건너 띄워, 스타일쉬트를 효과적으로 아래와 같이 줄인다. H1 {color: blue}

더 자세히 설명하면:

CSS 각 버전의 CSS 스타일쉬트는 statements의 목록으로 구성되어 있다. 두종류의 statements가 있는데, at-rules과 rulesets이다. statements의 앞과 뒤에 공백(space, tab, newline)이 있어도 된다.

CSS 스타일쉬트는 자주 HTML 문서들에 깔리며(embed), 옛날(older) 사용도구들에서는 스타일쉬트를 감출 수 있는데, 이는 스타일쉬트를 HTML 코멘트(Comment) 안에 넣는데 편리하다. HTML 코멘트(Comment)의 "<!--"와 "-->"가 statements의 앞, 뒤, 그리고 그 안에 나올 수 있고, 그 주위에 공백이 올 수 있다.

At-rules은 at-keyword로 시작되며, 그 인식자(identifier)의 시작을 알리는 '@'을 사용한다(예: '@import', '@page'). 인식자(identifier)는 글자, 수치, 대쉬(-)와 에스케입된(escaped) 글자들로 구성된다(아래 정의).

at-rule은 다음에 나오는 쎄미콜론(;) 또는 블럭(block: 곧 설명 함) 중 먼저 나오는 것까지, 그리고 그것을 포함하여, 모든 것으로 구성된다. CSS1 사용도구는, '@import' 이외의 다른 at-keyword로 시작되는 at-rule을 만나면, at-rule과 그 다음의 계속적인 처리(parsing)을 전부 무시한다. 만일 이것이 스타일쉬트의 맨 위에 나오지 않으면, 말하자면 어떤 명령(rule) 다음에 나온다면 그것이 유효하지 않더라도, '@import'로 시작되는 at-rule도 무시한다. 여기 예제가 있다.

CSS1 처리자(parser)가 아래 스타일쉬트를 만났다면: @import "subs.css"; H1 { color: blue } @import "list.css";

두번째 '@import'는 CSS1에서 유효하지 않다. CSS1 처리자(parser)는 전체 at-rule을 무시하고, 효과적으로 아래와 같이 간단히 한다. @import "subs.css"; H1 {color: blue}

한 블럭(block)은 '{'로시작되고 '}'로 끝난다. 그 사이에, 항상 짝이 맞아야 하고 네스트(nest)될 수 있는 괄호들'(), [], {}'들은 제외하고, 글자들이 나올 수 있다. 단일 따옴표(')와 이중 따옴표(") 도 짝을 맞추어 나오고, 그 사이의 글자들은 문자열(string)로 처리(parse)된다. 부록 B 문자열 정의 토큰(token)을 참조하라. 여기 블럭(block)의 예제가 있다. 따옴표 속의 오른쪽 '}'는 블럭(block) 시작 '{'와 짝이 맞지 않고, 두번째 단일 따옴표는 에스케입(escape)된 글자이며, 따라서 열린 따옴표와 짝이 맞지 않음을 주시하라. { causta: "}" + ({7} * '\'') }

ruleset는 selector-string와 그 뒤에 declaration-block으로 구성된다. selector-string는 처음 '{'까지, 그 '{'를 포함하지 않는, 모든 것으로 구성된다. selector-string으로 시작하는 ruleset는 무효 CSS1는 건너 뛴다.

CSS1 처리자(parser)가 다음 예제의 스타일쉬트를 만났다면 H1 { color: blue } P[align], UL { color: red; font-size: large } P EM { font-weight: bold }

두번째 줄은 CSS1에서 무효인 selector-string를 만났다. CSS1 사용도구는 이 ruleset를 건너 뛰어, 다음과 같이 된다. H1 { color: blue } P EM { font-weight: bold }

선언블럭(declaration-block)은 '{'로 시작하고 짝 맞는 '}'로 끝난다. 그 사이에 하나도 없거나 여러개의 선언(declaration)들이 쎄미콜론(;)으로 분리되어 위치한다.

선언(declaration)은 속성(property), 콜론(:) 그리고 값(value)으로 구성된다. 그 앞, 뒤에 공간(whitespace)이 들어 갈 수 있다. 속성은 앞에서 정의한 바와 같은 인식자(identifier)이다. 값에는 어떤 글자도 올 수 있는데 괄호들'(), [], {}'과 단일 따옴표(')와 이중 따옴표(") 도 짝을 맞추어 사용하여야 한다. 괄호들'(), [], {}'은 네스트(nest)될 수 있다. 따옴표 속의 글자들은 문자열(string)로 처리(parse)된다

현재의 속성들에 새로운 속성들과 값들을 향 후 추가할 수 있게하기 위하여, 사용도구는 유효하지 않은 속성 이름이나 유효하지 않은 값을 갖는 선언을 건너 뛰어야 한다. 각 CSS1 속성은 그것이 수용(accept)하는 값들에 문법적, 의미적 제한이 있다.

CSS1 처리자(parser)가 다음 예제의 스타일쉬트를 만났다면 H1 { color: red; font-style: 12pt } P { color: blue; font-vendor: any; font-variant: small-caps } EM EM { font-style: normal }

첫번째 줄의 두번째 선언에서 '12pt'는 무효 값이다. 두번째 줄의 두번째 선언에서 'font-vendor'는 정의되지 않은 속성이다. CSS1 처리자(parser) 이 선언들을 건너 띄고, 다음과 같이 줄일 것이다. H1 { color: red; } P { color: blue; font-variant: small-caps } EM EM { font-style: normal }

코멘트(Comment: 항목 1.7 참조)는, 공백으로 고려되는, 공백이 있는 곳에는 어디나 나올 수 있다. CSS1는 값의 안에서 추가적으로 공백이 나올 수 있는 곳을 정의하였다. 그 곳에서 코멘트(Comment)도 허용된다.

다음 규칙이 항상 적용된다.

• 모든 CSS 스타일쉬트는, CSS의 통제(control)를 받지 않는 부분을 제외하고는, 대소분자를 구분(case-insensitive)한다. CSS1에서 글꼴(font family) 이름과 URL은 대소분자를 구분(case-insensitive)할 수 있다. 또한 HTML [2] 제어 아래 있는 CLASS와 ID 애트리뷰트들은 대소분자를 구분(case-insensitive)한다.
• CSS1에서, 선택자(selector: 엘레멘트의 name, class, ID)들은 글자 A-Z, 0-9, Unicode 글자 161-255, '+', '-' 만을 가질 수 있다. '-'나 수자로 시작될 수 없다. 에스케입(escape) 글자와 Unicode 글자의 수치 코드(다음 참조)를 가질 수 있다.
• \(backslash) 다음의 16 진수(01..9abcdef)는 Unicode 글자의 번호이다.
• 16 진수 이외의 어느 글자는, \(backslash)를 그 글자 앞에 넣어, 그 특수 의미를 제거하여, 에스케입(escape)될 수 있다. 예를 들어 (\")는 한 이중 따옴표 한 글자의 배열변수(string)이다.
• 위 두가지는 백슬래쉬 에스케입(backslash-escape)을 정의하였다. 백슬래쉬 에스케입은, 문자열(string) 속의 것을 제외하고는, 항상 인식자(identifier)의 한 부분으로 고려된다. 말하자면, "{"는 구둣점인데, "\7B"는 구둣점이 아니고, "2"는 허용되지 않으나, "\32"는 글라스(class) 이름 시작에 허용된다.

주기: HTML의 CLASS 애트리뷰트는 클래스(class) 이름에 위 선택자(selector)로 허용된 글자 이외의 다른 글자들을 허용한다. CSS1에서, 이들 글자들은 에스케입(escape)되거나 또는 Unicode 번호로 써야 한다.
"B&W?"는 "B\&W\?" 또는 "B\26W\3F"로 쓸 수 있고,
그리스어(Greek: "kouros"): "κουρος"는 "\3BA\3BF\3C5\3C1\3BF\3C2"로 써야한다.
항 후 CSS 버전에서는 더 많은 글자를 직접 입력할 수 있을 것으로 기대된다.

부록 B CSS1 문법을 참조하라.

8.  참고

[1] 영문 W3C 스타일쉬트 자원 페이지 (http://www.w3.org/Style)

[2] HTML 4 규격 번역문,
영문 HTML 4.0 규격 "http://www.w3.org/TR/REC-html40/",
D. Raggett, A. Le Hors, I. Jacobs, December 1997.

[3] T Berners-Lee, D Connolly: "Hypertext MarkupLanguage - HTML 2.0",
영문 RFC1866,
MIT/W3C, November 1995.
영문 규격 웹양식 "http://www.w3.org/MarkUp/html-spec/html-spec_toc.html"

[4] F Yergeau, G Nicol, G Adams, M Dürst:
영문 Hypertext Markup Language의 국제화 "ftp://ds.internic.net/rfc/rfc2070.txt"

[5] 영문 ISO 8879:1986
정보 처리 - 텍스트와 오피스 시스템 -
Standard Generalized Markup Language (SGML)
HTML의 SGML 설명을 참조하라.

[6] 영문 ISO/IEC 10179:1996
정보 기술 -- 프로그램 언어 --
Document Style Semantics and Specification Language (DSSSL).

[7] 영문 ISO/IEC 9899:1990
프로그램 언어 -- C.

[8] 유니코드 컨소시움(The Unicode Consortium),
Unicode 표준 -- 세계 글자 엔코딩 -- Version 1.0,
Addison-Wesley, Volume 1, 1991, Volume 2, 1992.

[9] 영문 인터넷을 위한 표준 디폴트 색상, version 1.10,
M. Stokes, M. Anderson, S. Chandrasekar, and R. Motta, 5 November 1996.

[10] CIE Publication 15.2-1986, 영문 Colorimetry, 제 2 판,
ISBN 3-900-734-00-3
"http://www.hike.te.chiba-u.ac.jp/ikeda/CIE/publ/abst/15-2-86.html"

[11] T Berners-Lee, L Masinter, M McCahill: "Uniform Resource Locators (URL)",
영문 RFC1738,
CERN, Xerox Corporation, University of Minnesota, December 1994

[12] 영문 PNG (Portable Network Graphics) 규격, Version 1.0
"http://www.w3.org/TR/REC-png-multi.html"

[13] Charles A. Poynton: 영문 Macintosh Platform에서 감마(gamma) 수정
"ftp://ftp.inforamp.net/pub/users/poynton/doc/Mac/Mac_gamma.pdf"

[14] 국제 색상 컨소시움(International Color Consortium):
영문 ICC Profile Format Specification, version 3.2, 1995
"ftp://sgigate.sgi.com/pub/icc/ICC32.pdf"

[15] S C Johnson: "YACC - Yet another compiler compiler",
Technical Report, Murray Hill, 1975

[16] "Flex: The Lexical Scanner Generator", Version 2.3.7, ISBN 1882114213

9.  문서를 구성한 인사들

짧은 HTML의 역사 동안, 여러번의 영문 스타일쉬트 제안들이 있었는데, 이 제안은 그 것들에 기인하였다. 특히 Robert Raisch, Joe English와 Pei Wei의 제안들에서 영향을 많이 받았다.

CSS1 발전에 여러 사람들이 공헌하였다. 우리는 특히 다음 사람들에게 감사드린다. Terry Allen, Murray Altheim, Glenn Adams, Walter Bender, Tim Berners-Lee, Yves Bertot, Scott Bigham, Steve Byrne, Robert Cailliau, James Clark, Daniel Connolly, Donna Converse, Adam Costello, Todd Fahrner, Todd Freter, Roy Fielding, Neil Galarneau, Wayne Gramlich, Phill Hallam-Baker, Philipp Hoschka, Kevin Hughes, Scott Isaacs, Tony Jebson, William Johnston, Gilles Kahn, Philippe Kaplan, Phil Karlton, Evan Kirshenbaum, Yves Lafon, Murray Maloney, Lou Montulli, Colas Nahaboo, Henrik Frystyk Nielsen, David Perrell, William Perry, Scott Preece, Paul Prescod, Liam Quin, Vincent Quint, Jenny Raggett, Thomas Reardon, Cécile Roisin, Michael Seaton, David Seibert, David Siegel, David Singer, Benjamin Sittler, Jon Smirl, Charles Peyton Taylor, Irène Vatton, Daniel Veillard, Mandira Virmani, Greg Watkins, Mike Wexler, Lydja Williams, Brian Wilson, Chris Wilson, Lauren Wood and Stephen Zilles.

이 작업과 HTML3을 작업한 Dave Raggett, 특히 색상과 글꼴 분야에서 계속적인 공헌한 Chris Lilley, 그리고 이 구성과 창의적인 숙련을 제공한 Steven Pemberton, 이 세 분의 공헌을 특별히 명시한다.

부록 A: HTML 2.0을 위한 견본 스타일쉬트          

(이 부록은 지명적이 아니고 정보를 제공하기 위한 것이다.)

다음 스타일쉬트는 작성 [3] HTML 2.0 규격으로 암시되는 표현을 하기 위해 제공 되었다. 일부 스타일들, 예를 들어, 색상들은 완전성을 위하여 추가되었다. 아래의 제시된 스타일쉬트와 유사한 것이 사용도구의 디폴트로 사용되기를 제안한다. BODY { margin: 1em; font-family: serif; line-height: 1.1; background: white; color: black; } H1, H2, H3, H4, H5, H6, P, UL, OL, DIR, MENU, DIV, DT, DD, ADDRESS, BLOCKQUOTE, PRE, BR, HR, FORM, DL { display: block } B, STRONG, I, EM, CITE, VAR, TT, CODE, KBD, SAMP, IMG, SPAN { display: inline } LI { display: list-item } H1, H2, H3, H4 { margin-top: 1em; margin-bottom: 1em } H5, H6 { margin-top: 1em } H1 { text-align: center } H1, H2, H4, H6 { font-weight: bold } H3, H5 { font-style: italic } H1 { font-size: xx-large } H2 { font-size: x-large } H3 { font-size: large } B, STRONG { font-weight: bolder } /* 그 모체에 상대적 */ I, CITE, EM, VAR, ADDRESS, BLOCKQUOTE { font-style: italic } PRE, TT, CODE, KBD, SAMP { font-family: monospace } PRE { white-space: pre } ADDRESS { margin-left: 3em } BLOCKQUOTE { margin-left: 3em; margin-right: 3em } UL, DIR { list-style: disc } OL { list-style: decimal } MENU { margin: 0 } /* 치밀한 양식 */ LI { margin-left: 3em } DT { margin-bottom: 0 } DD { margin-top: 0; margin-left: 3em } HR { border-top: solid } /* 'border-bottom'도 사용될 수 있다 */ A:link { color: blue } /* 방문하지 않은 연결 */ A:visited { color: red } /* 방문 했던 연결(visited link) */ A:active { color: lime } /* 활성 연결(active link) */ /* 앤커 이미지 엘레멘트 주위의 테두리 설정은 복합(contextual) 선택자(selector)가 필요하다 */ A:link IMG { border: 2px solid blue } A:visited IMG { border: 2px solid red } A:active IMG { border: 2px solid lime }

부록 B: CSS1 문법

(이 부록은 지명적이다)

(CSS의 어떤 버전의) 최소의 CSS 문법은 지원할 필요가 있는 모든 적용들이 항목 7에 정의되어 있다. 아래의 문법은 훨신 짧게 기술되어 있는데 이는 CSS1의 문법(syntax)을 정의한다.

그러나 어떤 의미에서는 여전히 CSS1의 superset이다. 이 문법에는 표현되지 않은 추가적인 의미적인 제한들이 있다. 부합하는 사용도구는 또한 향 후 버전 부합성(항목 7.1) 처리(parsing), 그 속성과 값 표현(항목 5) 그리고 단위 표현(항목 6)를 준수하여야 한다. 또한 HTML도 제한이 있는데, 예를 들면, CLASS 애트리뷰트의 가능한 값들 등이다.

아래 문법은 LL(1)이다. 그러나 대부분의 사용도구들은 직접 사용하지 않아야 한다. 왜냐하면 이는 그 처리(parsing) 자체를 표현한 것이 아니고, CSS1의 문법 만을 다룬 것이기 때문이다. 이 양식은 인간이 읽기 좋게 최적화하였으며, [15] yacc 이외의 약식 표기도 사용하였다. * : 0 또는 그 이상 + : 1 또는 그 이상 ? : 0 또는 1 | : 대체 가능한(alternative) 항목의 분리 [] : 구룹지우기(grouping)

결과물은 다음과 같다. stylesheet : [CDO|CDC]* [ import [CDO|CDC]* ]* [ ruleset [CDO|CDC]* ]* ; import : IMPORT_SYM [STRING|URL] ';' /* 예: @import url(fun.css); */ ; unary_operator : '-' | '+' ; operator : '/' | ',' | /* empty */ ; property : IDENT ; ruleset : selector [ ',' selector ]* '{' declaration [ ';' declaration ]* '}' ; selector : simple_selector+ [ pseudo_element | solitary_pseudo_element ]? | solitary_pseudo_element ; /* "id"는 엘레멘트 타입에 왼쪽에 P#p007와 같이 추가되는 ID이다. ** "solitary_id" 는 #p007 처럼 그렇게 추가되지 않은 ID이다. ** 글라스(class)들과 가상 글라스(pseudo-class)에서 동시에. */ simple_selector : element_name id? class? pseudo_class? /* 예: H1.subject */ | solitary_id class? pseudo_class? /* 예: #xyz33 */ | solitary_class pseudo_class? /* 예: .author */ | solitary_pseudo_class /* 예: :link */ ; element_name : IDENT ; pseudo_class /* A:link에서 처럼 */ : LINK_PSCLASS_AFTER_IDENT | VISITED_PSCLASS_AFTER_IDENT | ACTIVE_PSCLASS_AFTER_IDENT ; solitary_pseudo_class /* :link에서 처럼 */ : LINK_PSCLASS | VISITED_PSCLASS | ACTIVE_PSCLASS ; class /* P.note에서 처럼 */ : CLASS_AFTER_IDENT ; solitary_class /* .note에서 처럼 */ : CLASS ; pseudo_element /* P:first-line에서 처럼 */ : FIRST_LETTER_AFTER_IDENT | FIRST_LINE_AFTER_IDENT ; solitary_pseudo_element /* :first-line에서 처럼 */ : FIRST_LETTER | FIRST_LINE ; /* id와 solitary_id에서 "#" 다음 부분은 ** 유효한 HTML ID 값 이어야 한다는 제한이 있다. ** 예: "#x77"는 OK, 그러나 "#77"는 무효. */ id : HASH_AFTER_IDENT ; solitary_id : HASH ; declaration : property ':' expr prio? | /* empty */ /* 문법 오류를 방지하기 위하여 */ ; prio : IMPORTANT_SYM /* 중요(!important) */ ; expr : term [ operator term ]* ; term : unary_operator? [ NUMBER | STRING | PERCENTAGE | LENGTH | EMS | EXS | IDENT | hexcolor | URL | RGB ] ; /* 색상에서 "#" 다음에 16 진수(0-9a-fA-F)가 ** 3 개 또는 6 개가 나와야 한다는 제한이 있다. ** 예: "#000"는 OK, 그러나 "#abcd"는 무효. */ hexcolor : HASH | HASH_AFTER_IDENT ;

다음은 [16] flex로 기술한 토큰화하는 것(tokenizer)이다. flex의 8-bit 적용을 가정함을 주시하라. 토큰화하는 것(tokenizer)은 대소문자를 구분한다(case-insensitive). (flex command line option -i). unicode \\[0-9a-f]{1,4} latin1 [¡-ÿ] escape {unicode}|\\[ -~¡-ÿ] stringchar {escape}|{latin1}|[ !#$%&(-~] nmstrt [a-z]|{latin1}|{escape} nmchar [-a-z0-9]|{latin1}|{escape} ident {nmstrt}{nmchar}* name {nmchar}+ d [0-9] notnm [^-a-z0-9\\]|{latin1} w [ \t\n]* num {d}+|{d}*\.{d}+ string \"({stringchar}|\')*\"|\'({stringchar}|\")*\' %x COMMENT %s AFTER_IDENT %% "/*" {BEGIN(COMMENT);} <COMMENT>"*/" {BEGIN(0);} <COMMENT>\n {/* ignore */} <COMMENT>. {/* ignore */} @import {BEGIN(0); return IMPORT_SYM;} "!"{w}important {BEGIN(0); return IMPORTANT_SYM;} {ident} {BEGIN(AFTER_IDENT); return IDENT;} {string} {BEGIN(0); return STRING;} {num} {BEGIN(0); return NUMBER;} {num}"%" {BEGIN(0); return PERCENTAGE;} {num}pt/{notnm} {BEGIN(0); return LENGTH;} {num}mm/{notnm} {BEGIN(0); return LENGTH;} {num}cm/{notnm} {BEGIN(0); return LENGTH;} {num}pc/{notnm} {BEGIN(0); return LENGTH;} {num}in/{notnm} {BEGIN(0); return LENGTH;} {num}px/{notnm} {BEGIN(0); return LENGTH;} {num}em/{notnm} {BEGIN(0); return EMS;} {num}ex/{notnm} {BEGIN(0); return EXS;} <AFTER_IDENT>":"link {return LINK_PSCLASS_AFTER_IDENT;} <AFTER_IDENT>":"visited {return VISITED_PSCLASS_AFTER_IDENT;} <AFTER_IDENT>":"active {return ACTIVE_PSCLASS_AFTER_IDENT;} <AFTER_IDENT>":"first-line {return FIRST_LINE_AFTER_IDENT;} <AFTER_IDENT>":"first-letter {return FIRST_LETTER_AFTER_IDENT;} <AFTER_IDENT>"#"{name} {return HASH_AFTER_IDENT;} <AFTER_IDENT>"."{name} {return CLASS_AFTER_IDENT;} ":"link {BEGIN(AFTER_IDENT); return LINK_PSCLASS;} ":"visited {BEGIN(AFTER_IDENT); return VISITED_PSCLASS;} ":"active {BEGIN(AFTER_IDENT); return ACTIVE_PSCLASS;} ":"first-line {BEGIN(AFTER_IDENT); return FIRST_LINE;} ":"first-letter {BEGIN(AFTER_IDENT); return FIRST_LETTER;} "#"{name} {BEGIN(AFTER_IDENT); return HASH;} "."{name} {BEGIN(AFTER_IDENT); return CLASS;} url\({w}{string}{w}\)| url\({w}([^ \n\'\")]|\\\ |\\\'|\\\"|\\\))+{w}\) {BEGIN(0); return URL;} rgb\({w}{num}%?{w}\,{w}{num}%?{w}\,{w}{num}%?{w}\) {BEGIN(0); return RGB;} [-/+{};,#:] {BEGIN(0); return *yytext;} [ \t]+ {BEGIN(0); /* 공간 무시 */} \n {BEGIN(0); /* 공간 무시 */} \<\!\-\- {BEGIN(0); return CDO;} \-\-\> {BEGIN(0); return CDC;} . {fprintf(stderr, "%d: Illegal character (%d)\n", lineno, *yytext);}

부록 C: 엔코딩(encoding)

(이 부록은 지명적이 아니고 정보를 제공하기 위한 것이다.)

HTML 문서들은 대략 30,000개의 유니코드(Unicode)에서 정의한 다른 글자들을 가질 수 있다. 많은 문서들은 몇 백가지 글자로서 충분하다. 많은 글꼴들 또한 몇 백가지의 도형(glyph)들 만을 가지고 있다. 이 부록은, 항목 5.2 글꼴의 속성들과 조합하여, 문서의 글자들과 글꼴의 도형(glyph)들이 어떻게 서로 맞는가를 설명한다.

글자 엔코딩(encoding)

HTML 문서의 내용(content)은 글자(character)들과 마크업(markup)들의 연속이다. 쓰여진 것이 송신되면, 이는, 여러가지 가능한 방법 중 한가지 엔코딩(encoding)을 사용하여, 바이트(byte)들의 연속으로 바뀌어(encode) 진다. HTML 문서는 글자들은 찾기 위 해 엔코딩되어야 한다. 예를 들어, 서부 유럽에서, 관습적으로 a-with-grave-accent (à)를 위하여, 244 바이트(bite)를 사용하였다. 그러나 히브리어(Hebrew)에서는, 224을 Aleph를 위하여 사용하는 것이 더 보편적이다. 일본어에서는 한 바이트(byte)의 의미가 그 뒤의 바이트들에 의하여 달라진다. 일부 엔코딩(encoding)에서는 한 글자가 두개(혹은 그 이상)의 바이트들로 엔코딩된다.

사용도구는 http header에 있는 글자세트("charset")를 점검하여 어떻게 엔코딩할 것인가를 안다. 전형적인 엔코딩(encoding: 글자세트의 값)들은 영어에서 아스키("ASCII"), 서유럽에서 "ISO-8859-1", 히브리어에서 "ISO-8859-8", 일본어에서 "Shift-JIS", 한글에서 "EUC-KR"이다.

[2] HTML 2.0과 [4] HTML 4에서, 일반적으로 유니코드(Unicode)에 의하여 정의되어 있는 30,000여 다른 글자들을 허용한다. 그렇게 많은 글자들을 사용하는 문서들은 많지 않을 것이다. 그리고 올바른 엔코딩(encoding)의 선택은 일반적으로 그 문서가 한 글자마다 한 바이트(byte) 만 필요하게 해 줄 것이다. 엔코딩 밖에 있는 때때로 사용하는 글자들도 글자 참조 수치를 입력하여 사용할 수 있다. '&#928;'는 어느 엔코딩를 사용하던 관계없이 항상 그리스어 Pi의 대문자(Π)를 의미한다. 사용도구들은, 단지 몇가지 엔코딩(encoding)들 만을 채택한다 하더라도, 어떤 유니코드(Unicode) 글자도 처리할 수 있어야 한다는 점을 주시하라.

HTML의 엔코딩 설명을 참조하라.

글꼴(font) 엔코딩(encoding)

글꼴(font)는 글자(character)들을 포함하지 않고 글자들의 도형(glyph)이라 불리우는 그림(picture)들을 갖는다. 이 도형(glyph)들은 아우트라인(outline) 비트맵(bitmap)에서 글자의 독특한 표현을 한다. 명시적(explicit)으로 혹은 암시적(implicit)으로, 각 글꼴는 그에 연관된 글꼴 엔코딩 표(font encoding table)를 갖는데, 이는 각 도형(glyph)이 어떤 글자을 표현하는가를 말해 준다. 타입(Type) 1 글꼴(font)는, 표에서 엔코딩 벡터(encoding vector)로 참조된다.

실제로, 많은 글꼴들은 한 글자를 위하여 여러가지 도형(glyph)들을 같는다. 어느 도형(glyph)이 사용되는가는 언어의 명령(rule)들이나 도형 설계자를 참조하는데 따라 채택된다.

예를 들어 아랍어(Arabic)에서, 모든 글자들은 네가지 다른 모양(shape)들을 갖는데, 그 글자가 단어의 앞에 오는가, 가운데 오는가, 끝에오는가 혹은 독립적으로 사용되는가에 따라 다르다. 이는 모든 경우에 같이 적용되고, 따라서 HTML 문서에서 한 가지의 글자인 것이다. 그러나 인쇄되면 매 번 다르게 보인다.

그래픽 디자이너들이 여러 대체 모양들 중에서 골라 사용할 수 있는 글꼴들도 남겨 놓았다. 불행하게도 CSS1은 아직 이들 대체 모양을 선택하는 수단을 제공하지 못하고 있다. 현재로서는 선택된 그런 글꼴는 항상 디폴트 모양(shape)으로 된다.

글꼴쎄트(font set)

단일 글꼴로 문서나 단일 엘레멘트의 모든 글자들을 표현하기에 불 충분한 경우의 문제를 다루기 위하여, CSS1는 글꼴쎄트(font set)들의 사용을 허용한다.

CSS1에서 글꼴쎄트(font set)는 글꼴들의 목록이다. 모두 같은 스타일(style)과 크기를 갖고있으며, 어떤 글자가 도형(glyph)을 갖고 있는가를 점검하는 일련의 순서이다. 한 엘레멘트가 영어 텍스트를 가지고 수학기호(mathematical symbol)들과 섞여 있을 때, 하나는 글자와 수자, 다른 하나는 수학기호를 갖는, 두가지 글꼴의 글꼴쎄트가 필요할 수 있다. 글꼴쎄트를 선택하는 기능(mechanism)에 대한 설명은 항목 5.2 글꼴 속성을 참조하라.

아래 글꼴쎄트 예제는 문장에 영어(Latin) 글자들, 일본어 글자들과 수학기호들이 들어가는 것이 예상되는 경우에 적당하다. BODY { font-family: Baskerville, Mincho, Symbol, serif }

Baskerville 글꼴(Latin 글자만 있슴)에 있으면 그 글꼴에서 채택하고, 일본어는 Mincho 글꼴에서, 그리고 수학기호는 Symbol 글꼴에서 올 것이다. 다른 글자들은 (희망적으로) 일반 글꼴(generic font family)인 'serif' 글꼴에서 올 것이다. 'serif' 글꼴는 하나이상의 다른 글꼴들이 없을 때도 사용될 수 있다.

부록 D: 감마(gamma) 수정

(이 부록은 지명적이 아니고 정보를 제공하기 위한 것이다.)

감마(gamma)에 대하여 잘 모르면 [12] PNG 규격의 영문 감마 안내서(Gamma Tutorial)를 참조하라.

사용도구들이 CRT(화면)에 디스플레이는, 계산하는데 있어, 이상적인 CRT를 가정하고 떨림(dithering)에 의하여 발생되는 gamma의 효과를 무시할 수 있다. 이는 현재의 프래트폼(platform)들에서 필요한 처리를 최소화 함을 의미한다.

MS-Windows를 사용하는 PC

없슴

X11을 사용하는 Unix

없슴

QuickDraw를 사용하는 Mac

감마(gamma) 1.39 적용 [13] (ColorSync-savvy 적용들은 올바른 색상 보정을 위하여 단순히 sRGB ICC profile [14]을 ColorSync에 전달한다.)

X를 사용하는 SGI

감마(gamma) 값을 /etc/config/system.glGammaVal로 부터 적용
(디폴트 값은 1.70; Irix 6.2 이상에서 운영되는 적용들은 단순히 sRGB ICC profile을 색상 관리 시스템에 전달한다)

NeXT using NeXTStep

감마(gamma) 2.22 적용

감마를 적용한다("applying gamma")는 것은 운영체계(OS)에서 처리되기 전에 각 R, G, B 삼색이 R'=R^gamma, G'=G^gamma, B'=B^gamma로 환산되어야 한다는 의미이다.

이는 브라우저마다 아래와 같이 한번에 256-엘레멘트 조견표(table)를 만들므로서 신속히 이루어 질 수 있다. for i := 0 to 255 do raw := i / 255; corr := pow (raw, gamma); table[i] := trunc (0.5 + corr * 255.0) end

그러면 이것은 색상 애트리뷰트마다나 픽셀(pixel)마다의 어떤 고급 계산의 필요를 피할 수 있다.

부록 E: CSS1의 적용성과 확장성

(이 부록은 지명적이 아니고 정보를 제공하기 위한 것이다.)

CSS1에 대하여 작업하는 목표는 HTML 문서들을 위하여 간단한 스타일쉬트 기능을 만들기 위한 것이다. 현재의 규격은 스타일쉬트을 웹에 사용 타당성을 제시하는 간단성과 풍부한 보이는 제어를 위하여 제작자들로부터의 압력에 의한 것의 사이에서 균형을 갖춘 상태이다. CSS1는 다음 사항들을 제공한다.

• 보이(visual)는 마크업(markup) 대체: HTML 표현(extension)들, 예를 들어 "CENTER", "FONT", "SPACER" 등은 CSS1 스타일쉬트로 쉽게 대체된다.
• 더 멋있는 마크업(markup): 인기있는 작은 대분자(small-caps) 스타일을 얻기 위해 "FONT" 엘레멘트들을 사용하는 대신에 스타일쉬트에서 하나의 선언(declaration)으로 충분하다. 마크업(markup)과 비교하면: <H1>H<FONT SIZE=-1>EADLINE</FONT></H1>

  스타일쉬트로는: H1 { font-style: small-caps } <H1>Headline</H1>

• 여러가지 통합 레벨들: CSS1 스타일 명령(rule)들은 외부 스타일쉬트로 부터 가져 올 수 있고, 'STYLE' 엘레멘트에 포함시킬 수 있고, 또는 'STYLE' 애트리뷰트 안에 넣을 수 있다. 나중의 선택은 HTML 표현(extension)들로 부터의 변환을 용이하게 한다.
• 새로운 효과들: 일부 새로운 보이는 효과들이 사용자의 흥미를 위하여 추가되었다. 인쇄술을 위한 가상 엘레멘트들과 배경(background) 속성의 추가적 값들은 여기에 해당된다.
• 배수에 의한 조정 가능(scalability): CSS1는 단순한 텍스트 터미날들에서부터 고 해상도 색상 워크스테이션(workstation)들까지 두루 유용하다. 제작자들은 한 스타일쉬트을 써서 합리적으로 의도하는 스타일이 가능한 가장 좋은 방식으로 나타 날 것이라는 것을 확실히 할 수 있다.

CSS1는 아래 사항들을 제공하지 않는다.

• 픽셀(pixel) 단위 제어: CSS1 값들의 제어 수준보다는 단순성에 중점을 두어, 이미지 배경과 스타일화된 HTML의 조합이 강력 함에도 불구하고, 픽셀(pixel) 수준의 제어는 불가능하다.
• 제작자 제어: 제작자는, 암시는 할 수 있을 뿐, 어떤 스타일의 사용을 보완할 수 없다.
• 배치(layout) 언어: CSS1는, 텍스트의 흐름(text-flow), 프레임의 겹침(overlapping) 등, 복수 컬럼들을 제공하지 않는다.
• 처리(parse) 계통(tree)에서 풍부한 쿼리(query) 언어: 다른 스타일쉬트들(예를 들어 [6] DSSSL)은 완전한 쿼리(query) 언어를 제공하는데 반 해, CSS1는 처리(parse) 계통(tree)에서 조상(ancestor) 엘레멘트들을 찾는 기능 만을 제공할 수 있다.

CSS에서 다음 여러 방향으로 확장될 것으로 기대한다.

• 종이(paper): HTML 문서들의 개선된 인쇄 지원
• 보이지 않는(non-visua) 메디아 지원: 속성들 목록에 추가하는 작업이 진행되고 있으며, 해당 값들은 음성 장치나 점자 출력을 지원한다.
• 색상명(color name)들: 현재의 목록의 확장
• 글꼴(font)들: 현재의 CSS1 글자(font) 속성들을 보완하기 위하여 보다 정확한 글꼴 규격 체계가 기대 됨.
• 값들과 속성들: 관련 업체(vendor)들에 의한 값들과 속성들의 CSS1 쎄트에 확장들이 제안될 것으로 기대한다. 이 방향으로의 확장은 규격의 자질구레한 부분이나, 서로 다른 사용도구들 사이에서 공동적 사용(interoperability)을 다룬다.
• 배치(layout) 언어: 전통적인 편집기등에서 두 차원 배치(two-dimensional layout)를 지원
• 다른 문서타입정의(DTD)들: CSS1은 예를 들어 'CLASS'와 'ID' 애트리뷰트들의 특수 상태(status) 등 HTML에 맞는(HTML-specific) 부분들을 갖는다. 그러나 쉽게 다른 문서타입정의(DTD)들의 적용에 확장되어야 할 것이다.

CSS는 다음 사항을 취급하지 않을 것이다.

• 프로그램 언어

부록 F: 1996년 12월 17일 버전으로 부터의 변경들

(이 부록은 지명적이 아니고 정보를 제공하기 위한 것이다.)

이 규격은 1996년 11월 17일 최초 발표된 것으로부터 개정된 CSS1 추천안으로, 아래 목록은 모든 변경들을 설명한다. 스타일쉬트 오류("errata")를 선택 함으로서 해당 변경들이 부각된다.

Komachi Yushi, Steve Byrne, Liam Quinn, Kazuteru Okahashi, Susan Lesch, Tantek Çelik에게 이 개정을 준비하는데 도움을 준 것에 대해 감사한다.

철자와 인쇄 상의 오류들, 일반 오류들, 구조와 구성 조정----------------------

맨위이 문서( http://trio.co.kr/webrefer/css1/rec-css1.html)는 자유로이 연결 사용이 가능함. (수정일 05/12/2006 18:20:32)

하이퍼텍스트 전송규약 1.1표준(안)

한국전자통신연구소

요약

하이퍼텍스트 전송 규약(HTTP)은 분산 정보 시스템, 종합 정보시스템 및 하이퍼미디
어 정보시스템에서 사용하는 응용 계층 규약으로서 요구 방법의 확장을 통해서 네임
서버와 분산 객체 관리 시스템과 같은 수많은 작업에 사용될 수 있는 보편적인
지향형 규약이다. HTTP는 어떤 문서의 데이터 표현 형식을 규정하고 협상하여 전송
중인 데이터와 무관하게 시스템을 구축할 수 있게 한다.

HTTP는 1990년 이후 World-Wide Web 범 세계 정보 이니셔티브에 의하여 사용되고
있다. 이 규격은 "HTTP/1.1"로 언급되는 규약을 정의하고 있다.

목차

 1 도입...........................................................  7
  1.1 목적 ...................................................  7
  1.2 필요 사항 .........................................  7
  1.3 용어 ...................................................  8
  1.4 전반적인 운영 ........................... 11
 2 기호 관례 및 일반적인 문법..............  13
  2.1 추가된 BNF .......................................  13
  2.2 기본적인 규칙 ..................................  15
 3 규약 파라미터...............................  17
  3.1 HTTP 버전 ........................................  17
  3.2 보편적 자원 식별자(Uniform Resource Identifiers) ........................  18
   3.2.1 일반적 형식 .............................  18
      3.2.2 http URL .........................................  19
      3.2.3 URI 비교   ..................................  20
  3.3 날짜/시간 형식...................................  21
      3.3.1 완전한 날짜 .................................  21
      3.3.2 Delta Seconds .................  22
     3.4 문자 집합 ..........................................  22
    3.5 내용 코딩 (Content Coding).............  23
    3.6 전송 코딩 (Transfer Coding)............  24
    3.7 미디어 타입 ......................................  25
     3.7.1 정형화(Canonicalization) 및 텍스트 기본값 ...............  26
     3.7.2 Multipart Type  ....................................  27
    3.8 제품 토큰 ......................................  28
    3.9 품질 등급 값..................................  28
    3.10 언어 태그......................................  28
    3.11 엔터티 태그.......................................  29
    3.12 영역 단위 .....................................  30
 4 HTTP 메시지.........................................  30
    4.1 메시지 유형 ...................................  30
    4.2 메시지 헤더 ...................................  31
    4.3 메시지 본문 ...................................  32
    4.4 메시지 길이 ...................................  32
    4.5 일반적인 헤더 필드 .....................  34
 5 요구........................................................  34
    5.1 Request-Line ........................................  34
     5.1.1 Method .........................................  35
     5.1.2 Request-URI ......................................  35
    5.2 요구에 의해 식별되는 자원 .........  37
    5.3 요구 헤더 필드 ...............................  37
 6 응답..........................................................  38
    6.1 상태-라인 ..........................................  38
     6.1.1 상태 코드 및 이유 문구 ..........  39
    6.2 응답 헤더 필드 ...............................  41

[Page 1]

 7 엔터티(Entity)..........................................................  41
    7.1 엔터티 헤더 필드 ................................  41
    7.2 엔터티 본문 .........................................  42
     7.2.1 유형 ..............................................  42
     7.2.2 길이 ............................................………………………………………………………...  43
 8 접속..........................................................  43
    8.1 지속적인 접속 .................................  43
     8.1.1 목적 ..............................................  43
     8.1.2 전반적인 운영..............................  44
     8.1.3 프락시 서버(Proxy Servers) ........  45
     8.1.4 실제적인 고려 사항 ..................  45
    8.2 메시지 전송 필요 조건 .................  46
 9 Method 정의.............................  48
    9.1 안전 및 멱등원(冪等元) method ..  48
   9.1.1 안전 method.....................................  48
      9.1.2 멱등원 method.................................  49
  9.2 OPTIONS ...............................................  49
    9.3 GET ........................................................  50
    9.4 HEAD ....................................................  50
    9.5 POST ......................................................  51
    9.6 PUT ........................................................  52
    9.7 DELETE .................................................  53
    9.8 TRACE ...................................................  53
 10 상태 코드 정의.......................................  53
  10.1 Informational 1xx (정보를 알려 주는 1xx) ..................................  54
     10.1.1 100 Continue (계속).....................................................................  54
     10.1.2 101 Switching Protocols (규약 전환)..................................  54
    10.2 Successful 2xx (성공을 알려 주는 2xx) .......................................................  54
     10.2.1 200 OK .........................................................................................  54
     10.2.2 201 Created (생성 되었음) .........................................................  55
     10.2.3 202 Accepted (접수 되었음).......................................................  55
     10.2.4 203 Non-Authoritative Information (비 인증 정보) ..................  55
     10.2.5 204 No Content (내용이 없음) ......................... ...... ...... ...........  55
     10.2.6 205 Reset Content (내용을 지움)............................ ...... ............  56
     10.2.7 206 Partial Content (부분적 내용)....................... ...... ...............  56
    10.3 Redirection 3xx (방향을 재설정하는 3xx).....................................  56
     10.3.1 300 Multiple Choices (복수 선택).......................... ...... .... ........  57
     10.3.2 301 Moved Permanently (영구 이동).............. ...........................  57
     10.3.3 302 Moved Temporarily (임시 이동)..........................................  58
     10.3.4 303 See Other (다른 것을 참조).................................................  58
     10.3.5 304 Not Modified (변경되지 않았음).........................................  58
     10.3.6 305 Use Proxy (프락시를 사용할 것)........................................  59
    10.4 Client Error 4xx (클라이언트 에러 4xx).........................................  59
     10.4.1 400 Bad Request (잘못된 요구)...................................................  60
     10.4.2 401 Unauthorized (인증되지 않았음)..........................................  60
     10.4.3 402 Payment Required (요금 지불 요청)....................................  60
     10.4.4 403 Forbidden (금지되었음)........................................…………………………..............  60

[Page 2]

     10.4.5 404 Not Found (찾을 수 없음).....................................................  60
     10.4.6 405 Method Not Allowed (Method를 사용할 수 없음)..............  61
     10.4.7 406 Not Acceptable (접수할 수 없음).........................................  61
     10.4.8 407 Proxy Authentication Required (프락시 인증이 필요함)....  61
     10.4.9 408 Request Timeout (요구 시간 초과).......................................  62
     10.4.10 409 Conflict (충돌).......................................................................  62
     10.4.11 410 Gone (내용물이 사라졌음)..................................................  62
     10.4.12 411 Length Required (길이가 필요함)........................................  63
     10.4.13 412 Precondition Failed (사전 조건 충족 실패)........................  63
     10.4.14 413 Request Entity Too Large (요구 엔터티가 너무 큼).............  63
     10.4.15 414 Request-URI Too Long (Request-URI이 너무 김)..................  63
     10.4.16 415 Unsupported Media Type (지원되지 않는 media type)..  63
    10.5 Server Error 5xx (서버 에러 5xx)......................................................  64
     10.5.1 500 Internal Server Error (서버 내부 에러)..................................  64
     10.5.2 501 Not Implemented (구현되지 않았음).....................................  64
   10.5.3 502 Bad Gateway (불량 게이트웨이) ....................................................  64
      10.5.4 503 Service Unavailable (서비스를 사용할 수 없음) .........................  64
      10.5.5 504 Gateway Timeout (게이트웨이 시간 초과)....................................  64
      10.5.6 505 HTTP Version Not Supported (지원되지 않는 HTTP 버전) ........  65
 11 접속 인증 ....................................................................  65
  11.1 기본 인증 scheme ........................................  66
    11.2 요약 인증 scheme .......................................................  67
 12 내용 협상(Content Negotiation)....................................  67
  12.1 서버가 주도하는 협상 .........................................  68
    12.2 에이전트가 주도하는 협상...................................  69
    12.3 투명한 협상(Transparent Negotiation ) ..................  70
 13 HTTP에서의 캐시........................................................  70
   13.1.1 캐시의 정확성 ..................................................  72
      13.1.2 경고 ....................................................................  73
      13.1.3 캐시-제어 메커니즘 .........................................  74
      13.1.4 명백한 사용자 에이전트 경고 ......................  74
      13.1.5 규칙 및 경고의 예외 사항 ............................  75
      13.1.6 클라이언트가 제어하는 행태 ........................  75
  13.2 유효일 모델 ...........................................................  75
     13.2.1 서버가 명시한 만기일 ....................................  75
     13.2.2 스스로 만기일을 찾음(Heuristic Expiration) ..  76
      13.2.3 경과 시간 계산(Age Calculations) ...................  77
      13.2.4 만기일 계산 ......................................................  79
      13.2.5 만기일 값을 명확하게 하기 .........................  80
      13.2.6 복수의 응답을 명확하게 하기 ......................  80
    13.3 검증 모델 ...............................................................  81
      13.3.1 최종 갱신 날짜 ................................................  82
      13.3.2 엔터티 태그 캐시 검증자(Validators) ................  82
      13.3.3 약한/강한 검증자 .............................................  82
      13.3.4 엔터티 태그와 최종 갱신 날짜를 사용할 때를 결정하는 규칙.......  85
      13.3.5 검증을 하지 않는 조건 법 .................................................................  86
    13.4 응답을 캐시할 수 있는 정도(Cachability) .....................……………................…..…....  86

[Page 3]

    13.5 캐시에서 응답을 구축하기 ..........................  87
     13.5.1 End-to-end 및 Hop-by-hop 헤더 ...............  88
      13.5.2 변경할 수 없는 헤더 ...............................  88
      13.5.3 헤더의 결합 ...............................................  89
      13.5.4 바이트 영역(Byte Ranges)의 결합............  90
    13.6 협상을 통한 응답을 캐시하기 ....................  90
    13.7 공유/비공유 캐시.............................................  91
    13.8 에러 또는 불완전한 응답 캐시 행태 .......  91
    13.9 GET 및 HEAD의 부작용 .............................  92
    13.10 갱신 또는 삭제 후의 무효화 ....................  92
    13.11 의무적으로 서버를 통하여 기입................  93
    13.12 캐시 대체 ......................................................  93
    13.13 History List ................................  93
 14 헤더 필드 정의.....................................................  94
  14.1 Accept .....................................................  95
  14.2 Accept-Charset.............................  97
    14.3 Accept-Encoding................................  97
    14.4 Accept-Language....................................  98
    14.5 Accept-Ranges ......................................  99
    14.6 Age...........................................................  99
    14.7 Allow...........................................  100
    14.8 Authorization.........................................  100
    14.9 Cache-Control....................................  101
   14.9.1 무엇을 캐시할 수 있는가................................  103
      14.9.2 캐시에 의해 무엇을 저장할 수 있는가........  103
      14.9.3 기본적인 만기일 메커니즘의 변경 ..............  104
      14.9.4 캐시의 재검증 및 Reload 제어 ...................  105
      14.9.5 비 변경 지시어 ................................................  107
      14.9.6 캐시 제어 확장..................................................  108
  14.10 Connection...............................................  109
    14.11 Content-Base................................  109
    14.12 Content-Encoding....................  110
    14.13 Content-Language........................  110
    14.14 Content-Length..............................  111
    14.15 Content-Location.........................  112
    14.16 Content-MD5..............................  113
    14.17 Content-Range.......................  114
    14.18 Content-Type..........................  116
    14.19 Date................................................  116
    14.20 ETag .........................................................................  117
    14.21 Expires.......................................................  117
    14.22 From.......................................................  118
    14.23 Host.....................................................  119
    14.24 If-Modified-Since ....................................................  119
    14.25 If-Match ...................................................................  121
    14.26 If-None-Match .........................................................  122
    14.27 If-Range ...................................................................  123
    14.28 If-Unmodified-Since ................................................  124
    14.29 Last-Modified ..................……………………………………………………………........... 124

[Page 4]

    14.30 Location...........................................  125
    14.31 Max-Forwards.............................  125
    14.32 Pragma ......................................................................  126
    14.33 Proxy-Authenticate.................  127
    14.34 Proxy-Authorization................  127
    14.35 Public ........................................................................  127
    14.36 Range........................................................  128
   14.36.1 Byte Ranges................  128
      14.36.2 Range Retrieval Requests  130
  14.37 Referer............................................  131
    14.38 Retry-After..............................  131
    14.39 Server.......................................................  132
    14.40 Transfer-Encoding..............  132
    14.41 Upgrade.......................................  132
  14.42 User-Agent........................  134
    14.43 Vary.........................................................  134
    14.44 Via.........................................................  135
    14.45 Warning...............................................  137
    14.46 WWW-Authenticate......................  139
 15 보안에 대한 고려 사항...............................................  139
  15.1 클라이언트의 인증 ...............................................  139
    15.2 인증 scheme을 선택할 수 있도록 함 ...................................  140
    15.3 서버 로그 정보의 남용 .......................................  141
    15.4 민감한 정보의 전송 .............................................  141
    15.5 파일 및 경로 이름에 기초한 공격 ...................  142
    15.6 개인적인 정보 ...........................................................  143
    15.7 Accept 헤더와 연결된 사생활 보호의 이슈 ...........  143
    15.8 DNS Spoofing(속이기) ............................................  144
    15.9 Location 헤더와 Spoofing(속이기) ........................  144
 16 감사의 말......................................................................  144
 17 참고 문헌......................................................................  146
 18 저자의 주소..................................................................  149
 19 부록................................................................................  150
  19.1 Internet Media Type message/http......................  150
    19.2 Internet Media Type multipart/byteranges ............  150
    19.3 Tolerant Applications.............................  151
    19.4 HTTP 엔터티와 MIME 엔터티의 차이점.........................................................  152
   19.4.1 규범적인 폼으로 변환 ....................................  152
     19.4.2 날짜 형식의 변환 ............................................  153
     19.4.3 Content-Encoding 소개...............................................  153
     19.4.4 No Content-Transfer-Encoding ........................................  153
      19.4.5 Multipart Body-Part의 HTTP 헤더 필드 .......  153
     19.4.6 Transmit-Encoding 소개 .............................................  154
     19.4.7 MIME-Version ..................................................………………………………………...... 154

[Page 5]

  19.5 HTTP/1.0 이후 변경 사항 ....................................  154
     19.5.1 복수의 홈을 가진 웹 서버를 단순하게 하기 위한 변경 사항 및 
           IP 주소 보존 .....................................................  155
  19.6 추가 기능 ...............................................................  156
     19.6.1 추가적인 요구 method ............................................  156
     19.6.2 추가 헤더 필드 정의 ......................................  156
    19.7 이전 버전과의 호환성 .........................................  160
     19.7.1 HTTP/1.0 지속적인 연결과의 호환성.............  161

[Page 6]

1 서론

1.1 목적

하이퍼텍스트 전송 규약(HTTP)은 분산 정보시스템, 종합 정보시스템 및 하이퍼미디어 정보시
스템에서 사용하는 응용계층의 규약이다. HTTP는 1990년 이후 World-Wide Web 범 세계 정보
이니셔티브에 의하여 사용되고 있다.  "HTTP/0.9"로 언급되는 HTTP의 첫 버전은 인터넷 상에
서 저장되어 있는 원래 데이터(raw data)를 전송하기 위한 단순한 규약이었다. RFC 1945 [6]이
규정한 HTTP/1.0은 메시지를 전송되는 문서 데이터에 대한 메타 정보 및 요구/응답 용어의
변경자를 포함하는 MIME과 유사한 메시지의 형식으로 사용할 수 있도록 함으로써 규약을 향
상시켰다. 그러나 HTTP/1.0은 계층적 프락시(hierarchical proxies), 캐시, 지속적인 연결의 필요
성 및 가상 호스트(virtual host) 등의 영향을 충분히 고려하지 않았다. 또한 "HTTP/1.0"을 지원
한다고 하면서도 규약의 불완전 구현 및 오해에 의한 잘못된 구현 등에 의해 응용 프로그램
사이에 종종 문제가 발생하였기에 상호 협상할 수 있는 응용 프로그램이 상대방의 진정한 성
능을 파악할 수 있도록 규약 버전을 갱신할 필요가 생겼다.

이 규격은 "HTTP/1.1"로 불리우는 하이퍼텍스트 전송 규약을 정의한다. 이 규약은 기능을 신
뢰할 수 있도록 구현하기 위해 HTTP/1.0보다 더 엄격한 필요 조건을 포함하고 있다.

실제적인 정보 시스템은 단순한 조회보다 검색, 프런트-엔드(front-end) 갱신 및 주석 달기 등
많은 기능을 필요로 한다. HTTP는 요구의 목적을 표시하는 일련의 개방된 method를 (open-
ended set of methods) 허용한다. 이 규약은 보편적 자원 식별자(URI) [3][20], 자원 위치 (URL) [4]
또는 자원 이름(URN)이 제공하는 참고 방법에 따라 method를 적용할 자원을 지칭하는 데 사
용한다. 메시지는 다용도 인터넷 메일 확장(MIME)에서 정의된 것처럼 인터넷 메일에서 사용
되는 것과 유사한 형식으로 전송된다.

HTTP는 사용자 에이전트, 프락시/게이트웨이와 SMTP [16], NNTP [13], FTP [18], Gopher [2], 및
WAIS [10] 등을 지원하는 다른 인터넷 시스템 사이의 통신을 위한 범용 규약으로서 사용된다.
이러한 방식으로 HTTP는 기본적인 하이퍼미디어가 다양한 애플리케이션의 자원에 접근할 수
있도록 한다.

1.2 필요 조건

이 규격은 각각의 특별한 필요 조건의 중요도를 정의할 때 RFC 1123 [8]와 동일한 용어를 사
용한다. 이러한 용어는 다음과 같다.

   MUST
이 단어 또는 "요구된"이라는 형용사는 해당 항목이 규격의 절대적인 필요 조건임을 의미
한다.

[Page 7]

   SHOULD
이 단어 또는 "추천된"이라는 형용사는 특정 상황에서 해당 항목을 무시할 합당한 이유가
있을 수 있다는 것을 의미한다. 그러나 충분히 함축적 의미를 이해해야 하고 다른 방법을
선택하기 전에 사례를 충분히 검토해야 한다.

   MAY
이 단어 또는 "선택적"이라는 형용사는 해당 항목이 진정으로 선택적이라는 것을 의미한
다. 한 판매회사는 특정 항목을 특정 시장이 요구하기 때문에 또는 예를 들어 제품의 기능
을 향상시켜 주기 때문에 다른 판매 회사와 달리 동일한 항목을 포함할 수 있다.

구현 방법이 하나 또는 그 이상의 MUST 규약 필요 조건을 충족시켜 주지 못하면 규약에 따
르지 않는 것이다. 구현 방식이 모든 MUST 및 SHOULD 필요 조건을 충족한다면 "무조건적으
로 충족한다"고 할 수 있고, 모든 MUST 필요 조건을 충족하지만 모든 SHOULD 필요 조건을
충족하지 못한다면 "조건적으로 충족한다"고 할 수 있다.

1.3 용어

이 규격은 HTTP 통신의 참여자 및 객체가 수행하는 역할을 지칭하는 몇몇 용어를 사용하고
있다.

   connection(연결)
통신을 목적으로 두 프로그램 간에 설정된 전송 계층의 가상적 회로

   message(메시지)
HTTP 통신의 기본 전송 단위. 4 장에 규정된 의미론을 따르는 구조적인 데이터 표현 형태
이며, 일련의 8 비트(octets)로 구성되어 있고 연결을 통하여 전송된다.

   request(요구)
       5 장에 규정된 HTTP 요구 메시지.

   response(응답)
       5 장에 규정된 HTTP 응답 메시지.

   resource(자원)
3.2절에 규정되어 있는 URI에 의하여 식별되는 네트워크 데이터 객체 또는 서비스. 자원
은 다양한 표현 형태 (예를 들어 언어, 데이터 형식, 크기 및 해상도)를 지닐 수 있으며 다
양한 방법으로 변형될 수 있다.

[Page 8]

   entity(엔터티)
요구나 응답 메시지의 페이로드(payload)로서 전송되는 정보. 엔터티는 7 장에서 설명된 대
로 Entity-Header 필드 형태의 메타 정보 및 Entity-Body 형태의 내용으로 구성되어 있다.

   representation(표현)
12 장에서 기술한 내용 협상의 통제를 따르는 응답에 포함된 엔터티. 특정한 응답 상태와
연관된 다수의 표현 방법이 있을 수 있다.

   content negotiation(내용 협상)
12 장에서 기술한 대로 요구를 처리할 때 적절한 표현 방법을 선택하는 메커니즘. 어떠한
응답에서는 엔터티의 표현은 협상할 수 있다.(에러 응답 포함)

   variant(변형자)
자원은 특정한 경우에 자원과 관련된 하나 이상의 표현 방식을 가질 수 있다. 이러한 각각
의 표현 방식을 "변형자"라고 부른다. "변형자"라는 용어를 사용한다고 해서 자원이 반드
시 내용 협상의 대상인 것은 아니다.

   client(클라이언트)
요구 메시지를 전송할 목적으로 연결을 설정하는 프로그램.

   user agent(사용자 에이전트)
요구 메시지를 시작하는 클라이언트. 이것은 종종 브라우저, 편집기, 스파이더(웹을 탐색하
는 로봇) 또는 다른 사용자 툴(tool)일 수 있다.

   server(서버)
요구 메시지를 처리하기 위해 접속을 수신하는 애플리케이션으로서 응답 메시지를 전송한
다. 어떤 프로그램이든 동시에 클라이언트와 서버가 될 수 있다. 이 규격에서 이 용어를
사용하는 것은 프로그램의 일반적인 능력을 참조하기보다는 특정한 연결을 위해 프로그램
이 수행하는 역할만을 참조하는 것이다. 마찬가지로 어떠한 서버도 원서버, 프락시, 게이트
웨이, 터널 등 각 요구의 성격에 따라 동작을 전환하는 역할을 할 수 있다.

   origin server(원서버)
해당 자원이 보관되어 있거나 자원을 생성할 수 있는 서버.

[Page 9]

   proxy(프락시)
다른 클라이언트를 대신하여 요구를 작성할 목적으로 서버와 클라이언트의 역할을 모두
수행하는 중간 프로그램. 요구는 내부적으로 처리되어 가능하면 해석되어 다른 서버로 전
달된다. 프락시는 이 규격의 클라이언트와 서버의 필요 조건을 모두 구현해야만 한다.

   gateway(게이트웨이)
다른 서버를 위해 중간 역할을 하는 서버. 프락시와는 달리 게이트웨이는 요구 메시지를,
요청받은 자원을 서비스하는 최종적인 원서버처럼 수신한다. 요구한 클라이언트는 자신이
게이트웨이와 통신하고 있다는 것을 알지 못할 수 있다.

   tunnel(터널)
두 연결 사이를 무조건 중계하는 역할을 하는 중간 프로그램. 활성화되면 비록 HTTP 요구
에 의하여 시작되지만 터널은 HTTP 통신의 참여자로 간주되지 않는다. 터널은 중계하고
있는 양 쪽의 연결이 종결되면 사라진다.

   cache(캐시)
프로그램이 응답 메시지를 저장하는 로컬 저장소. 메시지 보관, 조회 및 삭제를 제어하는
하부 시스템이기도 하다. 캐시는 응답 시간, 향후 네트워크 대역폭 소모 및 동일한 요구를
감소시킬 목적으로 캐시할 수 있는 응답을 저장한다. 어떤 클라이언트나 서버도 캐시를 포
함할 수 있다. 단지 터널 역할을 하는 서버는 캐시를 사용할 수 없다.

   cachable(캐시할 수 있는)
응답 메시지의 사본을 저장하여 계속적인 요구 응답에 사용할 수 있으면 응답을 캐시할
수 있다고 한다. HTTP 응답의 캐시 가능 여부를 결정하는 원칙은 13 장에 정의되어 있다.
자원을 캐시할 수 있다 하더라도 캐시가 특정 요구에 대하여 캐시 된 사본을 사용할 수
있는지 여부에 대한 추가적인 제한 사항이 있을 수 있다.

   first-hand(직접)
응답이 직접적으로 오며 원서버로부터 하나 또는 그 이상의 프락시를 거쳐옴으로써 발생
하는 불필요한 지연이 없을 경우 응답이 직접 온다고 할 수 있다. 또한 검증이 원서버에서
직접 이루어진다면 응답이 직접 온다고 할 수 있다.

   explicit expiration time(명백한 유효 시간)
원서버가 추가적인 검증 없이는 캐시에 의해 엔터티를 더 이상 되돌려 주지 않기로 한 시
간. 즉, 원서버가 캐시된 데이터의 유효성을 보장할 수 있는 시간.

[Page 10]

   heuristic expiration time(자동으로 설정되는 유효 시간)
분명한 유효 시간이 설정되어 있지 않을 때 캐시가 할당하는 유효 시간

   age(경과 시간)
응답 메시지의 경과 시간은 원서버로부터 전송된 후, 또는 성공적으로 검증된 후의 시간.

   freshness lifetime(신선한 기간)
응답의 생성 시점과 유효시간 만기 시점 사이의 시간 길이

   fresh(신선한)
응답의 경과 시간이 신선한 기간을 넘어서지 않았을 때 응답이 신선하다고 할 수 있다.

   stale(낡은)
응답의 경과 시간이 신선한 기간을 넘어섰다면 응답이 낡았다고 할 수 있다.

   semantically transparent(의미상으로 분명한)
성능을 향상시키고자 하는 목적을 제외하고 캐시의 사용이 요구하는 클라이언트나 원서버
에 영향을 미치지 않을 때 특정한 요구에 대하여 캐시가 "의미상으로 분명하게" 작동한다
고 할 수 있다. 캐시가 의미상으로 분명할 때 클라이언트는 원서버가 직접 처리했을 때와
완전히 동일할 응답을 수신하게 된다.( hop-by-hop 헤더는 제외).

   validator(검증자)
캐시 엔트리가 엔터티의 복사본과 동일한지 알아내는 데 사용하는 규약 요소(예를 들면
엔터티 태그나 Last-Modified 시간)

1.4 Overall Operation

HTTP 규약은 요구/응답 규약이다. 클라이언트는 요구 method, URI, 규약 버전의 형태로 서
버에 요구 메시지를 전송한다. 요구 변경자, 클라이언트 정보, 서버와의 접속에 사용되는
본문 내용을 포함하는 MIME 유형의 메시지가 뒤따른다. 서버는 메시지의 규약 버전 및
성공 또는 실패 코드를 포함하는 상태 정보로서 응답한다. 서버 정보, 엔터티 메타 정보,
Entity-Body 내용을 포함하는 MIME 유형의 메시지도 뒤따른다.

[Page 11]

대부분의 통신은 사용자 에이전트가 구동하며 특정 원서버에 적용할 요구로 구성되어 있다.
가장 단순한 경우 이것은 사용자 에이전트(UA)와 원서버(O) 사이의 단일 접속(v)에 의해 성취
할 수 있을 것이다.

    request chain ---------------------->
UA ---------------- v ------------------- O
    <--------------------- response chain

좀 더 복잡한 상황은 Request/Response chain에 하나 또는 그 이상의 중간 매개자가 있는 경우
이다. 프락시, 게이트웨이 및 터널의 세 가지 일반적인 중간 매개 형태가 있다. 프락시는 전송
에이전트로 절대 표현 형태의 URI 요구를 수신하여 메시지의 전체 혹은 부분을 재작성한 후
URI가 표시하는 서버로 재구성된 요구 메시지를 전달한다. 게이트웨이는 수신 에이전트로 다
른 서버 위의 계층 역할을 수행하며 필요하다면 원서버의 규약에 맞도록 요구를 해석하기도
한다. 터널은 메시지를 변경하지 않고 두 연결 지점을 연결하는 중계역할을 수행한다. 터널은
통신(communication)이 중간 매개자가 메시지의 내용을 이해할 수 없을 때라도 방화벽과 같은
중간 매개자를 통과할 필요가 있을 때 사용한다.

    request chain ------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
    <------------------------------------ response chain

위의 도표는 사용자 에이전트와 원서버 사이의 세 중간 매개자(A, B 및 C)를 보여 준다. 전체
고리를 통과하는 요구 또는 응답 메시지는 네 개의 별도 연결을 통과하게 된다. 몇몇 HTTP
통신 선택 사항은 최고 근접 거리의 비터널 이웃과의 통신, 연쇄적 연결 고리의 마지막 부분
에만 또는 연결 고리에 따르는 모든 연결에 적용되기 때문에 이러한 구분은 중요하다. 그림이
선형이지만 각 참여자는 복수의 동시 통신에 참여할 수 있다. 예를 들어 B는 A의 요구를 처
리함과 동시에 A를 제외한 복수의 클라이언트 요구를 수신하고/수신하거나 C 이외의 서버에
게 요구를 전송할 수 있다.

터널 역할을 수행하는 것이 아닌 통신에 참여하는 어떤 것이라도 요구를 처리할 때 내부 캐시
를 사용할 수 있다. 캐시의 효과는 연결 고리를 따라 참가자 중 하나가 해당되는 요구에 적용
할 수 있는 캐시된 응답을 갖고 있다면 Request/Response chain이 짧아진다. 다음은 UA 또는 A
가 캐시하지 않은 요구에 대한 O (C를 경유) 초기 응답의 사본을 B가 가지고 있을 때의 결과
고리를 설명하고 있다.

[Page 12]

    request chain --------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
    <-------- response chain

보통 모든 응답을 캐시할 수 있는 것은 아니며 어떤 요구는 캐시 방식에 특별 요구를 하는 변
경자를 포함할 수 있다. 13 장에 캐시 방식과 캐시할 수 있는 응답에 대한 필요 조건이 기록되
어 있다.

사실상 World Wide Web에는 현재 실험되고 있거나 배포되고 있는 캐시와 프락시의 다양한 아
키텍쳐와 환경설정 방법이 있다. 이러한 것 중에는 대륙간 대역폭을 절약하기 위한 프락시 캐
시의 국가적 계층, 캐시 엔트리를 배포하거나 복수로 배포하는 시스템, CD-ROM 등을 통하여
캐시 된 데이터의 하부 세트를 배포하는 조직 등이 있다. HTTP 시스템은 광대역 연결을 통한
기업 인트라넷, 저동력 무선 연결의 PDA를 통한 연결 및 간헐적인 연결에 사용된다. HTTP/1.1
의 목적은 고도의 신뢰성과 신뢰성을 확보할 수 없다면 신뢰할 수 있는 실패의 표시 기능을
지닌 웹 응용프로그램을 개발하는 개발자의 요구를 충족하는 규약 구조물을 새로 소개하면서
도 이미 배포된 다양한 환경을 지원하는 것이다.

HTTP 통신은 대개 TCP/IP 연결을 통하여 이루어진다. 기본 포트는 TCP 80 이지만 다른 포트
를 사용할 수도 있다. 그러나 이것은 HTTP가 인터넷 상의 다른 규약이나 다른 네트워크 위에
서 구현될 수 없게 하는 것은 아니다. HTTP는 단순히 신뢰할 수 있는 전송 수단을 가정할 뿐
이며 이러한 보장을 해 줄 수 있는 어떠한 규약을 사용해도 된다. HTTP/1.1의 요구 응답 구조
를 적용하고자 하는 규약의 전송 데이터 단위로 배치(mapping)하는 것은 이 규격의 범위 밖의
것이다.

HTTP/1.0에서 대부분의 구현 방식은 각각의 요구/응답 교환에 새로운 접속을 사용하는 것이
다. 또한 HTTP/1.1에서는 하나의 접속을 하나 또는 그 이상의 요구/응답 교환에 사용할 수 있
으나 연결이 여러 가지 이유로 단절될 수 있다.( 8.1  절 참조)

2 기호 관례 및 일반적인 문법

2.1 추가된 BNF

이 문서에서 명시된 모든 메커니즘은 설명형 문구로서 RFC 822 [9]에서 사용한 것과 유사한
추가된 Backus-Naur Form (BNF)으로 설명되어 있다. 구현자는 이 규격을 이해하기 위하여 이러
한 기호에 익숙할 필요가 있다. 추가된 BNF는 다음의 구성 요소를 포함한다.

[Page 13]

name = definition
규칙의 이름이 이름 그 자체(둘러싸는 "<" 및 ">"이 없는)이며 정의 부분과는 등호 문자("=")
로 구별된다. 계속되는 공백 문자는 규칙에 대한 규정이 한 줄 이상에 걸쳐 있음을 표시하
는 들여쓰기의 경우에만 의미가 있다. SP, LWS, HT, CRLF, DIGIT, ALPHA 등과 같은 몇몇 기본
규칙은 대문자로만 사용한다. 정의문 내에서 소괄호는 규칙 이름의 사용 구별을 용이하게
해줄 경우에는 언제든지 사용한다.

"literal"
인용 부호로 문자 텍스트 주위를 감싼다. 별도의 언급이 없으면 문자는 대소문자를 구별한
다.

rule1 | rule2
막대 ("|")로 구분된 요소는 선택 사항이다. 예를 들어 "yes |no" 는 yes 나 no어느 것이든 가
능하다.

(rule1 rule2)
괄호로 둘러싼 요소는 단일 요소로 취급한다. 따라서 "(elem (foo | bar) elem)"는 
"elem foo elem" 및 "elem bar elem"의 토큰 순서를 허용한다.

*rule
이것은 반복을 의미하는 것으로서 뒤이어서 나올 #rule과 혼동을 일으키는 표현 방식이므
로 유의해야 한다. 반복을 통해 이루어지는 결과는 하나의 단어나 수와 같이 한 개 요소의
표현 형태로 되는 것이며, #rule에서는 똑같은 반복이지만 여러 개 단어나 수의 열 형태
와 같이 여러 개 요소의 나열 형태로 표현되는 것이다. *element와 같은 표기 방
법으로 쓰인다. 이것은 적어도 n개와 최대 m개의 요소로 구성되는 한 가지 결과를 의미한
다. 즉, 1*2DIGIT 라는 표현은 숫자가 적어도 한 개 최대 두 개로 구성되어 한 개의 수를
나타낸다는 뜻이다. 4는 한 가지 예이며, 45도 한 가지 예가 된다. 그러나 345의 경우
에는 숫자 세 개로 구성된 한 개 요소이므로 최대 갯수에 위배되어 적합하지 않다.
n과 m은 생략될 수 있으며, 이 경우에 n의 기본값은 0이고 m의 기본값은 무한대이다.
그러므로 "*(element)"는 0개를 포함해서 어떤 개수라도 가능하고, "1*element"의 경
우는 한 요소의 표현에 있어 적어도 한 개는 있어야 하며 최대 갯수에는 제한이 없다.

[rule]
대괄호는 선택 요소를 둘러 싼다. "[foo bar]" 는 "*1(foo bar)"와 동일하다.

N rule
특정 횟수의 반복을 나타낸다. "(element)" 은 "*(element)"와 동일하다.
즉 요소(element)가 정확하게 번 표시된다. 따라서 2 DIGIT 는 2 자리 숫자, 3 ALPHA
는 세 개의 알파벳 문자로 구성된 문자열이다.

#rule
앞서 설명한 것처럼 반복을 나타내긴 하지만 요소들의 나열로서 표현되는 것이다. 즉,
1#DIGIT 라고 하면 여러 개의 수로 구성된 수열로서 표현되는데, 최소 한 개의 수는 있어
야 하고 최대 갯수는 제한이 없는 수열이 된다. 각 요소들 사이의 구분은 ","와 LWS를 이
용하는데, 여러 개의 나열 형태를 쉽게 표현할 수 있게 해준다. 예를 들어, (*LWS
element *(*LWS "," *LWS element)) 이것을 간단하게 1#element 이와 같이 표현할
수 있다. 또 다른 예를 들자면, 1#2(2DIGIT)이것은 숫자 두 개로 구성된 수가 적어도 한
개가 있어야 하며 최대 두 개까지 가능하다는 것이다. 즉, 23 이렇게 표현될 수도 있고,
23, 56 이렇게 두 개로 표현될 수도 있다. 이것이 *rule과의 차이점이고, #rule 에서도
"#element" 의 구성이 그대로 성립한다. 이에 대한 설명은 *rule 의 경우와 같다. ","
를 이용하여 나열함에 있어, null element가 허용된다. 예를 들어, 1#3(2DIGIT)과 같
은 표현식에 대해23, , 56, 34 이렇게 null element 표시가 가능하지만, 실제 갯수는
세 개로서 간주된다. 따라서 최소 한 개 최대 세 개의 제한에 위배되지 않는다.

[Page 14]

; comment
규칙 문장에서 오른쪽으로 약간 떨어져 있는 세미콜론은 해당 라인의 끝에까지 계속되는 주
석의 시작을 의미한다. 이것은 규격과 병행하여 적절한 설명을 포함시키기 위한 방법이다.

implied *LWS
두 개의 인접한 단어 (token or quoted-string) 또는 인접한 토큰(tokens)과 식별자
(tspecials) 사이에 LWS (linear whitespace)가 포함될 수 있다. 여기서 두 개의 토큰 사이에
는 반드시 적어도 하나의 식별자가 존재하여 각기 하나의 토큰으로 간주되지 않게끔 구별되
어야 한다.

2.2 기본 규칙

다음의 규칙은 기본적인 분석 구조를 설명하기 위해 이 규격 전반에 걸쳐 사용되고 있다. US-
ASCII로 코드화 된 문자 집합은 ANSI X3.4-1986 [21]에 의하여 규정되었다.

 OCTET    = <모든 8-bit 연속 데이터>
 CHAR           = <모든 US-ASCII 문자 (octets 0 - 127)>
 UPALPHA       = <모든US-ASCII 대문자 "A".."Z">
 LOALPHA       = <모든 US-ASCII 소문자 "a".."z">
  ALPHA          = UPALPHA | LOALPHA
  DIGIT    = <모든 US-ASCII 숫자 "0".."9">
  CTL             = <모든 US-ASCII 제어 문자 (octets 0 - 31) 및 DEL (127)>
  CR              =
  LF             =
  SP              =  
  HT              =  
  <">             =  

[Page 15]

HTTP/1.1은 연속적인 CR LF를 Entity-Body를 (부록 19.3 참조) 제외한 모든 규약 요소의
라인 마감 부호로 정의한다. Entity-Body 내에서의 라인 마감 부호는 3.7 절에서 설명된 것
처럼 연관된 media type에 의하여 정의한다.

 CRLF =  CR LF

HTTP/1.1 헤더는 계속되는 라인이 스페이스나 수평 탭으로 시작한다면 복수의 라인에 걸쳐 계
속 작성할 수 있다. 폴딩(folding)을 포함한 모든 선형 공백 스페이스는 SP와 동일한 의미를
가진다.

  LWS            = [CRLF] 1*( SP | HT )

TEXT 규칙은 메시지 분석기가 해석하지 않도록 정의한 설명 필드 내용이나 값에 사용한다.
*TEXT의 단어는 RFC 1522 [14]의 규칙에 따라 인코딩되었을 경우에만 ISO 8859-1 [22] 이외 문
자세트의 문자를 포함할 수 있다.

 TEXT  = < CTLs을 제외한 (그러나 LWS는 포함) 모든 OCTET>

16 진수 숫자는 몇몇 규약 요소에서 사용할 수 있다.

 HEX = "A" | "B" | "C" | "D" | "E" | "F"
         | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

많은 HTTP/1.1 헤더 필드 값은 LWS나 특수 문자로 구별되는 단어로 구성되어 있다. 파라미
터 값 내에서 사용할 이러한 특별 문자는 반드시 인용 문자열 내에 있어야 한다.

 token = 1*

 tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\"
| <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT

주석은 주석문을 괄호로 둘러싸서 몇몇 HTTP 헤더 필드에 포함할 수 있다. 주석은
"comment"를 필드 값 정의의 한 부분으로 포함하는 필드에서만 사용할 수 있다. 다른 필드
에서 괄호는 필드 값의 일부로 간주된다.

 comment = "(" *( ctext | comment ) ")"
  ctext    = < "(" and ")"을 제외한 모든 TEXT >

[Page 16]

텍스트 문자열이 이중 인용 부호를 사용하여 인용되었으면 단일 단어로 간주한다.

 quoted-string    = ( <"> *(qdtext) <"> )

 qdtext          = <<">을 제외한 모든 TEXT>

백슬래시 문자("\")는 인용된 문자열이나 주석 내에서만 단일문자 인용 메커니즘으로서 사용할
수 있다.

 quoted-pair     = "\" CHAR

3 규약 파라미터

3.1 HTTP 버전

HTTP는 "<주요한 변경>.<사소한 변경>" 번호 체계를 규약의 버전을 표시할 때 사용한다. 규
약 버전 부여 정책은 발송자가 통신을 통하여 획득한 기능보다는 메시지의 형식 및 계속적인
HTTP 통신을 이해할 능력이 있음을 표시할 수 있도록 하기 위해 정의되었다. 단순히 확장할
수 있는 필드 값을 추가하거나 통신 방식에 영향을 미치지 않는 메시지 구성 요소를 추가했을
경우에는 버전 숫자에 변화가 없다. <사소한 변경> 숫자는 일반적인 메시지 분석 알고리즘에
대한 변화는 없지만 메시지 의미에 대한 추가 사항이나 발송자의 추가적인 능력을 의미하는
규약 추가 기능에 대한 변경이 있을 경우 증가된다. <주요한 변경> 숫자는 규약 내부의 메시
지 형식이 변경되었을 때 증가한다.

HTTP 메시지의 버전은 메시지 첫 라인의 HTTP-Version 필드에 표시된다.

 HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

주요 및 사소한 부분을 표시하는 숫자는 반드시 별도의 정수 값으로 구분되어야 하며 10 단위
이상으로 증가할 수 있음을 주의해야 한다. 따라서 HTTP/2.4 은  HTTP/2.13보다 이전 버전이
며 또한 HTTP/12.3보다 이전 버전이다. 수신측에서는 앞 부분에 나오는 0을 반드시 무시해야
하며 전송해서는 안 된다.

이 규격이 규정하는 대로 요구나 응답 메시지를 전송하는 애플리케이션은 반드시 HTTP-
Version을 "HTTP/1.1"로 설정해야 한다. 이 버전 번호를 사용하는 것은 발송하는 애플리케
이션이 최소한 부분적으로는 이 규격을 따르고 있음을 표시한다.

애플리케이션의 HTTP 버전은 해당 프로그램이 최소한의 조건으로 상호 동작을 지원할 수 있
는 최고 HTTP 버전 값이다.
 
[Page 17]

프락시 및 게이트웨이 프로그램의 규약 버전이 애플리케이션과 상이할 경우 메시지를 전달할
때 주의해야 한다. 규약 버전은 발송자의 규약 능력을 표시하기 때문에 프락시/게이트웨이는
실제 자신의 버전보다 높은 버전 표시를 사용하여 메시지를 발송해서는 절대로 안 된다. 상위
버전의 요구가 수신되었으면 프락시/게이트웨이는 반드시 요구 버전을 내리거나, 에러를 발송
하거나 터널로 전환해야만 한다. 프락시/게이트웨이 버전보다 낮은 요구는 상위 버전으로 업그
레이드 할 수는 있으나 요구 받은 버전의 주요 버전은 반드시 동일해야 한다.

주의: HTTP 버전 간의 변환은 관련된 버전이 요구하거나 금지한 헤더 필드의 변경을 수반할
수도 있다.

3.2 보편적 자원 식별자(Uniform Resource Identifier - URI)

URI는 WWW 주소, 보편적인 문서 식별자, 보편적 자원 식별자 또는 보편적 자원 위치 지정
자(URL)와 이름(URN)의 결합에 이르기까지 많은 이름으로 불리우고 있다. HTTP로서는 보편
적 자원 식별자란 이름, 위치 또는 다른 어떤 특징을 이용하여 자원을 식별해 주는 정형화 된
문자열일 뿐이다.

3.2.1 일반적 형식

HTTP 규약에서 URI는 사용되는 상황에 따라 절대적인 형태로 표현할 수도 있고 알려진 기본
URI의 상대적인 형태로 표현할 수도 있다. 이 두 형태는 절대적 URI는 항상 콜론이 뒤 따르
는 scheme으로 시작한다는 사실로 구분할 수 있다.

URI = ( absoluteURI | relativeURI ) [ "#" fragment ]

AbsoluteURI = scheme ":" *( uchar | reserved )

RelativeURI = net_path | abs_path | rel_path

net_path   = "//" net_loc [ abs_path ]
abs_path    = "/" rel_path
rel_path    = [ path ] [ ";" params ] [ "?" query ]

path      = fsegment *( "/" segment )
fsegment   = 1*pchar
segment   = *pchar

params  = param *( ";" param )
param  = *( pchar | "/" )

[Page 18]

scheme   = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc       = *( pchar | ";" | "?" )

query =  *( uchar | reserved )
fragment  =  *( uchar | reserved )

pchar =  uchar | ":" | "@" | "&" | "=" | "+"
uchar    =  unreserved | escape
unreserved   =  ALPHA | DIGIT | safe | extra | national

escape  =  "%" HEX HEX
reserved  =  ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra =  "!" | "*" | "'" | "(" | ")" | ","
safe    =  "$" | "-" | "_" | "."
unsafe =  CTL | SP | <"> | "#" | "%" | "<" | ">"
national =  < ALPHA, DIGIT, reserved, extra, safe
                   및unsafe을 제외한 모든 OCTET>

URL 형식과 의미 규정에 관한 정보는 RFC 1738 [4] 및 RFC 1808 [11]을 따르고 있다. 상기
BNF 는 RFC 1738에 명시되어 있는 유효한 URL의 형태에서 허용하지 않고 있는 국가 문자
를 포함하고 있다. 이는 HTTP 서버가 주소에서 rel_path 부분을 표시하는 데 사용할 수 있
는 예약되어 있지 않는 문자 집합에 제한을 받지 않고, HTTP 프락시가 RFC 1738에 규정되지
않은 URI 요구를 수신할 수도 있기 때문이다.

HTTP 규약은 URI의 길이에 대한 어떠한 사전 제한도 두지 않는다. 서버는 반드시 자신이 제
공하는 어떠한 자원의 URI도 처리할 수 있어야 하며 이러한 URI를 생성할 수 있는 GET에
기초한 폼을 (GET-based forms) 제공한다면 무제한 길이의 URI를 처리할 수 있어야만 한다. 서
버는 URI의 길이가 자신의 처리할 수 있는 (10.4.15 절 참조) 것보다 긴 경우 414 (Request-URI
Too Long)를 응답으로서 돌려주어야 한다.

주의: 서버는 255 바이트 이상의 URI 길이를 사용할 때 몇몇 이전 클라이언트나 프락시 구
현 방식이 이러한 길이를 적절히 지원할 수 없는 경우가 있기 때문에 주의해야 한다.

3.2.2 http URL

"http" scheme은 HTTP 규약을 통하여 네트워크 자원의 위치를 파악하는 데 사용한다. 이 절은
http URL에 사용되는 scheme 특유의 형식과 의미를 규정한다.

[Page 19]

http_URL   = "http:" "//" host [ ":" port ] [ abs_path ]

host = <합법적인 인터넷 호스트 도매인 이름 또는 RFC 1123의 2.1 절에서 정
의한 방식의 IP 주소(점으로 구분된 형식)>

port  = *DIGIT

포트 항목이 비어 있거나 명시되지 않았으면 포트는 80으로 간주한다. TCP 연결 요구를 기다
리고 있는 해당 호스트 서버의 해당 포트에 식별된 자원이 위치하고 있으며 자원의
Request-URI는 abs_path라는 것이 의미한다는 내용이다. URL의 IP 주소의 사용은 가능한
한 피해야만 한다 (RFC 1900 [24] 참조). URL에 abs_path가 명시되어 있지 않으면 자원(5.1.2
절)을 위한 Request-URI로서 사용할 때 반드시 "/"가 주어져야 한다.

3.2.3 URI 비교

URI가 서로 일치하는지 여부를 결정하기 위해 URI를 비교할 때 클라이언트는 전체URI에
대하여 대소문자를 구별하는 8진수 대 8진수 비교 방법(octet-by-octet comparison)을 사용해야
만 하며 다음의 예외 사항이 있다.

? 비어 있거나 명시되지 않은 포트는 기본 포트 80번으로 정의한다;
 
? 호스트 이름의 비교에는 반드시 대소문자를 구별하지 않는다;
 
? scheme 이름의 비교는 반드시 대소문자를 구별하지 않는다;
 
? 비어 있는 abs_path는 "/"인 abs_path와 동일하다.

"예약되거나(reserved)" "안전하지 않는(unsafe)" 문자 집합 (3.2 절 참조) 이외의 문자는  ""%"
HEX HEX" 인코딩과 동일하다.

예를 들어 다음의 세 URI는 동일하다.

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

[Page 20]

3.3 날짜/시간 형식

3.3.1 완전한 날짜

HTTP 프로그램은 역사적으로 세 가지 방법으로 시간/날짜를 표시해 왔다.

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, RFC 1123에서 갱신
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, RFC 1036에서 폐기
Sun Nov  6 08:49:37 1994       ; ANSI C의 asctime() 형식

첫번째의 형식이 인터넷 표준으로 우선권을 가지고 있으며 RFC 1123 (RFC 822의 개정판)에서
규정한 고정 길이의 하부 세트를 표시한다. 두 번째 형식은 일반적으로 사용되기는 하지만 폐
기된 RFC 850 [12] 날짜 형식에 기초하고 있으며 4 단위 년도 표시가 결여되어 있다. 날짜를
분석하는 HTTP/1.1 클라이언트 및 서버는 반드시 상기 세 형식을 모두 수용해야 한다. 그러나
헤더 필드의 HTTP-날짜 값을 표시할 때는 반드시 RFC 1123 형식만을 생산해야 한다.

주의 : 날짜 값 수신처는 메시지를 프락시/게이트웨이를 통하여 SMTP나 NNTP로 조회 또
는 발송하는 경우처럼 비 HTTP 애플리케이션이 발송한 날짜 값을 수신하는 데 적극적인 조
치를 취할 것을 장려한다.

모든 HTTP 날짜/시간 표시는 예외 없이 반드시 그린이치 표준 시간(GMT))을 따라야 한다. 이
는 처음 두 형식에서 시간대를 표시하는 3 문자의 축약어인 "GMT"를 포함함으로써 표시되어
있다. 또한 asctime 형식의 날짜를 읽을 때도 "GMT"라고 반드시 가정해야 한다.

HTTP-date      = rfc1123-date | rfc850-date | asctime-date

rfc1123-date   =  wkday "," SP date1 SP time SP "GMT"
rfc850-date    =  weekday "," SP date2 SP time SP "GMT"
asctime-date   =  wkday SP date3 SP time SP 4DIGIT

date1          =  2DIGIT SP month SP 4DIGIT
                           ; day month year (e.g., 02 Jun 1982)
date2          = 2DIGIT "-" month "-" 2DIGIT
                           ; day-month-year (e.g., 02-Jun-82)
date3          = month SP ( 2DIGIT | ( SP 1DIGIT ))
                           ; month day (e.g., Jun  2)
time           = 2DIGIT ":" 2DIGIT ":" 2DIGIT
                           ; 00:00:00 - 23:59:59

wkday         = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun"

[Page 21]

weekday       = "Monday" | "Tuesday" | "Wednesday" | "Thursday"
                | "Friday" | "Saturday" | "Sunday"

month         = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun"
                | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"

주의: 날짜/시간 표현에 대한 HTTP 필요 조건은 규약 스트림 내부에서 사용할 때만 적용된
다. 클라이언트와 서버는 사용자의 표시 방법, 요구 로깅 등에서는 이러한 형식을 반드시 사
용해야 할 필요는 없다.

3.3.2 Delta Seconds

몇몇 HTTP 헤더는 메시지가 수신된 이후의 시간을 10진법의 정수로 초를 명시할 수 있도록
한다.

delta-seconds  = 1*DIGIT

3.4 문자 집합

HTTP는 MIME에서 설명된 "문자 집합"이라는 용어를 동일하게 사용한다.

일련의 8bit 데이터를 적절한 대응 관계에 있는 일련의 글자로 변환시킬 수 있도록 한 개 또
는 그 이상의 표로서 만들어서 참조하게 하는 수단이다. 그러므로 무조건 변환시켜서는 안
되고, 모든 글자가 문자 집합에 정의되어 있지 않을 수 있고, 특정한 글자를 표현하기 위해
하나 이상의 8bit 데이터열이 존재할 수도 있다. 이 정의에 따르면, US-ASCII와 같은 단순한
변환표로부터 ISO 2022의 경우에서와 같이 복잡한 변환표에 이르기까지 다양한 종류의 문자
인코딩들을 허용한다. 하지만 MIME 문자 집합 이름과 관련된 정의는 8bit 데이터로부터 글
자로의 변환에 관한 사항을 완전하게 명시하여야 한다. 완전한 변환 관계를 정의하기 위해
다른 수단을 통한 외부 정보를 활용해서는 안 된다.

주의 : 이러한 "문자 집합"이라는 용어의 사용은 보통 "문자 인코딩"으로 지칭된다. 그러나
HTTP와 MIME은 동일한 등록표를 사용하기 때문에 용어를 공유하는 것 또한 중요하다.

[Page 22]

HTTP 문자 집합은 토큰에 의해 식별되며 대소문자를 구별하지 않는다. 완전한 토큰 세트는
IATA 문자 집합 등록표(IANA Character Set registry [19])에 규정되어 있다.

charset = token

HTTP가 charset 값으로 임의의 토큰을 사용하도록 허용하지만 IATA 문자 집합 등록에 사전
정의된 모든 토큰은 반드시 이 등록표에 등록된 문자 집합을 표시해야 한다. 애플리케이션은
사용하는 문자 집합을 IATA 등록 표에서 규정된 것으로 제한해야만 한다.

3.5 내용 코딩(Content Codings)

내용 코딩 값은 엔터티에 적용하였거나 적용할 수 있는 인코딩 변환을 표시한다. 내용 코딩은
문서를 압축하거나, 그렇지 않다면 내용의 media type의 정체를 상실하거나 정보를 손실하지
않고 유용하게 변형하는 데 사용한다. 종종 엔터티는 코드화 된 폼에 저장되고 직접 전송되어
수신측만이 이를 해독한다.

content-coding   = token

모든 내용 코딩의 값은 대소문자를 구별하지 않는다. HTTP/1.1은 Accept-Encoding (14.3 절)
및 Content-Encoding (14.12 절) 헤더 파일에 내용 코딩 값을 사용한다. 그 값이 Content-
Coding을 설명하는 것이지만 더욱 중요한 것은 인코딩을 제거하기 위해 필요한 해독 메커니
즘을 표시한다는 것이다.

인터넷에서 할당된 숫자 체계(Internet Assigned Numbers Authority (IANA))는 Content-Coding
값 토큰의 등록표 역할을 수행한다. 처음에 이 등록표에는 다음의 토큰이 포함되어 있다.

   gzip
RFC 1952 [25]에 설명된 대로 파일 압축 프로그램인 "gzip"에 의하여 생성된 인코딩 포
맷. 이 포맷은 32 bit CRC를 가진 Lempel-Ziv coding (LZ77)이다.

   compress
일반적인 UNIX 파일 압축 프로그램인 "compress"에 의하여 생성된 인코딩 포맷. 이
포맷은 Lempel-Ziv-Welch 코딩(LZW)을 수정한 것이다.

[Page 23]

주의: 인코딩 포맷을 식별하는 프로그램 이름의 사용은 바람직하지 않으며 향후 인코딩을
위해서 사용하지 말도록 권고한다. 프로그램 이름을 여기에서 사용한 것은 역사적인 관례이
며 훌륭한 디자인은 아니다. HTTP의 이전 구현법과 호환성을 유지하기 위해 애플리케이션
은 "x-gzip" 및 "x-compress" 을 "gzip" 과 "compress" 각각 동일한 것으로 간주해야
한다.

   deflate
RFC 1951[29]에 설명된 "deflate" 압축 메커니즘과 결합하여 RFC 1950[31]에 정의된 "zlib"
포맷.

새로운 Content-Coding 값 토큰은 등록해야 한다. 클라이언트와 서버가 상호 운용성을 가
지도록 하기 위해 새로운 값을 구현하는 데 필요한 내용 코딩 알고리즘에 대한 규격은 일반인
이 사용할 수 있어야 하고 독립적으로 구현하기에 적합해야 하며 이 절에 규정된 내용 코딩의
목적에 따라야 한다.

3.6 전송 코딩 (Transfer Codings)

전송 코딩 값은 네트워크를 통한 "안전 전송"을 확보하기 위해 Entity-Body에 적용하였거
나, 적용할 수 있거나 또는 적용할 필요가 있는 인코딩 변환을 표시하는 데 사용한다. 전송 코
딩은 메시지의 특성 중의 하나이며 원래 엔터티의 특성이 아니라는 점이 내용 코딩과 다른 점
이다.

transfer-coding         = "chunked" | transfer-extension

transfer-extension       = token

모든 transfer-coding 값은 대소문자를 구별하지 않는다. HTTP/1.1은 Transfer-
Encoding 헤더 필드 (14.40 절)의 전송 코딩 값을 사용한다.

전송 코딩은 7 비트 전송 서비스로 바이너리 데이터를 안전하게 전송할 수 있도록 디자인 된
MIME의 Content-Transfer-Encoding 값과 유사하다. 그러나 8 비트 전송 규약에서 안전
전송의 중점은 다른 곳에 있다. HTTP에서 유일한 Message-Body의 불안전한 특징은 정확한
본문 길이(7.2.2 절)를 결정하기 어렵다는 것과 공유하는 전송체계에서 데이터를 암호화하기
어렵다는 것이다.

덩어리 인코딩(chunked encoding)은 메시지를 일련의 덩어리로 전송하기 위하여 메시지 본문을
변경한다. 이 덩어리는 각각 자신의 크기 표시자를 가지고 있으며 Entity-Header 필드를 포
함하고 있는 선택적인 각주(footer)가 뒤따른다. 이를 통하여 역동적으로 생산된 내용물이 수신
인이 메시지 전체를 수신하였다는 것은 증명하는 데 필요한 정보와 함께 전송될 수 있도록 한
다.

[Page 24]

Chunked-Body     = *chunk
                         "0" CRLF
                         footer
                         CRLF

chunk              = chunk-size [ chunk-ext ] CRLF
                      chunk-data CRLF

hex-no-zero      = < "0"을 제외한 HEX >

chunk-size       = hex-no-zero *HEX
chunk-ext        = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
chunk-ext-name   = token
chunk-ext-val    = token | quoted-string
chunk-data       = chunk-size(OCTET)

footer            = *Entity-Header

덩어리 인코딩은 크기 0의 덩어리로 종결되며 빈 라인으로 종료되는 각주가 뒤따른다. 각주의
목적은 역동적으로 생성된 엔터티에 대한 정보를 효과적으로 제공하도록 하는 것이다. 애플리
케이션은 Content-MD5, 디지털 서명이나 다른 기능을 위한 HTTP 향후 확장으로 명백하게
규정되지 않은 헤더 필드를 결코 각주에 넣어서 전송해서는 안 된다.

Chunked-Body를 해독하는 예가 부록 19.4.6에 제시되어 있다.

모든 HTTP/1.1 애플리케이션은 반드시 덩어리 전송 코딩을 해독하고 수신할 수 있어야 하며
해독할 수 없는 전송 코딩 확장은 반드시 무시해야 한다. 해독할 수 없는 Transfer-Coding
과 함께 Entity-Body를 수신하는 서버는 501 (Unimplemented)을 응답으로 돌려주고 연결을
종료해야 한다. 서버는 결코 Transfer-Coding을 HTTP/1.0 클라이언트에 보내서는 안 된다.

3.7 미디어 형식(Media type)

HTTP는 공개적이고 확장 가능한 데이터 유형 설정 및 유형 협상 기능을 제공하기 위해
Content-Type (14.18 절) 및 Accept (14.1 절) 헤더 필드의 인터넷 미디어 형식을 사용한다.

media-type  = type "/" subtype *( ";" parameter )
type             = token
subtype       = token

attribute/value(속성/값) 쌍 형태의 파라미터가 type/subtype 유형을 뒤따른다.
 
[Page 25]

parameter   = attribute "=" value
attribute    = token
value     = token | quoted-string

유형, 하부 유형 및 파라미터 속성 이름은 모두 대소문자를 구분하지 않는다. 파라미터 값은
파라미터 이름의 의미에 따라 대소 문자를 구별할 수도 있고 않을 수도 있다. 선형 공백 스페
이스(LWS)는 유형과 하부 유형, 속성과 속성 값 사이에 절대 사용해서는 안 된다. 미디어 형
식을 인지하는 사용자 에이전트는 반드시 해당 MIME 유형의 파라미터를 해당
type/subtype 정의가 설정한 방식으로 처리해야 한다. (또는 사용자 에이전트가 해당
type/subtype을 처리하는 데 사용하는 외부 애플리케이션이 처리하도록 주선해야 한다.) 또
한 발견된 모든 문제를 사용자에게 알려 주어야 한다.

주의 : 이전 HTTP 애플리케이션은 미디어 형식 파라미터를 인지하지 못한다. 이전 HTTP 애
플리케이션으로 데이터를 전송할 때 구현 방식은 해당 type/subtype 정의가 요구할 때만
미디어 형식 파라미터를 사용해야 한다.

미디어 유형 값은 인터넷 할당 숫자 체계(IANA)에 등록된다. 미디어 유형을 등록하는 절차는
RFC 2048 [17]에 윤곽이 설명되어 있다. 등록되지 않은 미디어 유형을 사용하는 것은 권하지
않는다.

3.7.1 정형화(Canonicalization) 및 텍스트 기본값

인터넷에서의 미디어 형식은 정형화된 형식으로서 등록되어 있다. 보통 HTTP 메시지를 통하
여 전송되는 Entity-Body는 반드시 전송되기 이전에 적절한 정형화된 형식으로 표시되어야
한다. 이의 예외는 다음 문구에서 정의된 "text" 유형이다.

정형화된 형식으로서 text 형식의 미디어 subtype은 CRLF를 텍스트 라인 줄 바꿈으로 사
용한다. HTTP는 이러한 필요 조건을 완화하여 Entity-Body 전반에 걸쳐 일관성 있게 동일
한 방법을 사용하였을 경우 단순히 CR 또는 LF 하나를 줄 바꿈으로 표현하는 텍스트 미디어
전송을 허용한다. HTTP 애플리케이션은 CRLF, 단편적인CR 또는 LF를 HTTP를 통하여 수신
한 텍스트 미디어에서 줄 바꿈을 표시하는 것으로 인정해야만 한다. 또한 텍스트가 몇몇 멀티
바이트 문자 집합의 경우처럼 8진수 13과 10을 CR 과 LF로 사용하지 않는 문자 집합을 사
용하고 있을 경우 HTTP는 어떠한 일련의 octets가 해당 문자 집합에서 줄바꿈을 위한 CR 및
LF를 대표하는 것으로 규정하든 이를 허용한다. 이러한 줄바꿈에 대한 유연성은 Entity-
Body의 텍스트 미디어에만 적용되며 단편적인 CR 또는 LF는 어떠한 HTTP 제어 구조(헤더
필드 및 multipart 경계와 같은)에서도 CRLF를 대체해서는 안 된다.

Entity-Body가 Content-Encoding으로 인코딩 되었다면 내부 데이터는 인코딩 되기 이
전에 위에서 규정한 형식으로 표현되어 있어야 한다.
 
[Page 26]

"charset" 파라미터는 몇몇 미디어 형식에서 데이터의 문자 집합(3.4 절)을 규정하는 데 사용
한다. 송신자가 명백한 charset 파라미터를 제공하지 않았다면 "text" 유형의 미디어
subtype 형식은 HTTP를 통하여 수신했을 때 "ISO-8859-1"의 charset 기본값을 갖도록
규정되어 있다. "ISO-8859-1" 이외 문자 집합의 데이터나 그 하부 세트는 적절한 charset
값으로 명명되어야 한다.

몇몇 HTTP/1.0 소프트웨어는 charset 파라미터 없는Content-Type 헤더를 "수신측이 짐작
해야 한다"라고 잘못 해석하였다. 이러한 방식을 방지하고자 하는 송신자는 charset가 ISO-
8859-1일 때도 charset 파라미터를 포함할 수 있다. 또한 수신측에게 혼선을 주지 않는다
는 것을 알 수 있을 때도 그렇게 해야 한다.

불행하게도 몇몇 이전 HTTP/1.0 클라이언트는 명확한 charset 파라미터를 적절히 처리하지
못했다. HTTP/1.1 수신측은 송신측이 제공하는 charset 라벨을 반드시 감안해야 한다. 또한
charset을 추측하는 조항을 가진 사용자 에이전트는 Content-Type 필드의 charset를
지원한다면 처음 문서의 내용을 표시할 때 수신측의 선호도에 따르기보다는 반드시 이
charset를 사용해야 한다.

3.7.2 Multipart Type

MIME은 많은 "multipart" 형식을 제공하고 있는데 ? 하나 또는 그 이상의 엔터티를 단일
메시지 본문 내에 포함시킬 수 있도록 하는 것이다. 모든 multipart 형식은 MIME [7]에 규
정되어 있는 공통적 표기법에 따르며 미디어 형식 표시값의 일부로서 경계 파라미터를 포함해
야 한다. 메시지 본문 자체는 규약의 한 요소이며, Body-Part 간의 줄 바꿈을 표시할 때 반드시
CRLF만을 사용해야 한다. MIME과는 달리 모든 multipart 메시지의 맺음말은 반드시 비어
있어야 한다. HTTP 애플리케이션은 맺음말을 절대로 전송해서는 안 된다 (비록 원래의
multipart가 맺음말을 포함하고 있다 하여도).

HTTP에서 multipart의 Body-Part는 해당 부분의 의미에 중대한 영향을 끼치는 헤더필드를
포함할 수 있다. Content-Location 헤더 필드(14.15 절)는 URL로 확인할 수 있는 엔터티의
Body-Part에 포함되어야 한다.

일반적으로 HTTP 사용자 에이전트는 MIME 사용자 에이전트가 multipart 유형을 수신했을
때 처리하는 방식과 동일하거나 유사한 방식에 따라야 한다.

주의: RFC 1867 [15]에서 설명된 것처럼 "multipart/form-data" 유형이 POST 요구
method으로 처리하기에 적합한 폼 데이터를 전송하기 위해 특별히 규정되었다.

[Page 27]

3.8 제품 토큰

제품 토큰은 통신 애플리케이션이 자신의 소프트웨어 이름 및 버전을 확인하는 데 사용한다.
제품 토큰을 사용하는 대부분의 필드는 공백 문자로 구분되는 목록에 열거할 애플리케이션의
중요한 부분을 형성하는 부수적 제품명의 표시를 허용한다. 관례상 제품은 애플리케이션을 식
별해 주는 제품의 중요도에 따라 열거된다.

product           = token ["/" product-version]
product-version  = token

   예:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4

제품 토큰은 간략해야 하며 요점이 있어야 한다. 광고나 필수적이지 않은 다른 정보를 위해
사용하는 것은 분명하게 금지되어 있다. 어떠한 토큰 문자라도 제품 정보에 표시할 수 있지만
이 토큰은 버전 식별자에만 사용해야 한다.(동일한 제품의 계속적인 버전은 제품 값(value)의
product-version 부분만 달라야 한다.)

3.9 품질 등급 값

HTTP 내용 협상(12 장)은 짤막한 "부동소수점" 숫자를 사용하여 다양한 협상 가능 파라미터
의 상대적 중요성("가중치")을 표시한다. 가중치는 최소값 0부터 최대값 1까지 범위의 실수로
정형화할 수 있다. HTTP/1.1 애플리케이션은 부동소수점 이후의 자리에 세 자리 이상의 숫자를
절대 사용해서는 안 된다. 이러한 값들에 대한 사용자의 값 설정은 또한 다음의 방식으로 한
정되어야 한다.

qvalue         = ( "0" [ "." 0*3DIGIT ] )
               | ( "1" [ "." 0*3("0") ] )

"품질등급 값"은 이 값이 단순히 원하는 품질에 대한 상대적인 질 저하를 표현하는 것이기 때
문에 잘못된 명칭이다.

3.10 언어 태그

언어 태그는 인간이 다른 인간과 정보를 교환하기 위하여 말하거나, 쓰거나 혹은 전달하는 자
연적인 언어를 표시한다. 컴퓨터 언어는 분명히 제외된다. HTTP는 Accept-Language 및
Content-Language 필드를 이용하여 언어 태그를 표시한다.

[Page 28]

HTTP 언어 태그의 의미 및 등록표는 RFC 1766 [1]에서 규정한 것과 동일한 것을 사용한다. 요
약하면 언어 태그는 하나 또는 그 이상의 부분으로 구성되어 있다. 주요 언어 태그 및 비어
있을 수도 있는 일련의 하부 태그는 다음과 같다.

language-tag   = primary-tag *( "-" subtag )

primary-tag     = 1*8ALPHA
subtag           = 1*8ALPHA

태그 내에서는 공백 문자를 사용할 수 없고 모든 태그는 대소문자를 구별하지 않는다. 언어
태그의 이름 영역은 IANA에서 관리한다. 태그 예제는:

en, en-US, en-cockney, i-cherokee, x-pig-latin

여기서 두 자리 문자로 되어 있는 제일 앞 태그는 ISO 639 언어 축약어 형태이며, 두 자리 문
자로 되어 있는 첫 하부 태그는 ISO 3166 국가 코드이다.(위에서 마지막 세 가지 태그는 등록
되지 않은 태그이다. 마지막 태그만 향후 등록될 수 있다.)

3.11 엔터티 태그

엔터티 태그는 동일하게 요구된 자원에서 둘 또는 그 이상의 엔터티를 비교하는 데 사용한다.
HTTP/1.1 은 엔터티 태그를 ETag (14.20 절), If-Match (14.25 절), If-None-Match (14.26 절)
및 If-Range (14.27 절) 헤더 필드에서 사용한다. 사용 방법 및 캐시 검증자와의 비교에 관한
정의는 13.3.3 절에 있다. 엔터티 태그는 명쾌하지 않은 인용 문자열로 (an opaque quoted string)
구성되어 있으며 약함(weakness) 표시자가 접두사로 붙을 수 있다.

entity-tag    = [ weak ] opaque-tag

weak          = "W/"
opaque-tag    = quoted-string

"강한 엔터티 태그(strong entity tag)"는 8진수의 질이 (octet equality) 동일할 경우에만 두 엔터티
가 자원을 공유할 수 있다.

"W/" 접두사로 표시되는 "약한 엔터티 태그(weak entity tag)"는 엔터티가 동일하고 의미상 심각
한 변화 없이도 서로 대체할 수 있을 경우에만 두 엔터티가 자원을 공유할 수 있다. 약한 엔
터티 태그는 약한 비교에만 사용할 수 있다.

엔터티 태그는 반드시 특정 자원과 연관된 모든 엔터티의 모든 버전을 통틀어 유일해야 한다.
특정 엔터티 태그값을 상이한 URI에 대한 요구로부터 획득한 엔터티에 동일하다는 아무런 표
시 없이 사용할 수 있다.

[Page 29]

3.12영역 단위

HTTP/1.1 는 클라이언트가 엔터티의 일부분(특정 영역)만 응답으로 전송해 달라고 요구할 수
있다. HTTP/1.1은 Range (14.36 절) 및 Content-Range (14.17 절) 헤더 필드의 영역 단위를
사용한다. 엔터티는 여러 가지 구조적 단위 크기에 따라 여러 하부 영역으로 분리할 수 있다.

range-unit        = bytes-unit | other-range-unit

bytes-unit        = "bytes"
other-range-unit   = token

HTTP/1.1에서 정의한 유일한 영역 단위는 "바이트(bytes)"이다. HTTP/1.1의 구현 방식은 다른
단위를 사용하여 명시한 영역을 무시할 수 있다. HTTP/1.1은 영역에 대한 인식 여부에 상관없
이 애플리케이션의 구현을 허용하고 있다.

4 HTTP 메시지

4.1 메시지 유형

HTTP 메시지는 클라이언트로부터 서버로의 요구 및 서버로부터 클라이언트로의 응답으로 구
성되어 있다.

HTTP-message   = Request | Response     ; HTTP/1.1 messages

요구(5 장) 및 응답(6 장) 메시지는 엔터티를 전송(message payload)하기 위해 RFC 822 [9]의 일
반적 메시지 형식을 사용한다. 두 메시지 형식 모두는 시작 라인, 하나 또는 그 이상의 헤더
필드("헤더"라고도 알려졌다.), 헤더 필드의 끝을 표시하는 빈 라인(예를 들어 CRLF 이전에 아
무 것도 없는 라인) 및 선택 사항인 Message-Body으로 구성되어 있다.

generic-message  = start-line
                         *message-header
                         CRLF
                         [ message-body ]

start-line        = Request-Line | Status-Line

안정적인 동작(robustness)을 위해 서버는 Request-Line이 있어야 할 곳에 빈 라인을 수신하
면 이를 무시해야 한다. 다른 말로 표현 한다면, 만약 서버가 규약 스트림을 읽는 도중 메시지
처음에 CRLF를 수신하게 되면 이를 무시해야 한다.

[Page 30]

주의: HTTP/1.0 클라이언트로서 잘못 구현한 방법은 POST 요구 후 추가적인 CRLF를 생성한
다는 것이다. BNF가 분명하게 금지하고 있는 것을 다시 언급한다면 HTTP/1.1 클라이언트는
여분의 CRLF로 요구를 시작하거나 따라서는 안 된다.

4.2 메시지 헤더

Request-Header(5.3 절), Response-Header(6.2 절) 및 Entity-Header(7.1 절) 필드를 포
함하는 HTTP 헤더 필드는 RFC 822 [9] 3.1 절에서 규정한 일반적 형식을 동일하게 따르고 있
다. 각각의 헤더 필드는 콜론 (":") 및 필드값이 뒤 따르는 이름으로 구성되어 있다. 필드 이
름은 대소문자를 구분하지 않는다. 필드 값은 단일 SP가 우선적이지만 무한정한 LWS가 선행
될 수 있다. 헤더 필드는 최소한 하나의 SP 및 HT가 선행되는 여분의 라인이 선행되는 복수
의 행에 걸쳐 확장될 수 있다. 애플리케이션은 공통적인 구성 형태를 벗어난 것을 처리하지
못 하는 구현 결과도 있을 수 있기 때문에 HTTP 구조를 생성할 때 "일반적인 형식"을 따라야
한다.

message-header  = field-name ":" [ field-value ] CRLF

field-name      = token
field-value     = *( field-content | LWS )

field-content   = <필드 값을 구성하는 OCTET 이며 *TEXT 또는 토큰, tspecials,
                      인용 스트링의 결합으로 구성된다.>

다른 필드 이름으로 수신된 헤더 필드의 정렬 순서는 중요하지 않다. 그러나 General-
Header 필드를 맨 처음 나오고 Request-Header이나 Response-Header 필드가 뒤를 따
르고 마지막에 Entity-Header 필드가 나오는 것이 "바람직한 관행" 이다.

동일한 필드 이름을 가진 복수의 Message-Header 필드가 해당되는 헤더 필드의 전체
field-value가 콤마로 구분된 목록[예를 들면 #(values)]으로 규정되어 있을 경우에만 메
시지에 존재할 수 있다. 복수의 헤더 필드를 뒤 따르는 field-value를 처음에 추가하여(각
각의 값은 콤마로 구분된다) 메시지의 의미를 변화 시키지 않고 단일 "field-name: field-
value" 쌍으로 결합할 수 있어서는 안 된다. 따라서 동일한 field-name의 헤더 필드를 수
신하는 순서는 결합된 필드 값을 해석하는 데 중요하게 된다. 그러므로 프락시는 메시지를 전
송할 때 이러한 필드 값의 순서를 절대 변경해서는 안 된다.

[Page 31]

4.3 메시지 본문

HTTP 메시지의 Message-Body는 (만약 있다면) 요구 또는 응답과 관련된 Entity-Body를
전송하는 데 사용한다. Message-Body는 Transfer-Encoding 헤더 필드(14.40 절)에 설명
된 전송 코딩이 적용되었을 때에만 Entity-Body와 다르다.

message-body  = Entity-Body
                |

안전하고도 적절한 메시지 전송을 가능하게 하기 위해 애플리케이션이 적용한 전송 코딩 방식
을 표시하기 위해 반드시 Transfer-Encoding을 사용해야 한다. Transfer-Encoding은
메시지의 특성이지 엔터티의 특성이 아니기 때문에 요구/응답에 따라서 애플리케이션이 추가
또는 삭제할 수 있다.

Message-Body를 언제 메시지에서 사용할 수 있는가에 대한 규칙은 요구와 응답에 대해 각
각 다르다.

요구 메시지에 있어 Message-Body의 존재는 요구 Message-Header에 Content-Length
또는 Transfer-Encoding 헤더 필드를 포함함으로써 표시할 수 있다. Message-Body는 요
구 method(5.1.1 절)가 Entity-Body를 허용할 때만 요구 메시지에 포함할 수도 있다.

응답 메시지의 경우 Message-Body가 메시지에 포함되어 있는가의 여부는 요구 method 및
응답상태 코드(6.1.1 절) 모두에 달려 있다. HEAD 요구 method에 대한 모든 응답은 Entity-
Header 필드가 포함한 것처럼 믿게 하여도 Message-Body를 포함해서는 절대 안 된다. 모
든 1xx (Informational), 204 (No Content) 및 304 (Not Modified) 응답은
Message-Body를 절대 포함해서는 안 된다. 다른 모든 응답은 비록 길이가 제로라 할지라도
Message-Body를 포함한다.

4.4 메시지 길이

Message-Body가 메시지에 포함되어 있을 때 그 본문의 길이는 다음 중의 하나에 의해 결정
된다.(우선 순위에 따라)

1.  Message-Body를 절대 포함해서는 안 되는 모든 응답 메시지는 (1xx, 204 및 304 응답
메시지와 HEAD 요구에 대한 모든 응답) Entity-Header 필드의 존재 유무에 관계없이
헤더 필드 다음의 첫 빈 라인으로 항상 종료된다.
2.  Transfer-Encoding 헤더 필드가 (14.40 절) 존재하고 "chunked" 전송 코딩이 적용되
었음을 표시하고 있으면 길이는 chunked 인코딩에 (3.6 절) 의해 규정된다.

[Page 32]

3.  Content-Length 헤더 필드가 (14.14 절) 존재하고 그 바이트 단위의 값이 Message-
Body의 길이를 표시한다.
4.  메시지가 자신 스스로의 경계 설정 요소로서 미디어 형식 "multipart/byteranges"를
사용하고 있다면 바로 이것이 길이를 규정한다. 이 미디어 형식은 송신자가 수신측이 그
것을 분석할 수 있다는 것을 알 수 없을 때에는 절대 사용해서는 안 된다. 어떤 요구 메
시지가 복수의 Byte-Range 명시자를 가진 Range 헤더를 갖고 있으면 클라이언트가
multipart/byteranges 응답을 분석할 수 있음을 의미한다.
5.  연결을 단절하는 서버에 의하여. (연결 단절은 서버가 응답을 되돌려 줄 가능성을 전혀
남겨 두지 않기 때문에 응답 본문의 종료를 표시하는 데 사용해서는 안 된다.)

HTTP/1.0 애플리케이션과의 호환성 유지를 위해 Message-Body를 가지고 있는 HTTP/1.1 요
구는 서버가 HTTP/1.1을 따른다는 것을 알기 전에는 반드시 유효한 Content-Length 헤더
필드를 포함해야 한다. 요구가 Message-Body를 포함하고 있고 Content-Length가 주어지
지 않았으면 서버는 메시지의 길이를 결정할 수 없을 때는 400(Bad Request)을 응답으로
보내고, 계속하여 유효한 Content-Length 수신을 기다리고자 할 때는 411(Length
Required) 메시지를 반송하여야 한다.

엔터티를 수신하는 모든 HTTP/1.1 애플리케이션은 반드시 "chunked" 전송 코딩(3.6 절)을 허
용해야만 한다. 이렇게 함으로서 메시지의 길이를 미리 결정할 수 없을 때 이 메커니즘이 사
용될 수 있도록 한다.

메시지는 Content-Length 헤더 필드 및 "chunked" 전송 코딩을 모두 포함해서는 안 된다.
만약 둘 다를 수신하였으면 Content-Length는 반드시 무시해야 한다.

Message-Body가 허용된 메시지에 Content-Length가 주어졌을 때 그 필드 값은 반드시
Message-Body의 OCTET 숫자와 정확하게 일치해야 한다. HTTP/1.1 사용자 에이전트는 유효
하지 않은 길이를 수신했거나 탐지했을 때 반드시 사용자에게 이를 알려야 한다.

[Page 33]

4.5 일반 헤더 필드

요구와 응답 메시지 모두에 일반적으로 적용할 수 있지만 전송되는 엔터티에는 적용되지 않는
헤더 필드가 몇 가지 있다. 이러한 헤더 필드는 전송되는 메시지에만 적용된다.

general-header  = Cache-Control              ; 14.9 절
                   | Connection                ; 14.10 절
                   | Date                      ; 14.19 절
                   | Pragma                    ; 14.32 절
                   | Transfer-Encoding         ; 14.40 절
                   | Upgrade                  ; 14.41 절
                   | Via                       ; 14.44 절

General-Header 필드 이름을 추가하고자 한다면 HTTP 규약 버전이 변경되어야 한다. 그러
나 통신에 참여하는 모든 대상이 새로운 또는 실험적인 헤더 필드를 General-Header 필드
로 인지한다면 이들 헤더 필드를 일반 헤더의 의미로 적용할 수 있다. 인식되지 않은 헤더 필
드는 Entity-Header 필드로 처리된다.

5 요구(Request)

클라이언트로부터 서버로의 요구 메시지는 해당 메시지의 첫 라인 내에 자원, 자원의 식별자
및 사용 중인 규약 버전에 적용할 method를 포함한다.

Request          = Request-Line               ; 5.1 절
                     *( general-header          ; 4.5 절
                     | request-header           ; 5.3 절
                     | Entity-Header )          ; 7.1 절
                     CRLF
      [ message-body ]            ; 7.2 절

5.1 Request-Line

Request-Line은 method 토큰으로 시작하며 Request-URI 및 규약 버전이 뒤 따르며 CRLF
로 종결된다. 각 요소는 SP 문자로 구분된다. CR 또는 LF는 마지막 CRLF 순서 이외에는 허용
되지 않는다.

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

[Page 34]

5.1.1 Method

Method 토큰은 Request-URI로 식별되는 자원에서 수행할 method를 표시한다. method는 대
소문자를 구별한다.

Method         = "OPTIONS"               ; 9.2 절
                | "GET"                    ; 9.3 절
                | "HEAD"                  ; 9.4 절
                | "POST"                   ; 9.5 절
                | "PUT"                    ; 9.6 절
                | "DELETE"                ; 9.7 절
                | "TRACE"                 ; 9.8 절
                | extension-method

extension-method = token

자원이 허용하는 method의 목록은 Allow 헤더 필드(14.7 절)에 명시할 수 있다. 응답의 리턴
코드는 허용된 method 세트가 역동적으로 변할 수 있기 때문에 항상 method가 현재 자원에서
허용되는지 여부를 클라이언트에게 알려 준다. 서버는 서버가 method를 알고는 있으나 요구된
자원에서는 사용할 수 없을 때 상태 코드 405(Method Not Allowed)를, 서버가 method를
인지하지 못하거나 구현하지 않았을 때는 상태 코드 501(Not Implemented)을 리턴해야만
한다. 서버가 알고 있는 method의 목록은 Public Response-Header 필드(14.35 절)에 나열
할 수 있다.

GET 및 HEAD method는 모든 일반적인 목적의 서버가 반드시 지원해야 한다. 다른 모든
method는 선택적이다. 하지만 GET 및 HEAD method가 구현되었으면 반드시 9 장에 명시된 의
미와 동일하게 구현되어야 한다.

5.1.2 Request-URI(Request-URI)

Request-URI 는 보편적인 자원 식별자(3.2 절)이며 요구를 적용할 자원을 식별한다.

Request-URI    = "*" | absoluteURI | abs_path

Request-URI의 세 가지 선택 사항은 요구의 성격에 달려 있다. 별표 "*"는 요구를 특별한
자원에 적용하지 않고 서버 자체에 적용한다는 것을 의미하며 사용된 method가 반드시 자원
에 적용되는 것은 아닐 때 사용할 수 있다. 한 예를 보면;

OPTIONS * HTTP/1.1

 [Page 35]

프락시에게 요구를 만들 때는 absoluteURI 형식이 필요하다. 프락시는 유효한 캐시로부터
요구를 전송하거나 처리하여 응답을 되돌려 주어야 한다. 프락시는 absoluteURI에 명시된
대로 요구를 다른 프락시로 전송하거나 서버로 직접 전송할 수 있다는 점을 주목해야 한다.
요구가 무한 루프를 도는 것을 방지하기 위하여 프락시는 반드시 모든 별명(aliases), 지역적
변이 및 IP 주소 숫자를 포함한 모든 서버 이름을 인지할 수 있어야 한다. Request-Line의
예는 다음과 같다.

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

향후 버전 HTTP에서 모든 요구가 absoluteURI로 이전될 수 있도록 하기 위해 모든
HTTP/1.1 서버는 비록 HTTP/1.1 클라이언트가 단지 프락시에 대한 요구에서만 그것을 생산한
다 할지라도 반드시 요구의 absoluteURI 형식을 수용해야 한다.

가장 일반적인 형태의 Request-URI는 원서버나 게이트웨이의 자원을 식별하는 데 사용한다.
이 경우URI의 절대적 경로는 반드시 Request-URI처럼 전송(3.2.1절의 abs_path 참조)되
어야 하며 URI의 네트워크 위치는 반드시 Host 헤더 필드를 이용하여 전송되어야 한다. 예
를 들어 원서버에서 직접 자원을 조회하고자 하는 클라이언트는 "www.w3.org" 호스트의 포
트 80으로 TCP 접속을 한 다음 아래의 라인을 전송할 것이다.

GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org

위 내용 다음에 요구 메시지의 나머지 부분이 뒤따른다. 절대 경로는 절대 비어서는 안 된다.
원래 URI의 절대 경로가 비어있을 때에는 반드시 "/" (서버의 루트 디렉토리)를 추가한다.

프락시가 Request-URI에 아무런 경로가 없는 요구를 수신하고 명시된 method가 별표 모양
의 요구를 지원할 수 있으면 응답 메시지의 전달 경로 상의 (Request chain) 마지막 프락시는
반드시 요구 메시지에 마지막 Request-URI로서 "*"를 첨부하여 전송해야 한다. 예를 들어
다음과 같은 요구 메시지를

OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1

프락시는 "www.ics.uci.edu".호스트의 포트 8001과 연결한 다음 아래와 같이 전송할 것이
다.

OPTIONS * HTTP/1.1
Host: www.ics.uci.edu:8001

Request-URI 는 3.2.1 절에서 명시한 형식으로 전송된다. 원서버는 요구를 적절히 해석하기
위하여 반드시 Request-URI를 해독해야 한다. 서버는 유효하지 않는  Request-URI를 수
신하면 적합한 상태 코드로 응답해야 한다.

[Page 36]

요구 메시지를 전송할 때 프락시는 어떤 방식으로든 위에서 설명한 것처럼 비어 있는 절대 경
로를 "*"로 대체하는 것 외에는 프락시 내부의 구현 방법에 관계없이 절대로 Request-URI
의 "abs_path" 부분을 재작성해서는 안 된다.

주의 : "재작성 금지" 규칙은 원서버가 특정 목적을 위해서 예약되지 않은 URL 문자를 적절
하게 사용하지 못하고 있을 때 요구의 의미를 변경하지 못하도록 한다. 구현자는 몇몇
HTTP/1.1 이전의 프락시는 Request-URI를 재작성하는 것으로 알려져 있음을 인식하고 있
어야만 한다.

5.2 요구에 의해 식별되는 자원

HTTP/1.1 원서버는 인터넷 요구가 식별하는 정확한 자원은 Request-URI 및 Host 헤더 필드
모두를 조사하여 결정된다는 것을 인지하고 있어야 한다.

요구받은 호스트와 다른 자원을 허용하지 않는 원서버는 Host 헤더 필드 값을 무시할 수 있
다. (그러나 HTTP/1.1에서의 Host 지원에 관한 다른 필요 조건에 관하여는 19.5.1절을 참조한
다.)

요구받은 호스트에 기초하여 자원을 구별하는 원서버(때로 가상 호스트 또는 허영 호스트 이
름이라고 불린다)는 HTTP/1.1 요구에 대한 자원을 결정할 때 다음의 규칙을 반드시 따라야 한
다.

1.  Request-URI 가 absoluteURI이면 호스트는 Request-URI의 일부분이다. 요구의
어떠한 Host 헤더 필드 값도 반드시 무시해야 한다.
2.  Request-URI 가 absoluteURI가 아니면 요구는 Host 헤더 필드를 포함한다. 호스
트는 Host 헤더 필드 값으로 결정된다.
3.  규칙 1, 2에 의하여 지정된 호스트가 서버의 유효한 호스트가 아니면 응답은 반드시
400(Bad Request) 에러 메시지이어야 한다.

Host 헤더 필드가 없는 HTTP/1.0의 수신측은 정확하게 무슨 자원을 요구했는지 결정하기 위
해 발견법을 (heuristics - 예를 들어 유일한 무엇인가의 특별한 호스트로의 URI 경로를 검사)
사용할 수도 있다.

5.3 요구 헤더 필드

요구 헤더 필드는 요구 및 클라이언트 자신에 관한 추가 정보를 클라이언트가 서버에게 전달
할 수 있도록 한다. 이 필드는 프로그래밍 언어 method 호출시 사용하는 파라미터와 동일한
의미로 요구 변경자(request modifiers)의 역할을 수행한다.

[Page 37]

request-header  = Accept                     ; 14.1 절
                   | Accept-Charset             ; 14.2 절
                   | Accept-Encoding            ; 14.3 절
                   | Accept-Language            ; 14.4 절
                   | Authorization               ; 14.8 절
                   | From                       ; 14.22 절
                   | Host                       ; 14.23 절
                   | If-Modified-Since          ; 14.24 절
                   | If-Match                   ; 14.25 절
                   | If-None-Match              ; 14.26 절
                   | If-Range                   ; 14.27 절
                   | If-Unmodified-Since        ; 14.28 절
                   | Max-Forwards              ; 14.31 절
                   | Proxy-Authorization        ; 14.34 절
                   | Range                      ; 14.36 절
                   | Referer                    ; 14.37 절
                   | User-Agent                 ; 14.42 절

Request-Header 필드 이름은 규약 버전의 변경과 함께 확장했을 때만 신뢰성 있게 확장될
수 있다. 그러나 통신에 참여하는 모든 대상이 그것을 Request-Header 필드로 인지한다면
새롭거나 실험적인 헤더 필드에 요구 헤더의 의미를 적용할 수 있다. 인정되지 않은 헤더 필
드는 Entity-Header 필드로 처리된다.

6 응답

요구 메시지를 수신하고 해석한 후 서버는 HTTP 응답 메시지로 응답한다.

Response      = Status-Line                  ; 6.1 절
                *( general-header            ; 4.5 절
                | response-header            ; 6.2 절
                | Entity-Header )             ; 7.1 절
                CRLF
   [ message-body ]             ; 7.2 절

6.1 상태 라인(Status-Line)

응답 메시지의 첫 라인은 상태 라인이다. 상태 라인은 규약 버전과 이에 뒤따르는 숫자 상태
코드 및 연관된 텍스트 문구로 구성되어 있으며 각 요소는 SP 문자로 구분된다. CR 또는 LF
는 마지막 CRLF에만 허용된다.

[Page 38]

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 상태 코드 및 이유 문구

Status-Code(상태 코드) 요소는 요구 메시지를 이해하고 이에 따라 서비스를 제공하려는 데
에 대한 결과로서 세 자리의 정수 코드이다. 이 코드는 10장에 모두 정의되어 있다. Reason-
Phrase(이유 문구)는 상태 코드에 대해 짧은 텍스트 형태의 설명을 제공하기 위해 사용한다.
상태 코드는 오토마타(automata)가 사용하고 이유 문구는 인간 사용자가 사용하기 위해서이다.

상태 코드의 첫 자리 숫자는 응답의 클래스를 규정하며 마지막 두 자리 숫자는 아무런 구분
역할을 가지고 있지 않다. 첫 자리에는 다섯 가지의 숫자가 올 수 있다.

? 1xx: 알림 정보 (Informational) ? 요구가 수신되어 계속 처리

? 2xx: 성공 (Success) ? 요구 메시지를 성공적으로 수신 및 해석을 하고 이를 허용

? 3xx: 방향 재설정 (Redirection) ? 요구에 대한 처리를 완료하기 위하여 추가 조치가 필
요

? 4xx: 클라이언트 오류 (Client Error) ? 요구 메시지가 잘못된 형식으로 구성되어 있기나
제대로 처리할 수 없는 경우

? 5xx: 서버 오류 (Server Error) ? 명백히 유효한 요구 메시지를 서버가 처리할 수 없을 때

HTTP/1.1이 규정한 숫자 상태 코드의 개별적인 값 및 이에 상응하는 Reason-Phrase의 예가 아
래에 제시되어 잇다. 여기에 열거된 이유 구문은 단지 권고 사항일 뿐이다. - 이유 구문은 규
약에 영향을 미치지 않고도 지역적인 등가물(equivalents)로 대체할 수 있다.

Status-Code    = "100"   ; Continue(계속)
                 | "101"   ; Switching Protocols(규약 전환)
                 | "200"   ; OK
                 | "201"   ; Created(생성 되었음)
                 | "202"   ; Accepted(접수 되었음)
                 | "203"   ; Non-Authoritative Information(비 인증 정보)
                 | "204"   ; No Content (내용이 없음)
                 | "205"   ; Reset Content(내용을 지움)
                 | "206"   ; Partial Content(부분 내용)
                 | "300"   ; Multiple Choices(복수 선택)
                 | "301"   ; Moved Permanently(영구 이동)
                 | "302"   ; Moved Temporarily(임시 이동)

[Page 39]

                 | "303"   ; See Other(다른 것을 참조)
                 | "304"   ; Not Modified(변경되지 않았음)
                 | "305"   ; Use Proxy(프락시를 사용할 것)
                 | "400"   ; Bad Request(잘못된 요구)
                 | "401"   ; Unauthorized(인증되지 않았음)
                 | "402"   ; Payment Required(요금 지불 요청)
                 | "403"   ; Forbidden(금지되었음)
                 | "404"   ; Not Found(찾을 수 없음)
                 | "405"   ; Method Not Allowed(method를 사용할 수 없음)
                 | "406"   ; Not Acceptable (접수할 수 없음)
                 | "407"   ; Proxy Authentication Required(프락시 인증 필요)
                 | "408"   ; Request Time-out(요구 시간 초과)
                 | "409"   ; Conflict(충돌)
                 | "410"   ; Gone(내용물이 사라졌음)
                 | "411"   ; Length Required(길이가 필요함)
                 | "412"   ; Precondition Failed(사전 조건 충족 실패)
                 | "413"   ; Request Entity Too Large (요구 엔터티가 너무 큼)
                 | "414"   ; Request-URI Too Large(Request-URI가 너무 김)
                 | "415"   ; Unsupported Media Type(지원되지 않는 미디어 유형)
                 | "500"   ; Internal Server Error(서버 내부 에러)
                 | "501"   ; Not Implemented(구현되지 않았음)
                 | "502"   ; Bad Gateway(불량 게이트웨이)
                 | "503"   ; Service Unavailable(서비스를 사용할 수 없음)
                 | "504"   ; Gateway Time-out(게이트웨이 시간 초과).
                 | "505"   ; HTTP Version not supported (지원되지 않는 HTTP 버
전)
                 | extension-code
extension-code   = 3DIGIT

Reason-Phrase    = *

HTTP상태 코드는 확장할 수 있다. HTTP 애플리케이션이 반드시 모든 등록된 상태 코드의 의
미를 이해할 필요는 없다.(이것이 분명 바람직하기는 하다.) 그러나 애플리케이션은 반드시 첫
단위가 표시하는 상태 코드의 클래스를 이해해야 하며 인식할 수 없는 응답은 해당 클래스의
x00 상태 코드와 동일한 것으로 처리해야 한다. 인식되지 않은 응답은 절대 캐시해서는 안 된
다. 예를 들어 클라이언트가 인식되지 않은 상태 코드 431을 수신하였으면 클라이언트는 요구
에 무엇인가 잘못이 있었으며 응답을 400 상태 코드로 수신한 것으로 안전하게 가정할 수 있
다. 이러한 경우 사용자 에이전트는 응답과 함께 리턴 된 엔터티를 사용자에게 제시해야 한다.
엔터티는 대개 사람이 읽을 수 있는 정보(비 정상적인 상태를 설명하는 정보)를 포함하고 있
기 때문이다.
 [Page 40]

6.2 응답 헤더 필드

응답 헤더 필드는 서버가 Status-Line에 표시할 수 없는 응답에 대한 추가 정보를 전달할
수 있도록 한다. 이러한 헤더 필드는 서버와 Request-URI가 식별하는 자원에 추가적으로
접근하는 방법에 대한 정보를 제공한다.

response-header  = Age                     ; 14.6 절
     | Location               ; 14.30 절
      | Proxy-Authenticate    ; 14.33 절
     | Public                 ; 14.35 절
     | Retry-After             ; 14.38 절
     | Server                 ; 14.39 절
     | Vary                   ; 14.43 절
      | Warning                ; 14.45 절
     | WWW-Authenticate     ; 14.46 절

Response-header 필드 이름은 규약 버전의 변경과 함께 확장했을 때만 신뢰성 있게 확장될
수 있다. 그러나 새로운 또는 실험적으로 사용하는 헤더 필드에 응답 헤더의 의미를 적용할
수 있는데, 이 경우는 통신에 참여하는 모든 대상이 그것을 response-header 필드로 인식
할 수 있을 때만 가능하다. 인식할 수 없는 헤더 필드는 Entity-Header 필드로 처리된다.

7 엔터티(Entity)

요구와 응답 메시지는 별도로 요구 method나 응답 상태 코드에 의하여 제한을 받지 않는 한
엔터티를 전송할 수도 있다. 어떤 응답은 엔터티 헤더만을 포함할 수도 있지만 엔터티는
Entity-Header 필드와 Entity-Body로 구성되어 있다.

이 절에서 송신자와 수신자는 누가 엔터티를 발송하고 누가 엔터티를 수신하는가에 따라 클라
이언트와 서버 어느 쪽이든지 지칭할 수 있다.

7.1 엔터티 헤더 필드

엔터티 헤더 필드는 Entity-Body에 대한 또는 본문이 없다면 요구 메시지를 통해 확인할
수 있는 자원에 대한 선택적인 메타 정보를 정의하고 있다.

[Page 41]

Entity-Header   = Allow                    ; 14.7 절
   | Content-Base             ; 14.11 절
   | Content-Encoding        ; 14.12 절
   | Content-Language        ; 14.13 절
   | Content-Length           ; 14.14 절
   | Content-Location         ; 14.15 절
   | Content-MD5             ; 14.16 절
   | Content-Range            ; 14.17 절
   | Content-Type             ; 14.18 절
   | ETag                     ; 14.20 절
   | Expires                  ; 14.21 절
   | Last-Modified            ; 14.29 절
   | extension-header

extension-header = message-header

Extension-Header 메커니즘은 규약을 변경하지 않고도 추가적인 Entity-Header 필드를
정의할 수 있게 한다. 그러나 이러한 필드를 수신자가 인식할 수 있다고 가정할 수는 없다. 인
식할 수 없는 필드는 수신측이 무시해야 하며 프락시를 통하여 전송한다.

7.2 엔터티 본문 (Entity Body)

HTTP 요구나 응답과 함께 발송된 (만약 있다면) Entity-Body는 Entity-Header 필드에서
규정한 포맷 및 인코딩에 따른다.

Entity-Body    = *OCTET

Entity-Body는 4.3 절에서 설명한 대로 Message-Body가 있을 때만 메시지 내에 존재한다.
안전하고 적절한 메시지 전송을 위해 적용되었을 수도 있는 Transfer-Encoding을 해독하
여 Message-Body에서 Entity-Body를 얻을 수 있다.

7.2.1 유형 (Type)

메시지에 Entity-Body가 포함되어 있으면 해당 본문의 데이터 타입은 Content-Type 및
Content-Encoding 의 헤더 필드를 통하여 결정된다. 이는 2 계층의 순서가 정해진 인코딩
모델을 규정한다.

Entity-Body  := Content-Encoding( Content-Type( data ) )

Content-Type은 메시지 본문 내용의 미디어 형식을 명시한다. Content-Encoding 은 대개
데이터를 압축할 목적으로 데이터에 적용된 추가적인 내용 코딩(요구된 자원의 속성이다)을
표시하는 데 사용할 수 있다.
 [Page 42]

Entity-Body를 포함하고 있는 모든 HTTP/1.1 메시지는 해당 본문의 미디어 형식을 규정하
는 Content-Type 헤더 필드를 포함하여야 한다. Content-Type 필드가 미디어 형식 정보를
제공하지 않는 경우에만 수신측은 자원을 확인하는 데 사용되는 URL 이름 확장자 및/또는 내
용 검사를 통하여 미디어 형식을 짐작하려 시도할 수도 있다. 계속 미디어 형식을 알 수 없다
면 수신측은 그것을 "application/octet-stream" 유형으로 처리해야만 한다.

7.2.2 길이

Entity-Body의 길이는 모든 전송 인코딩(Transfer-Coding)이 디코딩된 후의 Message-
Body의 길이이다. 4.4 절은 Message-Body의 길이를 결정하는 방법을 규정하고 있다.

8 접속(Connections)

8.1 지속형 연결(Persistent Connections)

8.1.1 목적

지속형 연결 개념이 등장하기 이전에는 각 URL의 정보를 가져오기 위해 매번 별도의 TCP
연결을 설정하여 HTTP 서버의 부하를 증가시키고 인터넷의 트래픽 혼잡을 유발했었다. 하이
퍼링크되어 있는 이미지와 및 기타 관련 데이터의 사용은 종종 클라이언트가 아주 짧은 시간
에 여러 개의 요구를 동일한 서버에 하도록 만들 수 있다. 이러한 성능 문제에 대한 분석을
[30][27]에서 참고할 수 있으며, 프로토타입 구현의 분석 및 결과를 [26]에서 참고할 수 있다.

지속형 HTTP 접속은 여러 가지 이점이 있다.

? TCP 연결을 시작하고 종료하는 회수를 줄임으로써 CPU 시간을 줄이고 TCP 규약 제어
블록에 사용되는 메모리를 절약할 수 있다.
? HTTP 요구와 응답이 연결선 상에서 파이프라인 될 수 있게 한다. 파이프라인을 사용하
면 클라이언트는 각 응답을 기다리지 않고도 복수의 요구를 할 수 있어 하나의 TCP 연
결을 효과적으로 빠른 시간 내에 이룩할 수 있다.
? TCP를 시작할 때 발생하는 패킷의 숫자를 감소시키고 네트워크의 혼잡 상태를 결정할
충분한 시간을 TCP에 주어 네트워크 혼잡을 줄일 수 있다.
? 오류가 발생해도 TCP 접속을 단절하지 않고도 이를 보고할 수 있기 때문에HTTP가 좀
더 잘 작동될 수 있도록 한다. HTTP 향후 버전을 사용하는 클라이언트는 새로운 기능을
시도할 수 있으나 이전 서버와 통신을 할 때 에러가 발생하면 이전 버전으로 재시도한
다.

HTTP 구현은 지속형 연결을 구현해야 한다.

[Page 43]

8.1.2 전반적인 운영

HTTP/1.1과 이전 버전의 HTTP의 큰 차이점은 지속적인 접속이 모든 HTTP 접속의 기본 방식
이라는 것이다. 별도의 표시가 없으면 클라이언트는 지속적인 접속을 유지한다고 가정한다.

지속적인 접속은 클라이언트와 서버가 TCP 연결 종결을 알릴 수 있는 메커니즘을 제공한다.
이러한 알림은 Connection 헤더 필드를 이용한다. 종료 신호가 통보되면 클라이언트는 더 이상
해당 연결에 요구를 보내서는 안 된다.

8.1.2.1 협상(Negotiation)

HTTP/1.1 서버는 요구 메시지에 "종료" Connection-Token이 포함된 Connection 헤더가 발송되지
않는 한 HTTP/1.1 클라이언트는 지속적인 접속을 유지하고자 한다고 가정한다. 서버가 응답을
발송한 후 곧 바로 연결을 종료하고자 한다면 종료 Connection-Token이 포함된 Connection 헤
더를 발송해야만 한다.

HTTP/1.1 클라이언트는 접속이 계속 유지되기를 기대하지만 서버로부터의 응답이 종료
Connection-Token의 Connection 헤더를 포함하고 있는가 여부에 따라 접속 유지 여부를 결정할
수도 있다. 클라이언트가 해당 요구 이상의 접속을 유지하기 원치 않는다면 클라이언트는 종
료 Connection-Token이 포함된 Connection 헤더를 발송해야 한다.

클라이언트 또는 서버가 Connection 헤더에 종료 토큰을 발송하면 해당 요구는 접속에 대한
마지막 요구가 된다.

클라이언트나 서버는 명확하게 표시되지 않는 한 1.1 이전의 HTTP 버전에서 지속적인 접속이
유지된다고 가정해서는 안 된다. HTTP/1.0 클라이언트와의 호환성 유지에 관한 정보는 19.7.1
절을 참조한다.

지속적으로 유지되기 위해서 연결선 상의 모든 메시지는 4.4 절에서 설명된 스스로 정의된 메
시지 길이(예를 들면 접속 종료에 의해 규정되지 않는)를 포함하고 있어야 한다.

8.1.2.2 파이프라인 사용

지속적인 접속을 지원하는 클라이언트는 요구를 파이프라인(복수의 요구를 각각의 응답을 기
다리지 않고 발송)할 수 있다. 서버는 반드시 이러한 요구에 대한 응답을 요구가 수신된 동일
한 순서로 발송해야 한다.

[Page 44]

접속된 후 곧 바로 지속적인 접속이나 파이프라인(pipeline)을 예상하는 클라이언트는 첫 파이
프라인 시도가 실패할 경우 재시도할 준비가 되어 있어야 한다. 클라이언트가 재시도를 했을
때 접속이 지속적인지 알기 전에는 파이프라인 기능을 절대로 사용해서는 안 된다. 클라이언
트는 서버가 모든 상응하는 응답을 발송하기 전에 접속이 종료되었으며 재발송할 준비가 되어
있어야만 한다.

8.1.3 프락시 서버

프락시가 14.2.1 절에 명시된 Connection 헤더 필드의 특성을 정확하게 구현하는 것이 특히 중
요하다.

프락시 서버는 연결하고 있는 클라이언트와 원서버(또는 다른 프락시 서버)의 지속적인 접속
을 반드시 구분하여 알려야 한다. 각각의 지속적 접속은 단지 하나의 전송 링크에만 적용한다.

프락시 서버는 절대 HTTP/1.0과 지속적인 접속을 설정해서는 안 된다.

8.1.4 실제적인 고려 사항

서버는 대개 비활성 접속을 더 이상 유지하지 않을 시간 초과 값을 가지고 있다. 프락시 서버
는 클라이언트가 동일한 서버를 통하여 더 많은 접속을 설정하기 쉽기 때문에 이 값을 더 높
게 할 수 있다. 지속적인 접속의 사용은 클라이언트나 서버의 시간 초과 길이에 어떠한 필요
조건을 두지 않는다.

클라이언트 또는 서버가 시간 초과 기능을 사용하고자 할 때 전송 접속 상에 종료를 알려야
한다. 클라이언트와 서버는 전송 선상의 다른 쪽의 접속 종료를 항상 주시하고 있다가 적절하
게 반응하여야 한다. 클라이언트 또는 서버가 다른 쪽의 종료를 신속하게 감지하지 못하면 네
트워크 상의 불필요한 자원 낭비를 초래하게 된다.

클라이언트, 서버 또는 프락시는 언제든지 전송 접속을 종료할 수 있다. 예를 들어 클라이언트
는 서버가 "사용하지 않는" 접속을 종료하기로 결정한 바로 그 순간에 새로운 요구 발송을 시
작했을 수 있다. 서버 관점에서 보면 접속은 사용하지 않고 있는 동안은 종료되고 있는 것이
며 클라이언트의 관점에서 보면 요구가 처리되고 있는 것이다.

이는 클라이언트, 서버 및 프락시가 반드시 동시 종료 이벤트에서 회복할 수 있어야 한다는
것을 의미한다. 클라이언트 소프트웨어는 전송 접속을 재개할 수 있어야 하며 요구 method가
멱등원(冪等元) method(9.1.2 절 참조)일 경우 사용자와의 상호 작용 없이도 중단된 요구를 재
전송할 수 있어야 한다. 다른 method는 사용자 에이전트가 인간 운영자에게 요구를 재시도할
수 있는 선택권을 줄 수도 있지만 자동적으로 재시도해서는 안 된다.

[Page 45]

그러나 두 번째 요구가 실패할 경우 자동적인 재시도를 반복해서는 안 된다.

서버는 가능하다면 항상 한 접속 건 당 최소한 하나의 요구에 응답해야 한다. 서버는 네트워
크나 클라이언트 실패가 발생할지도 모르는 상황이 아니면 응답을 전송하는 도중에 접속을 종
료해서는 안 된다.

지속적인 접속을 사용하는 클라이언트는 특정 서버로의 동시 접속 숫자에 제한을 두어야 한다.
단독 사용자 클라이언트는 최대 2 개의 서버나 프락시 접속을 유지해야 한다. 프락시는 최대
2*N 개의 서버나 프락시 접속을 할 수 있으며 여기서 N은 사용하고 있는 동시 사용자의 숫
자이다. 이러한 지침은 HTTP 응답 시간을 향상하고 인터넷이나 다른 네트워크의 혼잡을 피하
기 위함이다.

8.2 메시지 전송 필요 조건

일반적인 필요 조건:

? HTTP/1.1 서버는 지속적인 접속을 유지하고 있어야 하며 일시적인 오버로드(overloads)를 완화
시키기 위하여 클라이언트가 재시도할 것이라는 예상으로 접속을 종결하기보다는 흐름 제어
메커니즘을 사용해야 한다. 후자의 방법을 사용하면 네트워크 혼잡이 가중될 수 있다.

? Message-Body를 발송하는 HTTP/1.1 (또는 이후) 클라이언트는 요구를 전송하는 동안 네트워크
접속에 에러가 발생하는지 점검해야 한다. 클라이언트가 에러를 감지하였으면 본체 전송을
즉시 중단해야 한다. 본체가 "덩어리" 인코딩(3.6 절) 기법을 사용하여 전송되고 있을 경우에
는 제로 길이의 덩어리와 비어 있는 주석을 사용하여 메시지의 종료를 조기에 표시할 수도
있다. 본문에 앞서 Content-Length 헤더가 있으면 클라이언트는 접속을 종료해야 한다.
? HTTP/1.1 (또는 이후) 클라이언트는 정상적인 응답이 뒤 따르는 100(Continue) 상태 메시지를
접수할 준비가 반드시 되어 있어야 한다.

? HTTP/1.0 (또는 이전) 클라이언트로부터 요구를 수신한 HTTP/1.1 (또는 이후) 서버는 100
(Continue) 응답 메시지를 전송해서는 안 된다. 서버는 요구가 정상적으로 완료될 때까지(이렇
게 하여 중단된 요구가 발생하지 않도록 함) 기다리던가 조기에 접속을 종료해야 한다.

[Page 46]

HTTP/1.1 (또는 이후) 클라이언트로부터 이러한 필요 조건을 만족해야 하는 method를 수신하
면 HTTP/1.1 (또는 이후) 서버는 반드시 100 (Continue) 상태로 응답하고 입력 스트림에서 계속
적으로 요구를 읽어 들이든지 에러 상태 코드로 응답해야 한다. 에러 상태 코드로 응답하였으
면 전송(TCP) 접속을 종료하던지 또는 계속적으로 요구를 읽어 들이고 요구의 나머지 부분을
폐기할 수 있다. 에러 상태 코드를 리턴했을 때는 요구 받은 method를 절대로 처리해서는 안
된다.

클라이언트는 최소한 가장 최근에 사용된 서버의 버전 숫자를 기억하고 있어야 한다. HTTP/1.1
클라이언트가 HTTP/1.1 또는 이후의 응답을 서버로부터 얻고 서버로부터 상태 메시지를 수신
하기 전에 연결이 종료되었으면 클라이언트는 요구 method가 멱등원(冪等元) method(9.1.2 절
참조)이 아닌 이상 사용자와의 상호 작용 없이 요구를 재시도해야 한다. 사용자 에이전트가
인간 운영자에게 요구를 재시도할 선택권을 줄 수는 있지만 다른 method를 자동적으로 재시
도해서는 안 된다. 클라이언트가 요구를 재시도 했으면 클라이언트는

? 반드시 먼저 요구 헤더 필드를 발송해야 하며 그런 다음
 
? 서버가 100 (Continue) 응답(이 경우 클라이언트는 계속 진행해야 한다)이나 에러 코드를
응답할 때 까지 반드시 기다려야 한다.

HTTP/1.1 클라이언트가 HTTP/1.1이나 이후 응답을 서버로부터 얻지 못하면 서버가 HTTP/1.0
이나 이전 버전을 구현하고 있으면 100 (Continue) 응답을 사용하지 않을 것으로 가정해야 한
다. 이 경우 클라이언트가 서버로부터 상태 메시지를 접수하기 전에 접속이 종료되면 클라이
언트는 요구를 재시도해야 한다. 클라이언트가 이 HTTP/1.0 서버에 요구를 재시도할 때 아래
의 "바이너리 지수 백오프(binary exponential backoff)" 알고리즘을 사용하여 신뢰할 수 있는 응
답을 얻었음을 확인해야 한다.

1.  서버로 새로운 접속을 시작한다.
 
2.  Request-Header을 전송한다.
 
3.  변수 R을 서버로의 예상 왕복 여행 시간으로 초기화한다.(예를 들면 접속을 설정하기 위
해 소요되는 시간에 기초한다)
 
4.  T = R * (2**N)을 계산한다. 이때 N은 이 요구를 이전에 재시도한 숫자이다.
 
5.  서버로부터 에러 응답을 기다리던가 T 초 동안 기다린다. (어떤 것이든 먼저 오는 것)

[Page 47]

6.  아무런 에러 응답도 수신되지 않았으면 T 초가 경과한 후 요구의 본문을 전송한다.
 
7.  클라이언트가 접속이 조기에 종료되는 것을 알았으면 요구가 접수되었거나, 에러 응답을
수신하였거나 또는 사용자가 더 이상 기다릴 수 없어 재시도 절차를 종료할 때 까지 첫
스텝부터 계속한다.

서버 버전에 관계없이 에러 상태가 접수되었으면 클라이언트는

? 절대로 계속해서는 안 되며
 
? 메시지 전송을 완료하지 않았으면 접속을 반드시 종료해야 한다.

다른 어떤 상태 메시지를 접수하기 이전에 100 (Continue)을 수신한 후 접속을 종료한 것을 인
지한 HTTP/1.1 (또는 이후) 클라이언트는 요구를 재시도해야 하며 100 (Continue) 응답을 기다릴
필요가 없다.(그러나 이것이 구현 방법을 단순하게 한다면 기다려도 된다.)

9 Method 정의

HTTP/1.1에서 사용되는 일반적인 method 세트를 아래에 규정하였다. 이 세트를 확장할 수 있
지만 추가된 method를 별도로 확장된 클라이언트와 서버가 동일한 의미를 공유하고 있다고
가정할 수 없다.

호스트 Request-Header 필드(14.23 절)는 반드시 모든 HTTP/1.1 요구를 따라야 한다.

9.1 안전 및 멱등원(冪等元) method

9.1.1 안전 method

구현자는 소프트웨어가 사용자와의 상호작용이 인터넷을 통하여 표시된다는 점을 인지해야 하
며 사용자에게 자신이 취하는 행동이 자신과 다른 사용자에게 예상하지 못한 중요성을 가질
수 있다는 점을 인지시키도록 주의해야 한다.

특히 GET 및 HEAD method가 조회 이외의 작업을 수행하는 중요성을 가져서는 안 된다는 관
례가 확립되었다. 이러한 method는 안전한 것으로 간주해야 한다. 이렇게 하여 사용자 에이전
트가 POST, PUT 및 DELETE와 같은 다른 method를 특별한 방식으로 표현할 수 있게 하며
사용자가 안전하지 못한 처리를 요구하고 있다는 사실을 인식할 수 있게 한다.

당연히 서버가 GET 요구를 수행한 결과로서 부작용을 발생하지 않고 있음을 보장할 수 없다.
[Page 48]

사실상 몇몇 역동적인 자원은 이것을 하나의 기능으로 보고 있다. 중요한 구별 점은 사용자가
부작용을 요청하지 않았기 때문에 부작용에 대한 책임을 부과할 수는 없다는 것이다.

9.1.2 멱등원(冪等元) method

Method는 또한 N > 0 과 동일한 요구의 부작용이 단일 요구의 부작용과 동일하다는 점에서
"멱등원" 특성을 가질 수 있다.(에러 또는 만기일의 문제는 별도로 하고)  GET, HEAD, PUT 및
DELETE method는 이 특성을 공유하고 있다.

9.2 OPTIONS

OPTIONS method는 Request-URI에 의하여 식별되는 Request/Response chain에서 사용할 수 있
는 통신 선택 사항에 관한 정보 요구를 표시한다. 이 method는 클라이언트가 자원 처리를 시
도하거나 자원 조회를 시작하지 않고도 선택 사항 및/또는 자원과 관련된 필요 조건, 서버의
처리 능력을 결정할 수 있게 한다.

서버의 응답이 에러가 아닌 이상 응답은 통신 선택 사항이라고 간주할 수 있는 것 이외의 엔
터티 정보를 포함해서는 안 된다.(예를 들어 Allow 는 적합하지만 Content-Type은 적합하지 않
다).

Request-URI 가 별표("*")이면 OPTIONS 요구는 전체를 서버에 적용하려는 것이다. 200 응답은
모든 적용 가능한 일반 필드 또는 Response-Header 필드 이외에 이 규격에서 규정하지 않는
모든 확장을 포함하여 서버가 구현한(예 Public) 선택 기능을 표시하는 모든 헤더 필드를 포함
해야 한다. 5.1.2 절에서 설명된 것처럼  "OPTIONS *" 요구는 경로 정보 없이 Request-URI에
목적지 서버를 명시함으로써 프락시를 통하여 적용할 수 있다.

Request-URI가 별표가 아니면 OPTIONS 요구는 해당 자원과 통신할 때 사용할 수 있는 선택
사항에만 적용된다. 200 응답은 모든 적용 가능한 일반 필드 또는 Response-Header 필드 이외
에 이 규격에서 규정하지 않는 모든 확장을 포함하여 서버가 구현한(예 Allow) 선택 기능을
표시하는 모든 헤더 필드를 포함해야 한다. OPTIONS 요구가 프락시를 통한다면 프락시는 프
락시의 성능에 관계되는 선택 사항 및 프락시를 통하여 사용할 수 없는 것으로 알려진 선택
사항을 제외할 수 있도록 응답을 반드시 편집해야 한다.

[Page 49]

9.3 GET

GET method는 Request-URI가 식별하는 모든 정보(엔터티의 형태로)를 조회한다는 것을 의미
한다. Request-URI가 데이터를 생성하는 프로세스를 참조한다면 텍스트가 우연히 프로세스의
산출물이 아닌 이상 엔터티로서 리턴 되는 것은 프로세스의 소스 텍스트가 아니라 생성된 데
이터이다.

GET method의 의미는 요구 메시지가 If-Modified-Since, If-Unmodified-Since, If-Match, If-None-
Match 또는 If-Range 헤더 필드를 포함하고 있으면 "조건적인 GET"으로 변화한다. 조건적인
GET method는 엔터티가 조건 헤더 필드가 명시한 조건 하에서만 전송되도록 요청하는 것이다.
조건적 GET method는 복수의 요구나 클라이언트가 이미 보유하고 있는 데이터를 전송하지 않
고도 캐시 된 엔터티를 갱신할 수 있도록 함으로서 불필요한 네트워크 사용을 감소시키기 위
해 사용한다.

GET method의 의미는 요구 메시지가 Range 헤더 필드를 포함하고 있으면 "부분적인 GET"으
로 변화한다. 부분적인 GET method는 14.36 절에 설명된 것처럼 엔터티의 일 부분만 전송하도
록 요청하는 것이다. 부분적 GET method는 클라이언트가 이미 보유하고 있는 데이터를 전송
하지 않고도 부분적으로 조회한 엔터티가 완성될 수 있도록 함으로써 불필요한 네트워크 사용
을 감소시키기 위해 사용한다.

GET 요구에 대한 응답은 13 장에 설명된 대로 HTTP 캐시 요구 필요 조건을 만족할 경우에만
캐시할 수 있다.

9.4 HEAD

HEAD method는 서버가 응답 메시지에 Message-Body를 반드시 리턴해야 한다는 것 이외에는
GET과 동일하다. HEAD 요구에 대한 응답으로 HTTP 헤더에 포함된 메타 정보는 GET 요구에
대한 응답으로 발송된 정보와 반드시 동일해야 한다. 이 method는 Entity-Body 자체를 전송하
지 않고도 요구가 내포하는 엔터티에 대한 메타 정보를 얻는 데 사용할 수 있다. 이 method는
종종 하이퍼텍스트 링크의 유효성, 접근성 및 최근의 변경 사항을 테스트하기 위해 사용된다.

HEAD 요구에 대한 응답은 응답에 포함된 정보를 해당 자원의 이전 캐시 엔터티를 갱신하는
데 사용할 수 있다는 의미에서 캐시할 수 있다. 새로운 필드 값이 캐시 된 엔터티가 현재 의
엔터티 (Content-Length, Content-MD5, ETag 또는 Last-Modified의 변화에 의해 표시되는 것과 같
은)와 상이함을 표시할 때는 캐시는 반드시 이 캐시 엔트리를 낡을 것으로 취급해야 한다.

[Page 50]

9.5 POST

POST method는 서버에게 Request-Line의 Request-URI가 식별하는 자원의 새로운 부속물로서
요구에 포함된 엔터티를 접수할 것을 요구하는 데 사용한다. POST는 다음의 기능을 수행하는
일관된 method를 사용할 수 있도록 디자인 되었다.

? 기존 자원의 주해;
 
? 게시판, 뉴스그룹, 편지 발송 목록 또는 유사한 기사 그룹으로 메시지를 송부;
 
? 폼을 제출한 결과로 발생한 데이터 블록을 데이터 처리 프로세스에 제공;
 
? 추가 작업을 통한 데이터 베이스의 확장.

POST method가 실제적으로 수행하는 기능은 서버가 결정하며 보통 Request-URI에 달려 있다.
발송된 엔터티는 파일이 파일을 포함하고 있는 디렉토리에 종속되고, 뉴스 기사가 발송한 뉴
스그룹에 종속되며 레코드가 데이터 베이스에 종속되듯이 해당 URI에 종속된다.

POST method가 수행하는 작업이 URI로 식별할 수 있는 자원을 생성하지 않을 수도 있다. 이
러한 경우 응답이 결과를 설명하는 엔터티를 포함하고 있는가 여부에 따라 200(OK)이나
204(No Content)가 적절한 응답 상태이다.

새로운 자원이 원서버에서 생성되었다면 응답은 201(Created)이어야 하고 요구의 상태를 설명
하며 새로운 자원 및 Location 헤더 (14.30 절 참조)를 지칭하는 엔터티를 포함해야 한다.

이 method에 대한 응답은 응답이 적절한 Cache-Control 또는 Expires 헤더 필드를 포함하지 않
는 한 캐시할 수 없다. 그러나 303(See Other) 응답을 사용하여 사용자 에이전트에게 캐시할 수
있는 자원을 조회하도록 지시할 수 있다.

POST 요구는 8.2 절에 설정된 메시지 전송 필요 조건을 반드시 따라야 한다.

[Page 51]

9.6 PUT

PUT method는 동봉된 엔터티를 제공된 Request-URI에 저장하도록 요구한다. Request-URI가 이
미 존재하는 자원을 지칭할 경우 동봉된 엔터티는 원서버에 있는 엔터티의 변경된 버전으로
간주해야 한다. Request-URI가 기존 자원을 지칭하지 않고 URI가 요구하는 사용자 에이전트가
새로운 자원으로 규정할 수 있다면 원서버는 해당 URI로 자원을 생성할 수 있다. 만약 새로
운 자원이 생성되었으면 원서버는 사용자 에이전트에게 201(Created) 응답을 알려야 한다. 기존
자원이 변경되었다면 200(OK)이나 204(No Content) 응답 코드를 발송하여 요구를 성공적으로
완료하였음을 표시하여야 한다. Request-URI로 자원을 생성하거나 변경할 수 없는 경우에는 문
제의 기본 성격을 반영하는 적절한 에러 응답을 발송해야 한다. 엔터티의 수신측은 이해 또는
구현할 수 없는 Content-* (예: Content-Range) 헤더를 반드시 무시해야 하고 이러한 경우
501(Not Implemented) 응답을 리턴해야 한다.

요구가 캐시를 통과할 경우 Request-URI는 하나 또는 그 이상의 현재 캐시 된 엔터티를 식별
한다. 이러한 엔터티는 낡은 것으로 취급해야 하며 이러한 method에 대한 응답은 캐시할 수
없다.

POST와 PUT 요구의 근본적인 차이점은 Request-URI의 다른 의미에 반영된다. POST의 URI
는 동봉된 엔터티를 처리할 자원을 식별한다. 그 자원은 데이터를 접수하는 프로세스, 다른 규
약으로의 게이트웨이 또는 주석을 접수하는 별도의 엔터티일 수 있다. 이에 비하여 PUT 요구
의 URI는 요구에 포함된 엔터티를 식별한다. - 사용자 에이전트는 어떤 URI를 의도하고 있으
며 서버는 요구를 다른 자원에 적용해서는 절대로 안 된다는 것을 알고 있다. 만약 서버가 해
당 요구를 다른 URI에 적용하고자 한다면 서버는 301(Moved Permanently) 응답을 반드시 발송
해야 한다. 그러면 사용자 에이전트는 해당 요구의 방향을 재설정 할 것인지에 관한 자신의
결정을 한다.

단일 자원이 복수의 상이한 URI에 의하여 식별될 수 있다. 예를 들어 기사(article)는 각각의
특별한 버전을 식별하는 URI와 구별되는 "현재 버전"을 확인하기 위한 URI를 가질 수 있다.
이 경우 일반 URI의 PUT 요구는 원서버에 의하여 규정되는 복수의 URI를 생성할 수도 있다.

HTTP/1.1은 PUT method가 어떻게 원서버의 상태에 영향을 미치는가에 대해서는 규정하지 않
는다.

PUT 요구는 8.2 절에 설정된 메시지 전송 필요 조건을 반드시 따라야 한다.

[Page 52]

9.7 DELETE

DELETE method는 Request-URI가 식별하는 자원을 삭제하도록 원서버에 요구한다. 이 method
는 원서버에서 사용자의 개입(또는 다른 방법)에 의하여 무시될 수 있다. 클라이언트는 비록
원서버에서 발송한 상태 코드가 해당 작업이 성공적으로 완수되었다는 표시를 하여도 실제로
작업이 완료되었다는 보장을 받을 수 없다. 그러나 서버는 요구를 접수한 시점에서 자원을 삭
제하거나 접근할 수 없는 위치로 이동할 의사가 없는 한 성공을 표시해서는 안 된다.

성공적인 응답은 응답이 상태를 설명하는 엔터티를 포함한다면 200 (OK), 처리가 시작되지 않
았으면 202 (Accepted), 응답은 OK이나 엔터티를 포함하지 않고 있으면 204 (No Content)이다.

요구가 캐시를 통과할 경우 Request-URI는 하나 또는 그 이상의 현재 캐시 된 엔터티를 식별
한다. 이러한 엔터티는 낡은 것으로 취급해야 하며 이러한 method에 대한 응답은 캐시할 수
없다.

9.8 TRACE

TRACE method는 요구 메시지의 원격지, 애플리케이션-계층 루프백(loop back)을 호출하는 데
사용한다. 응답의 최종 수신측은 클라이언트에게 되돌려 진 메시지를 200(OK) 응답의 Entity-
Body로 수신해야 한다. 마지막 수신측은 메시지의 Max-Forwards 제로 값(14.31 절)을 수신하는
원서버, 첫 프락시 또는 게이트웨이이다. TRACE 요구는 절대 엔터티를 포함해서는 안 된다.

TRACE는 클라이언트가 Request chain의 다른 끝 쪽에 무엇이 수신되는가를 알 수 있게 하며
그 데이터를 시험 또는 진단 정보로 사용한다. Via 헤더 필드(14.44 절)의 값은 Request chain의
추적 역할을 수행하기 때문에 특히 주목할 만하다. Max-Forwards 헤더 필드를 사용하면 클라이
언트가 Request chain의 길이를 제한할 수 있으며 이는 무한 루프에서 메시지를 전달하는 프락
시 고리를 테스트하는 데 유용하다.

성공적이면 응답은 "message/http" 의 Content-Type을 가진 Entity-Body의 전체 요구 메시지를
포함할 수 있어야 한다. 이러한 method에 대한 응답을 절대 캐시해서는 안 된다.

10 Status Code Definitions

각Status-Code 가 어떤 method를 따를 수 있는가에 대한 설명과 응답에서 필요로 하는 헤더 정보
를 포함하여 아래에 설명되어 있다.

[Page 53]

10.1 정보를 알려 주는 1xx

이 상태 코드 클래스는 잠적적인 응답을 표시하며 Status-Line과 선택적인 헤더로 구성되어 있
다. 이 클래스는 빈 라인으로 종료된다. HTTP/1.0은 어떠한 1xx 상태 코드로 정의하지 않기 때
문에 실험적인 상황 이외에 서버는 1xx 응답을 HTTP/1.0 클라이언트에 발송해서는 안 된다.

10.1.1 100 계속

클라이언트는 요구를 계속 진행할 수 있다. 이 잠정적인 응답은 클라이언트에게 응답의 시초
부분이 수신되었으며 서버가 아직 거부하지 않았음을 알리는 데 사용한다. 클라이언트는 요구
의 나머지 부분을 발송하여야 하며 요구가 완료 되었으면 이 응답을 무시해야 한다. 서버는
요구가 완료된 다음 마지막 응답을 발송한다.

10.1.2 101 규약 전환

서버가 이해하였으며 기꺼이 Upgrade 메시지 헤더 필드(14.41 절)를 통하여 접속에 사용되고
있는 애플리케이션 규약 변경에 관한 클라이언트의 요구에 따른다. 서버는 101 응답을 종료하
는 빈 라인 바로 다음 응답 메시지의 Upgrade 헤더 필드가 정의한 규약으로 전환할 것이다.

규약은 전환하는 것이 유리한 경우에만 전환된다. 예를 들어 새로운 버전의  HTTP로 전환하
는 것이 이전 버전을 사용하는 것보다 유리하며 해당 기능을 사용하는 자원을 배달할 때 실시
간, 동시 규약으로 전환하는 것이 유리하다.

10.2 성공을 알리는 2xx

이 상태 코드 클래스는 클라이언트의 요구가 성공적으로 수신, 해석 및 접수되었음을 표시한
다.

10.2.1 200 OK

요구를 성공적으로 전달하였다. 응답과 함께 리턴 되는 정보는 요구에 사용된 method에 달려
있다. 예를 들면:

   GET  요구한 자원에 상응하는 엔터티는 응답에 포함되어 발송된다.

   HEAD 요구한 자원에 상응하는 Entity-Header 필드는 Message-Body 없이 응답에 포함되어 발송
된다.

[Page 54]

   POST 처리 결과를 설명 또는 포함하는 엔터티.

   TRACE 수신 서버가 수신한 요구 메시지를 포함하고 있는 엔터티

10.2.2 201 Created (생성 되었음)

요구가 충족되었으며 새로운 자원이 생성되고 있다. 새로 생성된 자원은 응답  엔터티의 리턴
된 URI를 통하여 참조할 수 있으며 자원의 가장 상세한 URL은 Location 헤더 필드로 알 수
있다. 원서버는 201 상태 코드를 리턴하기 전에 반드시 자원을 생성해야 한다. 처리가 즉각적
으로 수행될 수 없을 때에 서버는 202(Accepted) 응답으로 대신 응해야 한다.

10.2.3 202 Accepted (접수 되었음)

처리를 위해 응답을 접수하였으나 처리는 완료되지 않았다. 요구는 엔터티의 처리 과정에서
허용되지 않을 수도 있기 때문에 궁극적으로 처리될 수도 있고 처리되지 않을 수도 있다. 이
와 같은 동시 작업에서 상태 코드를 재발송하는 설비는 없다.

202 응답은 의도적으로 작업을 수행하지 않는다. 이 응답의 목적은 서버가 사용자 에이전트가
프로세스가 완료될 때까지 서버에 지속적으로 연결되지 않고도 다른 프로세스에 대한 요구(하
루에 한 번만 실행되는 배치 지향적인 프로세스일 수도 있다.)를 접수할 수 있도록 하는 데
있다. 이 응답을 리턴하는 엔터티는 상태 점검자(monitor)에 대한 지시자 또는 사용자가 언제
요구가 완료될 수 있는지에 대한 예상 및 요구의 현재 상태에 대한 표시를 포함해야 한다.

10.2.4 203 Non-Authoritative Information(비 인증 정보)

Entity-Header의 리턴 된 메타 정보는 서버에서 사용할 수 있는 정의 세트가 아니고 지역 또는
제 3 자의 복사본에서 수집한 것이다. 제시된 세트는 원래 버전의 하부 세트 또는 상위 세트
일 수 있다. 예를 들어 자원에 대한 지역적 주해 정보를 포함하면 원서버가 알고 있는 메타
정보에 대한 상위 세트를 만들어 낼 수도 있다. 이 응답 코드를 사용하는 것은 의무사항이 아니
며 응답이203이 아니면 200 (OK)일 때만 적합하다.

10.2.5 204 No Content(내용이 없음)

서버가 요구를 완전히 처리 했으나 반송할 새로운 정보가 없다. 클라이언트가 사용자 에이전
트이면 요구를 발송하도록 한 문서 내용을 변경해서는 안 된다.

[Page 55]

이 응답은 주로 사용자 에이전트의 문서 내용에 대한 변화를 초래하지 않고 처리를 위한 입력
을 실행하도록 하기 위해 사용한다. 응답은 Entity-Header 형태의 새로운 메타 정보를 포함한다.
이 정보는 사용자 에이전트의 현재 문서에 적용해야 한다.

204 응답은 Message-Body를 포함해서는 안되며 항상 헤더 필드 다음의 첫 빈 라인으로 종료
된다.

10.2.6 205 Reset Content(내용을 지움).

서버가 요구를 완전히 처리하였으며 사용자 에이전트는 요구를 발송하도록 한 문서의 내용을
지워야 한다. 이 응답은 주로 사용자 입력을 통하여 처리를 위한 입력이 발생하도록 하기 위
해 사용한다. 이 응답 뒤에 입력을 수행한 폼을 지워 사용자가 다른 입력 요구를 쉽게 시작할
수 있게 한다. 이 응답은 엔터티를 포함해서는 안 된다.

10.2.7 206 Partial Content(부분적 내용).

서버가 자원에 대한 부분적 GET 요구를 완료하였다. 이 요구는 반드시 원하는 영역을 표시하
는 Range 헤더 필드(14.36 절)를 포함해야 한다. 응답은 이 응답에 포함된 영역을 표시하는
Content-Range 헤더 필드(14.17 절)나 각 파트의 Content-Range 필드를 포함하는
multipart/byteranges Content-Type을 포함해야 한다. multipart/byteranges를 사용하지 않았으면 응
답의Content-Length 헤더 필드는 Message-Body로 전송된 OCTET의 실제 숫자와 정확하게 일
치해야 한다.

Range 및 Content-Range 헤더를 지원하지 않는 캐시는 206(Partial Content) 응답을 캐시해서는
안 된다.

10.3  (방향을 재설정하는 3xx)

이 상태 코드 클래스는 사용자 에이전트가 요구를 완전히 처리하기 위해서는 추가적인 처리가
필요하다는 것을 표시한다. 요구되는 처리는 두 번째 요구에 사용된 method가 GET 또는
HEAD일 경우에만 사용자와의 상호작용 없이도 수행될 수 있다. 사용자 에이전트는 이러한
방향 재설정이 무한 루프를 표시하는 것이기 때문에 다섯 번 이상 자동적으로 요구 방향 재설
정을 해서는 안 된다.

[Page 56]

10.3.1 300 Multiple Choices (복수 선택)

요구된 자원이 각자 자신 특유의 위치를 가지고 있는 표현 세트 중의 하나와 대응되며 사용자
(또는 사용자 에이전트)가 선호하는 표현 방식을 선택하고 요구를 해당 위치로 재설정할 수
있도록 에이전트가 주도하는(agent-driven) 협상 정보가 제공된다.

HEAD 요구가 아닌 이상 응답은 사용자 또는 사용자 에이전트가 가장 적합한 것을 선택할 수
있는 자원 특징 및 위의 목록을 포함한 엔터티를 포함한다. 엔터티 포맷은 Content-Type 헤더
필드가 설정한 media type에 의해 명시된다. 사용자 에이전트의 포맷 및 성능에 따라 가장 적
합한 선택을 결정하는 것은 자동으로 수행될 수 있다. 그러나 이 규격은 이러한 자동 선택의
표준에 대하여 아무런 규정도 하지 않는다.

서버가 선호하는 표시 방법을 가지고 있으면 Location 필드에 해당 표시 방법에 대한 상세한
URL을 포함해야 한다. 사용자 에이전트는 Location 필드 값을 이용하여 자동으로 방향을 재
설정할 수 있다. 이 응답은 별도의 표시가 없는 한 캐시할 수 있다.

10.3.2 301 301 Moved Permanently (영구 이동)

요구된 자원에 새로운 영구 URI가 할당되었으며 향후 이 자원에 대한 참조는 리턴 된 URI
중 하나를 이용하여 이루어질 수 있다. 링크를 편집할 수 있는 능력이 있는 클라이언트는 가
능하다면 Request-URI 에 대한 참조를 서버가 리턴한 하나 또는 그 이상의 새로운 참고처로
자동적으로 재링크시켜야 한다. 다르게 표시되어 있지 않으면 이 응답은 캐시할 수 있다.

새로운 URI가 위치이면 해당 URL은 응답의Location 필드가 부여해야 한다. 요구 method가
HEAD가 아니면 응답의 엔터티는 새로운 URI로의 하이퍼링크가 표시된 짧은 하이퍼텍스트
주석을 포함하고 있어야 한다.

GET 또는 HEAD 이외의 요구에 대한 응답에 301 상태 코드가 접수되면 사용자 에이전트는
사용자가 확인하지 않는 한 요구를 발행한 조건을 변경할 수도 있기 때문에 자동적으로 요구
의 방향을 재설정해서는 안 된다.

주의 : 301 상태 코드를 수신한 후 자동적으로 POST 요구의 방향을 재설정할 때 기존의 몇
몇 HTTP/1.0 사용자 에이전트는 실수로 POST 요구를 GET 요구로 변경한다.

[Page 57]

10.3.3 302 Moved Temporarily(임시 이동)

요구된 자원이 별도의 URI에 임시로 보관되어 있다. 방향 재설정은 종종 변경될 수 있기 때문
에 클라이언트는 향후 요구를 위해서 계속해서 Request-URI를 사용해야 한다. 이 응답은 Cache-
Control 또는 Expires 헤더 필드가 표시할 경우에만 캐시할 수 있다.

새로운 URI가 위치이면 해당 URL은 응답의Location 필드가 부여해야 한다. 요구 method가
HEAD가 아니면 응답의 엔터티는 새로운 URI로의 하이퍼링크가 표시된 짧은 하이퍼텍스트
주석을 포함하고 있어야 한다.

GET 또는 HEAD 이외의 요구에 대한 응답에 301 상태 코드가 접수되면 사용자 에이전트는
사용자가 확인하지 않는 한 요구를 발행한 조건을 변경할 수도 있기 때문에 자동적으로 요구
의 방향을 재설정해서는 안 된다.

주의 : 301 상태 코드를 수신한 후 자동적으로 POST 요구의 방향을 재설정할 때 기존의 몇
몇 HTTP/1.0 사용자 에이전트는 실수로 POST 요구를 GET 요구로 변경한다.

10.3.4 303 See Other(다른 것을 참조)

요구된 자원이 별도의 URI에 임시로 보관되어 있으며 해당 자원에서 GET method를 사용하여
조회해야 한다. 이 method는 주로 POST가 활성화한 스크립트의 산출물을 사용자 에이전트가
선택된 자원으로 방향을 재설정할 수 있도록 하기 위해 사용된다. 새로운 URI는 처음 요구된
자원에 대한 대체 참고처가 아니다. 303 응답은 캐시할 수 없으나 두 번째(재설정된) 요구에
대한 응답은 캐시할 수 있다.

GET 또는 HEAD 이외의 요구에 대한 응답에 301 상태 코드가 접수되면 사용자 에이전트는
사용자가 확인하지 않는 한 요구를 발행한 조건을 변경할 수도 있기 때문에 자동적으로 요구
의 방향을 재설정해서는 안 된다.

10.3.5 304 Not Modified(변경되지 않았음)

클라이언트가 조건적 GET 요구를 실행했고 접근할 수 있으나 문서가 변경되지 않았으면 서버
는 이 상태 코드로 응답해야 한다. 이 응답은 Message-Body를 포함해서는 안 된다.

[Page 58]

응답은 다음의 헤더 필드를 포함하고 있어야 한다.

? 날짜
 
? ETag 및/또는 Content-Location, 동일한 요구에 대한 200 응답 속에 헤더가 발송되었을 경
우
 
? Expires, Cache-Control, 및/또는 Vary, 동일한 변이에 대한 이전 응답 속에 발송된 field-
value가 상이할 경우

조건적 GET이 강한 캐시 검증자(13.3.3 절 참조)를 사용했다면 응답은 다른 Entity-Header를
포함해서는 안 된다. 그렇지 않으면(조건적 GET이 약한 캐시 검증자를 사용할 때) 응답은
Entity-Header을 포함해서는 안 된다. 이렇게 하여 캐시 된 Entity-Body과 갱신된 헤더 사이의
불일치를 방지할 수 있다.

304 응답이 현재 캐시 되지 않은 엔터티를 표시할 때 캐시는 이 응답을 무시하고 조건 없이
요구를 반복해야 한다.

캐시가 수신한 304 응답을 캐시 엔트리의 갱신에 사용한다면 캐시는 응답이 가지고 있는 새로
운 필드 값을 반영하기 위해 엔트리를 반드시 갱신해야 한다.

304 응답은 Message-Body를 포함해서는 안되므로 항상 헤더 필드 다음의 첫 공백 라인으로
종료되어야 한다.

10.3.6 305 Use Proxy(프락시를 사용할 것)

요구된 자원을 Location 필드에 명시된 프락시를 통하여 접근해야만 한다. Location 필드가 프
락시의 URL을 제공한다. 수신측은 프락시를 통한 요구를 반복할 것으로 기대된다.

10.4 Client Error 4xx (클라이언트 에러 4xx)

상태 코드의 4xx 클래스는 클라이언트가 에러를 발생한 것처럼 보일 경우에 사용된다. HEAD
요구에 응답하는 경우를 제외하고는 서버는 임시적이건 영구적이건 에러 상황에 대한 설명을
포함한 엔터티를 포함해야 한다. 이러한 상태 코드는 모든 요구 method에 적용할 수 있다. 사
용자 에이전트는 사용자에게 포함된 엔터티를 표시해야 한다.

주의 : 클라이언트가 데이터를 발송한다면 TCP를 사용하는 서버 구현 방식은 서버가 입력
접속을 종료하기 전에 응답을 포함하고 있는 패킷 접수를 확인할 수 있도록 주의해야 한다.
클라이언트가 접속이 종료된 후에도 계속해서 데이터를 전송한다면 서버의 TCP 스택은 리
셋 패킷을 클라이언트에게 발송할 것이다.
 [Page 59]

이 리셋 패킷은 HTTP 애플리케이션이 읽거나 해석하기 전에 클라이언트가 확인한 입력 버
퍼를 지운다.

10.4.1 400 Bad Request(잘못된 요구)

잘못된 형식 때문에 서버가 요구를 이해할 수 없다. 클라이언트는 변경 없이 요구를 반복해서
는 안 된다.

10.4.2 401 Unauthorized (인증되지 않았음)

응답이 사용자 인증을 요구한다. 이 응답은 요구된 자원에 적용할 수 있는 설명 요구
(challenge)를 포함하고 있는 WWW-Authenticate 헤더 필드(14.46 절)를 포함하고 있어야 한다.
클라이언트는 적절한 Authorization 헤더 필드(14.8 절)를 가지고 요구를 반복할 수 있다. 요구
가 벌써 Authorization 증명서를 포함하고 있다면 401 응답은 해당 증명서에 대한 인증이 거절
되었음을 표시한다. 401 응답이 이전 응답과 동일한 설명 요구를 포함하고 있고 사용자 에이전
트가 한 번 이상 인증 획득을 시도했다면 해당 엔터티가 관련된 진단 정보를 포함하고 있기
때문에 사용자에게 응답에 표시된 엔터티를 표시해주야 한다. HTTP 접속 인증은 11 장에 설명
되어 있다.

이 코드는 향후 사용을 위해 예약되었다.

10.4.4 403 Forbidden(금지되었음)

서버가 요구를 이해했으나 완료하는 것을 거절하고 있다. 인증은 적용되지 않으며 요구를 반
복될 수 없다. 요구 method가 HEAD가 아니고 서버가 왜 요구가 완료되었는지 알리고 싶다면
엔터티 안에 거절한 이유를 기록해야 한다. 이 상태 코드는 서버가 요구가 거부 사유를 밝히
기 원하지 않을 때나 다른 응답을 적용할 수 없을 때 일반적으로 사용된다.

10.4.5 404 Not Found(찾을 수 없음)

서버가 Request-URI와 일치하는 것을 아무것도 발견하지 못했다. 이러한 상태가 잠정적인지
영구적인지 관한 아무런 표시도 주어지지 안는다.

[Page 60]

서버가 이 정보를 클라이언트에게 알리고 싶지 않을 경우 상태 코드 403(Forbidden)을 대신 사
용할 수 있다. 내부적으로 환경을 설정할 수 있는 메커니즘을 통하여 이전의 자원을 영구적으
로 사용할 수 없으며 전송 주소가 없다는 것을 알 수 있으면 410(Gone) 상태 코드를 사용한다.

10.4.6 405 Method Not Allowed(Method를 사용할 수 없음)

Request-Line에 명시된 method를 Request-URI로 확인할 수 있는 자원에서 사용할 수 없다. 응
답은 요구된 자원에 사용할 수 있는 method의 목록을 포함한 Allow 헤더를 포함해야 한다.

10.4.7 406 Not Acceptable(접수할 수 없음)

요구가 확인한 자원이 요구 메시지와 함께 발송된 Accept 헤더에 의해서 접수할 수 없는 내용
특징을 가지고 있는 응답 엔터티만을 생성할 수 있다.

HEAD 요구가 아닌 이상 응답은 사용자 또는 사용자 에이전트가 가장 적합한 것을 선택할 수
있는 자원 특징 및 위의 목록을 포함한 엔터티를 포함한다. 엔터티 포맷은 Content-Type 헤더
필드가 설정한 media type에 의해 명시된다. 사용자 에이전트의 포맷 및 성능에 따라 가장 적
합한 선택을 결정하는 것은 자동으로 수행될 수 있다. 그러나 이 규격은 그러한 자동 선택의
표준에 대하여 아무런 규정도 하지 않는다.

주의 : HTTP/1.1 서버는 요구 메시지와 함께 발송된 Accept 헤더에 의해서 접수할 수 없는
응답을 리턴할 수 있게 한다. 어떤 경우엔 이것이 406 응답을 발송하는 것보다 좋을 수도
있다. 사용자 에이전트는 도착하는 응답의 헤더를 검사하여 그것의 접수 여부를 결정하도록
추천한다. 응답을 접수할 수 없을 때 사용자 에이전트는 잠정적으로 더 이상의 데이터를 수
신하지 말아야 하며 추가 행동을 취할 것인지 사용자에게 질의한다.
    
10.4.8 407 Proxy Authentication Required(프락시 인증 필요)

이 코드는 401(Unauthorized)과 유사하지만 클라이언트는 먼저 프락시에서 자기 자신을 인증해
야 한다는 것을 표시한다. 프락시는 요구된 자원의 프락시에 적용할 수 있는 설명 요구를 포
함하는 Proxy-Authenticate 헤더 필드(14.33 절)를 리턴해야 한다. 클라이언트는 적절한 Proxy-
Authorization 헤더 필드(14.34 절)와 함께 요구를 반복해야 한다. HTTP 접속 인증 획득에 대해
서는 11 장에 설명되어 있다.
  
[Page 61]

10.4.9 408 Request Timeout(요구 시간 초과)

클라이언트가 서버가 기다리도록 준비한 시간 내에 요구를 만들어 낼 수 없다. 클라이언트는
나중에 변경 없이 요구를 반복할 수 있다.

10.4.10 409 Conflict(충돌)

자원의 현재 상태와의 충돌 때문에 요구를 완료할 수 없다. 이 코드는 사용자가 충돌을 해결
하고 요구를 재전송할 수 있을 것으로 기대할 수 있는 상황에서만 사용할 수 있다. 응답 본문
은 사용자가 충돌의 원인을 인지할 수 있도록 충분한 정보를 포함해야 한다. 이상적으로는 응
답 엔터티가 사용자 또는 사용자 에이전트가 문제를 해결할 수 있을 정도의 충분한 정보를 포
함할 수 있을 것이다. 그러나 가능하지 않을 수도 있으며 필수 사항은 아니다.

충동은 PUT 요구에 대한 응답으로 발생할 가능성이 높다. 버전 관리를 사용하고 있고 PUT 요
구를 하는 엔터티가 이전 요구(제 3 자)가 작성한 요구와 충돌되는 자원에 대한 변경 사항을
포함하고 있다면 서버는 409 응답을 사용하여 요구를 완료할 수 없음을 표시해야 한다. 이 경
우 응답 엔터티는 응답 Content-Type이 규정한 형식으로 두 버전 사이의 차이점 목록을 포함
해야 한다.

10.4.11 410 Gone (내용물이 사라졌음)

요구된 자원이 서버에 더 이상 존재하지 않으며 전송 주소를 알 수 없다. 이 조건은 영구적인
것으로 간주해야 한다. 링크를 편집할 기능이 있는 클라이언트는 사용자 인증 후의 Request-
URI에 대한 참고는 삭제해야 한다. 서버가 그 조건이 영구적인지 여부를 알 수 없거나 결정
할 시설이 없으면 상태 코드 401(Unauthorized)을 대신 사용해야 한다. 다르게 표시되지 않는
한 이 응답은 캐시할 수 있다.

410 응답은 주로 수신측에게 자원을 의도적으로 사용할 수 없게 하였고 서버의 소유주가 해당
자원에 대한 원격 링크를 제거하고자 한다는 것을 알림으로써 웹 유지 작업을 지원하기 위해
사용된다. 이러한 일은 제한된 시간, 선전용 서비스 및 서버의 사이트에서 더 이상 일하지 않
는 개인에게 소속된 자원에서 공통적으로 발생할 수 있다. 영구적으로 사용할 수 없는 모든
자원을 "사라진" 것으로 표시하거나 특정 시간 동안 표시를 유지할 필요는 없다. - 이것은 서
버 소유자의 판단에 달려 있다.

[Page 62]

10.4.12 411 Length Required(길이가 필요함)

서버가 규정된 Content-Length 없는 요구 접수를 거부하였다. 요구 메시지 내의 Message-Body
의 길이를 포함하는 유효한 Content-Length 헤더 필드를 추가한다면 클라이언트는 요구를 반복
할 수 있다.

10.4.13 412 Precondition Failed(사전 조건 충족 실패)

하나 또는 그 이상의 Request-Header 필드에 기입된 사전 조건이 서버에서 테스트 했을 때 거
짓으로 평가되었다. 이 응답 코드는 클라이언트가 현재 자원의 메타 정보에 사전 조건을 부여
할 수 있게 하여 의도하지 않는 자원에 요구 method를 적용하는 것을 방지한다.

10.4.14 413 Request Entity Too Large(요구 엔터티가 너무 큼)

요구 엔터티가 서버가 처리할 수 있거나 처리하려는 것보다 크기 때문에 서버가 요구 처리를
거부하였다. 서버는 클라이언트가 계속적으로 요구하는 것을 방지하기 위하여 연결을 종료한
다.

조건이 잠정적이면 서버는 Retry-After 헤더 필드를 포함하여 조건이 잠정적이며 얼마 후에 클
라이언트가 재시도할 것인지를 표시한다.

10.4.15 414 Request-URI Too Long(Request -URI가 너무 김)

Request-URI가 서버가 해석할 수 있는 것보다 크기 때문에 서버가 요구 처리를 거부하였다.
이처럼 드문 조건은 클라이언트가 부적절하게 질의 정보가 긴 POST 요구를 GET 요구로 변환
했을 때, 클라이언트가 방향 재설정의 URL "블랙 홀"로 빠졌을 때(방향이 재설정된 URL 접두
사가 자신의 접미사를 지칭할 때), Request-URI를 읽거나 조작하는 고정-길이 버퍼를 사용하는
몇몇 서버에 존재하는 보안의 허점을 이용하려는 클라이언트로부터 서버가 공격을 받을 때만
발생하는 것 같다.

10.4.16 415 Unsupported Media Type(지원되지 않는 media type)

요구의 엔터티가 요구 받은 method의 자원이 지원하지 않는 포맷으로 구성되어 있기 때문에
요구 처리를 거부하였다.

[Page 63]

10.5 Server Error 5xx(서버 에러 5xx)

숫자 "5"로 시작하는 응답 상태 코드는 서버가 에러를 발생시켰으며 요구를 처리할 능력이 없
음을 인지한 경우를 표시한다. HEAD 요구에 응답하는 때를 제외하고는 서버는 에러 상황에
대한 설명 및 에러가 잠정적인지 영구적인지에 관한 상황 설명을 포함하는 엔터티를 포함해야
한다. 사용자 에이전트는 포함된 모든 엔터티를 사용자에게 표시하여야 한다. 이러한 응답 코
드는 모든 요구 method에 적용할 수 있다.

10.5.1 500 Internal Server Error(서버 내부 에러)

서버가 요구를 처리하지 못하도록 하는 예상치 못한 상황에 접했다.

10.5.2 501 Not Implemented(구현되지 않았음)

서버가 요구를 완료하는 데 필요한 기능을 지원하지 않는다. 이것은 서버가 요구 method를 인
지할 수 없고 어떠한 자원을 사용해도 지원할 수 없을 때 적절한 응답이다.

10.5.3 502 Bad Gateway(불량 게이트웨이)

게이트웨이나 프락시 역할을 수행하는 서버가 요구를 완료하려는 시도에서 접근한 업스트림
(upstream) 서버로부터 유효하지 않은 응답을 수신했을 경우이다.

10.5.4 503 Service Unavailable(서비스를 사용할 수 없음)

서버가 현재 잠정적인 오버로딩(overloading)이나 서버의 유지 작업 때문에 요구를 처리할 수
없다. 이것의 의미는 이것이 잠정적인 상황이며 얼마 후에는 완화될 수 있다는 것이다. 알 수
있다면 지연 시간 길이를 Retry-After 헤더에 표시할 수 있다. 아무런 Retry-After 정보가 없으
면 클라이언트는 500 응답을 처리하는 것처럼 응답을 처리해야 한다.

주의 : 503 상태 코드가 있다는 것이 서버가 오버로드 되었을 때 이것을 반드시 사용해야 된
다는 것을 의미하지 않는다. 어떤 서버는 단순히 접속을 거부하고자 한다.

10.5.5 504 Gateway Timeout(게이트웨이 시간 초과)

게이트웨이나 프락시 역할을 수행하는 서버가 시간 내에 요구를 완료하려는 시도에서 접근한
업스트림(upstream) 서버로부터 응답을 수신하지 못했을 경우이다.

[Page 64]

10.5.6 505 HTTP Version Not Supported(지원되지 않는 HTTP 버전)

서버가 요구 메시지에서 사용된 HTTP 규약 버전을 지원하지 않거나 지원하기를 거부했다. 서
버는 이 에러 메시지 이외에는 3.1 절에서 설명한 대로 클라이언트가 사용하는 동일한 주요
버전을 사용하여 요구를 완료할 의사나 능력이 없음을 표시한다. 응답은 왜 해당 버전이 지원
되지 않으며 서버가 어떤 규약을 지원하는가를 설명하는 엔터티를 포함해야 한다.

11 접속 인증

HTTP는 서버는 클라이언트의 요구를 시도하고 클라이언트는 인증 정보를 제공하는 단순한
Try-Response 인증 획득 메커니즘을 제공한다. 이것은 확장 가능하고 대소문자를 구별하지 않
는 토큰을 사용하여 인증 scheme을 확인한다. 이 scheme 뒤에는 이 scheme을 통하여 인증을
획득하는 데 필요한 파라미터를 가지고 있는 콤마로 구분된 attribute-value 쌍의 목록이 뒤따른
다.

          auth-scheme     = token

          auth-param      = token "=" quoted-string

원서버는 401(Unauthorized) 응답 메시지를 사용하여 사용자 에이전트의 인증을 시도한다. 이
응답은 요구된 자원에 적용할 수 있는 최소한 하나의 시도를 포함한 WWW-Authenticate 헤더
필드를 포함해야 한다.

          challenge       = auth-scheme 1*SP realm *( "," auth-param )

          realm           = "realm" "=" realm-value
          realm-value     = quoted-string

인증을 시도하는 모든 인증 scheme은 영역 속성(대소문자를 구별하지 않음)을 가지고 있어야
한다. 영역 속성(대소문자를 구별함)은 접속하려는 서버의 정형적 루트 URL (5.1.2 절 참조)과
결합하여 보호 구역(protection space)을 정의한다. 이 영역은 서버의 보호된 자원이 각각 자신의
인증 획득 scheme 및/또는 인증 데이터 베이스를 가지고 보호 구역 세트로 분할될 수 있도록
한다. 영역 값은 문자열이며 보통 원서버가 지정한다. 원서버는 인증 획득 scheme에 한정된
추가적인 의미를 가질 수 있다.

서버에 자신의 인증을 얻고자 하는 사용자 에이전트는 - 대개의 경우 필수적인 사항은 아니지
만 401 또는 411 응답을 수신한 후 -요구에 Authorization 헤더 필드를 포함하여 인증을 얻을
수 있다. Authorization 필드 값은 요구하고 있는 자원의 영역에 대한 사용자 에이전트의 인증
획득 정보를 포함하고 있는 인증 증명서로 구성되어 있다.

 [Page 65]

          credentials    = basic-credentials
                         | auth-scheme #auth-param

사용자 에이전트에 의해 증명서가 자동적으로 적용될 수 있는 도메인(domain)은 보호 구역에
의하여 결정된다. 이전의 요구가 인가되었으면 인증 획득 scheme, 파라미터 및/또는 사용자의
선호에 따라 결정되는 기간 동안 해당 보호 구역 내에서는 동일한 증명서를 재사용할 수 있다.
인증 획득 scheme에 의해 다르게 규정되지 않는 한 단일 보호 구역은 서버의 범위를 넘어서
확장될 수 없다.

요구

서버가 요구와 함께 수신한 증명서를 접수하고 싶지 않으면 서버는 401(Unauthorized) 응답을
리턴해야 한다. 응답은 요구된 자원 및 거절 이유를 설명하는 엔터티에 적용할 수 있는 시도
(재시도일 수도 있다)를 포함한 WWW-Authenticate 헤더 필드를 반드시 포함해야 한다.

HTTP 규약은 접속 인증 획득을 위해 이 단순한 Try-Response 메커니즘만을 애플리케이션이
사용하도록 제한하지는 않는다. 전송 수준 또는 메시지 내포화(encapsulation)를 통한 암호화 등
과 같은 추가적인 메커니즘을 인증 획득 정보를 명시하는 추가적인 헤더 필드와 더불어 사용
할 수 있다.

프락시는 반드시 사용자 에이전트 인증 획득에 관하여 완전히 투명해야 한다. 말하자면 프락
시는 반드시 WWW-Authenticate 및 Authorization 헤더를 변경하지 않고 전송해야 하며 14.8 절
에 있는 규칙에 따라야 한다.

HTTP/1.1은 클라이언트가 인증 획득 정보를 Proxy-Authenticate 및 Proxy-Authorization 헤더를
통하여 프락시와 주고 받을 수 있도록 허용해야 한다.

11.1 기본 인증 scheme

"기본적(basic)" 인증 scheme은 사용자 에이전트가 각 영역에서 사용자 ID 및 암호로서 자신의
인증을 획득해야 한다는 모델에 기초하고 있다. 영역 값은 동일 서버의 다른 영역과의 동일성
이 비교될 수 있는 불투명한 문자열로 간주해야 한다. 서버는 Request-URI의 보호 구역에서
사용자 ID와 암호를 검증할 수 있을 때만 요구를 청할 것이다. 선택적인 인증 획득 파라미터
는 없다.

[Page 66]

보호 구역 내의 URI에 대한 허가되지 않는 요구를 수신하면 서버는 다음과 같은 시도로 응답
할 수 있다.

          WWW-Authenticate: Basic realm="WallyWorld"

여기서 "WallyWorld"는 서버가 지정한 문자열로 Request-URI의 보호 구역을 확인해 준다.

인증 획득을 수신하기 위해서 클라이언트는 증명서 내의 base64로 인코딩된 문자열 내에서 단
일 콜론(":") 문자로 구분된 사용자 ID 와 암호를 발송한다.

          basic-credentials = "Basic" SP basic-cookie

          basic-cookie    =                            라인 당 76 문자에 제한을 받지 않을 경우>

          user-pass      = userid ":" password

          userid        = *

          password      = *TEXT

Userids 는 대소문자를 구별할 수도 있다.

사용자 에이전트가 userid "Aladdin" 과 암호 "open sesame"를 송신하고 싶다면 다음의 헤더 필
드를 사용해야 할 것이다:

          Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

기본 인증 획득과 관련된 보안에 대한 고려 사항은 15 장을 참고한다.

11.2 요약 인증 scheme

HTTP의 요약 인증 scheme은 RFC 2069 [32]에 명시되어 있다.

12 내용 협상(Content Negotiation)

대부분의 응답은 인간 사용자가 해석하는 정보를 포함한 엔터티를 포함하고 있다. 당연히 사
용자에게 요구에 상응하는 "최상의 사용 가능" 엔터티를 제공하는 것이 바람직하다. 서버와
캐시에게는 불행하게도 모든 사용자가 무엇이 최상인가에 대한 동일한 선호 사항을 가지고 있
는 것이 아니며 모든 사용자 에이전트가 평등하게 모든 엔터티 유형을 표시할 능력이 있는 것
이 아니다. 이러한 이유로 HTTP는 "내용 협상"을 위한 몇몇 메커니즘을 제공하고 있다.
[Page 67]

내용 협상이란 복수의 표현 방법을 사용할 수 있을 때 특정 응답에 대한 최상의 표현 방법을
선택하는 과정이다.

주의 : 대체하는 표시 방법이 동일한 media type이고 동일 유형의 다른 능력을 사용하거나
다른 언어로 되어 있을 수 있기 때문에 "포맷 협상" 이라고 부르지 않는다.

에러 응답을 포함하여 Entity-Body를 가지고 있는 모든 응답은 협상의 대상이 될 수 있다.

HTTP에서 사용할 수 있는 두 가지 종류의 내용 협상이 있다 - 서버가 주도하는 협상과 에이
전트가 주도하는 협상. 이 두 종류의 협상은 직교하기 때문에 분리하여 사용할 수도 있고 결
합하여 사용할 수도 있다. 투명한 협상으로 지칭되는 결합의 한 방법은 직후의 요구에 대하여
서버가 주도하는 협상을 제공하기 위해서 캐시가 원서버가 제공하는 에이전트 주도의 협상 정
보를 사용할 때 발생한다.

12.1 서버가 주도하는 협상

응답에 대한 최상의 표현 방식 선택이 서버에 위치한 알고리즘에 의하여 이루어 질 때 이를
서버가 주도하는 협상이라 부른다. 선택은 사용 가능한 응답 표시 방법(변형할 수 있는 차원.
예를 들어 언어 Content-Codings 등), 요구 메시지의 특정 헤더 필드의 내용 또는 요구와 관련
된 기타 정보(클라이언트의 네트워크 주소 같은 것)에 기초한다.

서버가 주도하는 협상은 사용 가능한 표현 방법 중에서 선택하는 알고리즘이 사용자 에이전트
에게 설명하기가 어려울 때 또는 서버가 자신의 "최상의 예측"을 첫 응답에 뒤 따라서("최상
의 예측"이 사용자에게 충분할 정도로 좋다면 계속되는 요구의 왕복 여행으로 인한 지연을 피
하려는 희망에서) 클라이언트에게 발송할 때 유리하다. 서버의 예측을 향상시키기 위해 사용
자 에이전트는 그러한 응답에 대한 자신의 선호를 표시하는 요구 헤더 필드(Accept, Accept-
Language, Accept-Encoding 등)를 포함할 수도 있다.

서버가 주도하는 협상은 다음의 단점이 있다.

1.  서버가 정확하게 특정 사용자에게 "최상"이 무엇인지 결정한다는 것은 사용자 에이전트의
능력 및 응답의 의도된 사용 용도에 대한 완벽한 이해를 필요로 하기 때문에 불가능하다.
(예를 들면 사용자가 그것을 화면에서 보기를 원하는가 아니면 종이에 인쇄하기를 원하는
가?)
 
2.  사용자 에이전트에게 요청할 때마다 자신의 능력을 설명하도록 하는 것은 매우 비효율적
(적의 퍼센트의 응답만이 복수의 표현 방법을 가지고 있다고 가정하면)이면서도 사용자의
프라이버시를 침해할 가능성이 있다.
[Page 68]

 
3.  원서버의 구현 방법 및 요구에 대한 응답을 생성하는 알고리즘을 복잡하게 만든다.
 
4.  복수의 사용자 요구에 대해 동일한 응답을 사용할 수 있는 보편적인 캐시의 능력을 제한
할 수 있다.

HTTP/1.1은 사용자 에이전트의 능력 및 사용자의 선호를 기술하여 서버가 주도하는 협상을
가능하게 하는 다음의 Request-Header 필드를 포함하고 있다. -  Accept (14.1 절), Accept-Charset
(14.2 절), Accept-Encoding (14.3 절), Accept-Language (14.4 절) 및User-Agent (14.42 절). 그러나
원서버는 이러한 차원에 제한 받지 않고 Request-Header 필드 이외의 정보 또는 이 규격이 규
정하지 않은 확장 헤더 필드를 포함하는 요구의 어떠한 측면에 따라 변형될 수 있다.

HTTP/1.1 원서버는 서버가 주도하는 협상에 기초한 캐시할 수 있는 모든 응답에서 반드시 적
절한 Vary 헤더 필드(14.43 절)를 포함해야 한다. Vary 헤더 필드는 응답이 변형될 수 있는 차
원을 설명한다. (예를 들어 원서버가 복수의 표현 방식으로부터 "최상의 예측"을 끄집어 낼 수
있는 차원)

HTTP/1.1 공공 캐시는 응답에 포함되어 있는 Vary 헤더 필드를 인지해야 하고 캐시와 내용 협
상의 상호 작용을 기술하고 있는 13.6 절에 설명된 필요 조건을 충족해야 한다.

12.2 에이전트가 주도하는 협상

에이전트가 주도하는 협상에서 응답에 대한 최상의 표현 방식의 선택은 원서버로부터 첫 응답
을 수신한 다음 사용자 에이전트가 수행한다. 선택은 각각의 표현 방식은 자신의 URI에 의하
여 식별하면서 헤더 필드(이 규격은 부록 19.6.2.1에 기술한 대로 필드 이름 Alternates를 예약
했다.) 내에 포함되어 있는 사용 가능한 표현 방식의 목록이나 첫 응답의 Entity-Body에 기초
한다. 표현 방식 선택은 자동적으로 수행(사용자 에이전트가 그렇게 할 능력이 있다면)될 수도
있고 사용자가 생성된(하이퍼텍스트일 수 있다) 메뉴에서 선택할 수도 있다.

에이전트가 주도하는 협상은 응답이 일반적으로 사용하는 차원(유형, 언어 또는 인코딩)에 따
라 변할 때, 원서버가 응답을 관찰하여 사용자 에이전트의 능력을 결정할 수 없을 때 또는 서
버의 부하를 분산하고 네트워크 사용을 감소시키기 위해 공공 캐시가 사용되었을 때 유리하다.

[Page 69]

에이전트가 주도하는 협상은 최적의 대체 표시 방법을 얻기 위해서 두 번째 요구가 필요하다
는 단점이 있다. 이 두 번째 요구는 캐시가 사용될 때만 효과적이다. 또한 이 규격은 자동적
선택을 지원하는 어떠한 메커니즘도 규정하지 않는다. 그러나 이 규격은 또한 이러한 메커니
즘이 확장으로서 개발되고 HTTP/1.1 내에서 사용되는 것을 금지하지는 않는다.

HTTP/1.1은 서버가 주도하는 협상을 이용하는 변화된 응답을 제공할 수 없거나 제공하려 하
지 않을 때 에이전트가 주도하는 협상이 가능하도록 300 (Multiple Choices) 및 406 (Not
Acceptable) 상태 코드를 규정한다.

12.3 투명한 협상(Transparent Negotiation)

투명한 협상은 서버가 주도하는 협상과 에이전트가 주도하는 협상의 복합체이다. 캐시가 응답
의 사용 가능한 표현 방식 목록 형태로 제공되고(에이전트가 주도하는 협상처럼) 캐시가 변이
의 차원을 완전히 이해했으면 해당 자원에 대한 계속적인 요구에 대하여 원서버를 대신하여
캐시는 서버가 주도하는 협상을 수행할 수 있게 된다.

투명한 협상은 그렇지 않다면 원서버가 수행해야 하는 협상 작업을 분산할 수 있고 캐시가 정
확하게 올바른 응답을 예측할 수 있을 때 에이전트가 주도하는 협상의 두 번째 요구 지연을
제거할 수 있다는 장점을 가지고 있다.

이 규격은 투명한 협상에 대한 어떠한 메커니즘도 규정하지 않는다. 그러나 이 규격은 또한
이러한 메커니즘이 확장으로서 개발되고 HTTP/1.1 내에서 사용되는 것을 금지하지는 않는다.
투명한 협상을 수행하는 HTTP/1.1 캐시는 HTTP/1.1과의 올바른 상호 작용을 확보하기 위하여
캐시할 수 있다면 반드시 응답(변이의 차원을 정의)에 Vary 헤더 필드를 포함해야 한다. 원서
버가 제공하는 에이전트가 주도하는 협상에 대한 정보는 투명하게 협상된 응답에 포함되어야
한다.

13 HTTP에서의 캐시

HTTP는 전형적으로 응답 캐시를 사용하여 성능을 향상시킬 수 있는 분산 정보 시스템에서
사용된다. HTTP/1.1 규약은 캐시 작업을 가능한 한 잘 수행하기 위한 몇몇 요소를 포함한다.
이러한 요소는 규약의 다른 측면에서 제외할 수 없는 것이기 때문에 또한 서로 상호 작용을
하기 때문에 method, 헤더, 응답 코드 등에 대한 자세한 설명과는 별도로 HTTP의 기본 캐시
디자인을 설명하는 것이 유용하다.

[Page 70]

성능을 상당히 개선하지 못한다면 캐시는 쓸모없는 것이 될 것이다. HTTP/1.1 캐시의 목적은
많은 경우에 요구를 발송할 필요를 제거하고 또 다른 많은 경우에 완전한 응답을 발송할 필요
를 제거하는 것이다. 전자는 많은 운영에서 네트워크의 왕복 여행 숫자를 줄여 준다. 우리는
이 목적을 위해서 "만기일" 메커니즘을 사용한다. (13.2 절 참조). 후자는 네트워크 대역폭 요
구를 감소시켜 준다. 우리는 이 목적을 위해서는 "검증" 메커니즘을 사용한다.( 13.3 절 참조)

성능, 가용성 및 단절된 운영에 대한 필요 조건이 우리에게 의미 투명성(semantic transparency)
의 목적을 완화할 수 있도록 요구한다. HTTP/1.1 규약은 원서버, 캐시, 클라이언트가 필요하다
면 분명하게 투명성을 감소할 수 있도록 한다. 그러나 비-투명적 작업은 비 전문가 사용자에
게 혼선을 줄 수 있고, 특정 서버 애플리케이션과 호환되지 않을 수 있기 때문에(제품 주문을
위한 애플리케이션처럼) 규약은 투명성을 완화시킬 것을 요구한다.

? 클라이언트나 원서버에 의해 완화되었을 때는 분명하게 규약 수준의 요구에 의해서만
? 캐시나 클라이언트에 의해 완화되었을 때는 사용자에게 분명한 경고를 줌으로써

[Page 71]

따라서 HTTP/1.1 규약은 다음의 중요한 요소를 제공한다.

1.  모든 참가자가 요구할 때 완전한 의미 투명성을 제공하는 규약 기능
 
2.  원서버나 사용자 에이전트가 비 투명적 작업을 분명하게 요청하고 제어할 수 있도록 하는
규약 기능
 
3.  캐시가 요구한 의미 투명성에 대한 근접 요구를 유지할 수 없는 응답에 경고를 첨부하는
규약 기능

기본 규칙은 클라이언트가 잠재적인 의미 투명성의 완화를 감지할 수 있어야 한다는 것이다.

주의 : 서버, 캐시 또는 클라이언트 구현자는 이 규격에서 분명하게 토의되지 않은 디자인을
결정해야 하는 문제에 직면하게 된다.  결정 사항이 의미 투명성에 영향을 미치게 되면 구
현자는 주의 깊고 완전한 분석이 투명성을 어김으로써 상당한 혜택을 주는 것으로 나타나지
않는 한 투명성을 유지하는 데 치우쳐야 한다.

13.1.1 캐시의 정확성

정확한 캐시는 반드시 아래의 조건 중 하나를 만족하며 요구에 적합한(13.2.5, 13.2.6 및 13.12
절 참조) 보유하고 있는 캐시 중 가장 최근의 응답으로 요구에 답해야 한다.

1.  원서버가 원서버를 사용하여 응답을 재검증한 후 되돌려 주었을 것과 같은 것인지 점검하
였다.( 13.3 절)
 
2.  충분히 신선하다.( 13.2 절 참조). 기본적인 경우 이것은 클라이언트, 서버 및 캐시의 최소
한도의 신선도 필요 조건을 만족한다는 것을 의미한다.(14.9 절 참조). 원서버가 그렇게 명
시하였으면 그것은 원서버의 신선도 필요 조건일 뿐이다.
 
3.  클라이언트 또는 서버의 신선도 요구가 위반되었을 경우(13.1.5 또는 14.45 절 참조) 경고
를 포함하고 있다.
 
4.  적절한 304 (Not Modified), 305 (Use Proxy), 또는 error (4xx or 5xx) 응답 메시지이다.

캐시가 원서버와 통신할 수 없다면 정확한 캐시는 위처럼 응답해야 한다.(캐시가 정확한 응답
을 할 수 있다면). 그렇지 못하면 캐시는 통신 실패가 있었음을 알리는 에러 또는 경고를 리
턴해야 한다.

[Page 72]

캐시가 보통 클라이언트로 전달하게 되는 응답을 수신하고(전체 응답 혹은 304(Not Modified)응
답) 수신한 응답이 더 이상 신선하지 않으면 캐시는 응답을 새로운 Warning(그러나 기존의
Warning헤더는 제거하지 않고)을 추가하지 않고 요구한 클라이언트로 전달한다. 캐시는 응답
이 그 동안 낡은 것이 되기 때문에 검증하려 시도해서는 안 된다. 시도하면 무한 루프로 빠지
게 될 것이다. Warning 없는 낡은 응답을 수신한 사용자 에이전트는 사용자에게 경고 표시를
할 수 있다.

13.1.2 경고

캐시가 처음이 아니거나 "충분히 신선하지"( 13.1.1 절의 조건 2의 의미) 않은 응답을 리턴할
때는 Warning Response-Header을 이용하여 이러한 취지로 경고를 부착하여야 한다. 이 경고는
클라이언트가 적절한 조치를 취할 수 있도록 한다.

경고는 캐시와 관련되거나 별도의 다른 목적을 위해 사용할 수 있다. 에러 상태 코드 대신 경
고를 사용하여 이 응답을 진짜 실패와 구별할 수 있게 한다.

경고는 응답의 투명성을 결코 약하게 하지 않기 때문에 언제나 캐시할 수 있다. 이는 경고를
HTTP/1.0에게 위험 없이 전달할 수 있음을 의미한다. 이러한 캐시는 단순히 경고를 응답의
Entity-Head헤드와 함께 전달한다.

경고는 0부터 99까지의 숫자로 지정한다. 이 규격은 코드 숫자와 현재 각각에 지정된 경고의
의미를 규정하여 클라이언트 또는 캐시가 몇몇 경우(모든 경우는 아니다.) 자동화된 조치를 취
할 수 있게 한다.

경고는 또한 경고문을 수반한다. 경고문은 적당한 자연 언어(아마도 클라이언트의 Accept 헤더
에 기초하여)로 작성될 수 있으며 선택적으로 사용된 문자 집합 표시를 포함할 수 있다.

동일한 코드 번호의 복수의 경고를 포함하는 복수의 경고가 응답에 부착될 수 있다.(원서버나
캐시에 의해서). 예를 들어 서버는 동일한 경고를 영어와 바스크어로 된 경고문으로 제공할
수 있다.

복수의 경고가 응답에 부착되었을 때 이 모두를 사용자에게 보여 주는 것은 실질적이지 않거
나 비합리적일 수 있다. 이 HTTP 버전은 어떤 경고를 어떤 순서에 입각하여 표시할 것인지
결정하는 엄격한 우선권 규칙은 명시하지 않지만 약간의 발견법(heuristics)을 제안하기는 한다.

[Page 73]

Warning 헤더와 현재 정의된 경고는 14.45 절에 기술되어 있다.

13.1.3 Cache-Control 메커니즘

HTTP/1.1의 기본적인 캐시 메커니즘(서버가 명시한 유효 시간 및 검증자)은 캐시에 내재된 지
시를 하는 것이다. 어떤 경우에 서버나 클라이언트는 내재된 지시자를 HTTP 캐시에게 제공할
필요가 있다. 우리는 Cache-Control 헤더를 이 목적으로 사용한다.

Cache-Control 헤더는 클라이언트나 서버가 요구나 응답의 다양한 지시자를 전달할 수 있도록
한다. 이 지시자는 대개의 경우 기본 캐시 알고리즘을 무시한다. 보편적인 원칙으로 만약 헤더
값 사이에 분명한 충돌이 있으면 가장 엄격한 해석을 사용해야 한다.(말하자면 의미 투명성을
가장 잘 보존할 수 있는 것). 그러나 어떤 경우에는 Cache-Control 지시자가 분명하게 의미 투
명성의 근사치를 약화시키는 것으로 명시할 수 있다.(예를 들어 "max-stale" 또는 "public"

Cache-Control 지시자는 14.9 절에 자세하게 기술되어 있다.

13.1.4 명백한 사용자 에이전트 경고

많은 사용자 에이전트는 사용자가 기본적인 캐시 메커니즘을 무시할 수 있도록 한다. 예를 들
어 사용자 에이전트는 사용자가 캐시 된 엔터티(분명하게 낡은 캐시까지도)를 결코 검증하지
말도록 명시하는 것을 허락한다. 또는 사용자 에이전트가 습관적으로 "Cache-Control: max-
stale=3600" 을 모든 요구 내에 첨가할 수도 있다. 사용자는 투명하지 않는 방식이나 비정상적
으로 비효과적인 캐시를 초래하는 방식을 확실하게 요구해야 한다.

사용자가 기본적인 캐시 메커니즘을 무시했다면 이것이 서버의 투명성 필요 조건을 만족시켜
주지 못할 정보 표시를 초래하게 될 때 사용자 에이전트는 항상 사용자에게 분명하게 표시해
주어야 한다. 보통 규약은 사용자 에이전트가 응답이 낡은 것인지 아닌지 여부를 결정할 수
있도록 하기 때문에 실제로 발생했을 경우에는 이것을 화면에 표시할 필요가 있다. 이 표시는
반드시 대화 박스일 필요는 없고 아이콘(예를 들어 부패된 생선 그림)이나 다른 시각적 표시
자일 수도 있다.

사용자가 캐시의 효과성을 비정상적으로 감소시키는 방식으로 캐시 메커니즘을 무시했다면 사
용자 에이전트는 계속해서 화면에 이를 표시(예를 들어 불타는 지폐 그림)하여 사용자가 부주
의하게 과도한 자원을 낭비하거나 지나치게 기다리지 않도록 해야 한다.

[Page 74]

13.1.5 규칙 및 경고의 예외 사항

어떤 경우에는 캐시 운영자는 클라이언트가 요구하지 않았어도 낡은 응답을 리턴하도록 환경
을 설정할 수 있다. 이러한 결정은 가볍게 해서는 안되지만 가용성이나 성능 특히 캐시가 원
서버와 약하게 연결되어 있을 때는 필요할 수도 있다. 캐시가 낡은 응답을 리턴할 때마다 이
러한 상태를 표시해야 한다.(Warning 헤더를 이용하여). 이렇게 하여 클라이언트 소프트웨어가
사용자에게 문제가 발생할 소지가 있음을 경고할 수 있도록 한다.

또한 사용자 에이전트가 처음 또는 새로운 응답을 얻는 조치를 취할 수 있도록 한다. 이러한
이유로 캐시는 클라이언트가 분명하게 처음 또는 새로운 캐시를 요구하면 기술적인 이유나 정
책적인 이유에 따르는 것이 불가능하지 않는 한 낡은 응답을 리턴해서는 안 되는 것이다.

13.1.6 클라이언트가 제어하는 행태

원서버(최소한 응답의 시간 경과에 공헌한 것을 감안하여 중간 캐시)가 만기일 정보의 주요
소스일 때 어떤 경우에는 클라이언트가 검증 없이 캐시 된 응답을 리턴할 것인지 여부에 대한
결정을 제어할 필요가 있다. 클라이언트는 몇몇 Cache-Control 헤더 지시자를 사용하여 이를
수행한다.

클라이언트의 요구는 검증되지 않은 응답을 접수할 수 있는 최대한의 경과시간을 명시한다.
이 값을 제로로 설정하면 캐시가 모든 응답을 재검증하도록 한다. 클라이언트는 응답이 만료
되기 전에 남아 있는 최소한의 시간을 명시한다. 이 두 선택 사항 모두 캐시의 행태에 대한
제한을 증대시키기 때문에 캐시의 의미 투명성 근사치를 추가로 완화시켜 주지는 못한다.

클라이언트는 또한 최대한 어떠한 수준까지의 낡은 응답을 접수할 것임을 명시할 수 있다. 이
것은 캐시에 대한 제한을 완화시켜 주기 때문에 원서버가 명시한 의미 투명성에 대한 제한 사
항을 위반할 수도 있지만 접속이 단절된 상태에서의 운용, 불량한 접속에 직면하여 높은 가용
성을 지원하기 위해 필요할 수도 있다.

13.2 만기일 모델

13.2.1 서버가 명시한 만기일

HTTP 캐시는 원서버로 요구를 발송하는 것을 완전히 피할 수 있을 때 최상으로 작동한다. 요
구를 피하는 주요 메커니즘은 원서버가 분명하게 해당 응답이 계속되는 요구를 만족시킬 수
있다는 것을 표시하는 미래의 만료 시간을 제공하는 것이다. 다른 말로 표현하면 캐시가 먼저
서버와 접촉하지 않고도 새로운 응답을 리턴할 수 있다는 것이다.

[Page 75]

우리가 기대하는 것은 서버가 만기일이 도착 전에 엔터티가 의미상으로 중대하게 변화하지 않
을 것이라는 믿음으로 미래의 분명한 만료 시간을 부여하는 것이다. 이렇게 하면 서버의 유효
시간이 신중하게 선택된 한 대개의 경우 의미 투명성을 보존한다.

유효일 메커니즘은 캐시에서 얻은 응답에만 적용되며 요구한 클라이언트에게 직접적으로 전달
되는 첫 응답에는 적용되지 않는다.

원서버가 모든 요구를 검증하기 위해 의미상으로 투명한 캐시를 요구한다면 과거 시점의 유효
시간을 부여할 수도 있다. 이는 응답이 항상 낡은 것이기 때문에 계속되는 요구에 이것을 사
용하기 위해서는 반드시 먼저 검증을 해야 한다는 것을 의미한다. 검증을 강제로 요구하는 제
한적인 방법에 관한 추가 정보는 14.9.4 절을 참조한다.

원서버가 HTTP/1.1 캐시가 모든 요구를 검증하도록 하려면 어떤 방식으로 환경이 설정되었든
"must-revalidate" Cache-Control 지시자(14.9 절 참조)를 사용해야 한다.

서버는 Expires 헤더 또는 Cache-Control 헤더의 max-age 지시자를 사용하여 분명하게 유효 시
간을 명시한다.

유효 시간은 사용자 에이전트가 자원을 화면에 표시하거나 갱신하도록 만드는 데 사용할 수
없다. 이 의미는 캐시 메커니즘에만 적용되며 이러한 메커니즘은 해당 자원에 대한 새로운 요
구가 시작되었을 때 자원의 유효일 상태만을 점검할 필요가 있다. 캐시와 history 메커니즘의
차이점에 대한 설명은 13.13 절을 참고한다.

13.2.2 스스로 유효일을 찾음(Heuristic Expiration)

원서버가 언제나 명백한 유효 시간을 제공하는 것이 아니므로 HTTP 캐시는 전형적으로 그럴
듯한 유효 시간을 짐작하기 위해 다른 헤더 값(Last-Modified 시간과 같은)을 사용하는 알고리
즘을 활용하는 발견법(heuristic) 유효 시간을 할당한다. HTTP/1.1 규격은 상세한 알고리즘을 제
공하지는 않지만 결과에 대한 최악의 경우 제한 사항을 부과하고 있다. 발견법에 의한 유효
시간은 의미 투명성 때문에 정확하지 않을 수도 있기 때문에 조심해서 사용해야 하며 우리는
원서버가 가능한 한 분명한 유효 시간을 제공하도록 권고한다.

[Page 76]