400
RST
は
Content-Length: に満たずに400
400 :、400
400 400
Server: Fujitsu-InfoProvider-Pro/V12L10 (UXP/DS) というサーバーは LF で出力します。 Mozilla や WinIE を含めた多くの まあ [HTTP92] でも改行は
1xx HEADERS PUSH_PROMISE PUSH_PROMISE CONTINUATION
CONTINUATION END_STREAM HEADERS
Content-Length
obs- obs-
application/http
message/http
message/* message/http
message/*
message/http TRACE
Request / Response
- message
- The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in
{1945] Sectionsection 4 and transmitted via the connection.
HTTP messages consist of requests from client to server and responses from server to client.
HTTP メッセージは顧客からサーバーへの要求とサーバーから顧客への応答 から構成されます。
HTTP-message = Simple-Request ; HTTP/0.9 messages
| Simple-Response
| Full-Request ; HTTP/1.0 messages
| Full-ResponseFull-Request and Full-Response use the generic message format of RFC 822 [7] for transferring entities. Both messages may include optional header fields (also known as "headers") and an entity body. The entity body is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF).
Full-Request と Full-Response は実体の転送に RFC 822 の一般メッセージ形式を使います。両メッセージは省略可能な頭欄 (「頭達」とも呼ばれる) と実体本文を含んでも構いません。 実体本文は頭達と空行 (つまり CRLF の前に何も無い行) で区切ります。
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2 Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2Simple-Request and Simple-Response do not allow the use of any header information and are limited to a single request method (GET).
Simple-Request と Simple-Response はいかなる頭情報の使用も 認められませんし、単一要求方式 (GET) に制限されます。
Simple-Request = "GET" SP Request-URI CRLF
Simple-Response = [ Entity-Body ]
Use of the Simple-Request format is discouraged because it prevents the server from identifying the media type of the returned entity.
Simple-Request 形式の使用は非推奨です。 この形式では返される実体の媒体型を識別できないからです。
HTTP messages consist of requests from client to server and responses from server to client.
HTTP メッセージは顧客からサーバーへの要求とサーバーから顧客への 応答で構成されます。
HTTP-message = Request | Response ; HTTP/1.1 messages
Request (section 5) and Response (section 6) messages use the generic message format of RFC 822 [9] for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body.
Request, Response 両メッセージは実体 (メッセージの弾頭) の転送に RFC 822 の一般メッセージ形式を使います。両メッセージ型は star-line, 0個以上の頭欄 (「頭達」とも呼ばれる), 頭欄の終わりを示す空行 (つまり CRLF の前に何も無い行), それとあれば message-body から構成されます。
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-LineIn the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.
頑強性の点から、サーバーは Request-Line が来るはずのところで 受け取った空行を無視するべきです。他の言葉でいえば、サーバーが メッセージの始めのプロトコル列を読んで最初に CRLF を受け取ったなら、 その CRLF は無視するべきです。
Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an extra CRLF.
イかれた HTTP/1.0 の顧客実装は余計な CRLF 達を POST 要求の後に生成します。 BNF で明示的に禁止されていることを 繰り返しますが、 HTTP/1.1 顧客は要求の前や後に余計な CRLF をつけてはいけません。
In addition to defining the
{1945} HTTP/1.0HTTP/1.1 protocol, this document serves as the specification for the Internet media type "message/http" {2616} and "application/http". {2616} The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed). The following is to be registered with IANA{1945} [13]{2616} [17] .
この文書は、 HTTP プロトコルを定義するのに加えて、インターネットmessage/http および message/http 型は、単一の HTTP 要求メッセージまたは応答メッセージを、すべての message 型についての行長と符号化に関する MIME の制限に従うものとして囲むために使うことができます。 application/http 型は、一つ以上の HTTP 要求メッセージ群または応答メッセージ群 (非混合。) のパイプ線を囲むために使うことができます。
次は、 IANA に登録されます。
- Media Type name
- message
- Media subtype name
- http
- Required parameters
- none
- Optional parameters
- version, msgtype
- version
- The HTTP-Version number of the enclosed message (e.g.,
{1945} "1.0""1.1"). If not present, the version can be determined from the first line of the body.
囲まれたメッセージの 1.0 や 1.1。)
存在しなければ、版は
- msgtype
- The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.
メッセージ型 — request 又は response。
存在しなければ、型は本体の最初の行から決定できます。
- Encoding considerations
- only "7bit", "8bit", or "binary" are permitted
- Security considerations
- none
{2616}
- Media Type name
- application
- Media subtype name
- http
- Required parameters
- none
- Optional parameters
- version, msgtype
- version
- The HTTP-Version number of the enclosed messages (e.g., "1.1"). If not present, the version can be determined from the first line of the body.
囲まれたメッセージの HTTP-Version 番号
(例えば 1.1。)
存在しなければ、版は本体の最初の行から決定できます。
- msgtype
- The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.
メッセージ型 — request 又は response。
存在しなければ、型は本体の最初の行から決定できます。
- Encoding considerations
- HTTP messages enclosed by this type are in "binary" format; use of an appropriate Content-Transfer-Encoding is required when transmitted via E-mail.
この型で囲まれた HTTP メッセージは
- Security considerations
- none
HTTP messages consist of requests from client to server and responses from server to client.
HTTP メッセージは、
HTTP-message = Simple-Request ; HTTP/0.9 messages | Simple-Response | Full-Request ; HTTP/1.0 messages | Full-Response
- HTTP-message = Request | Response ; HTTP/1.1 messages
Full-RequestRequest (section 5) andFull-ResponseResponse (section 6) messages use the generic message format of RFC 822[7][9] for transferring entities (the payload of the message).Both messages may include optional header fields (also known as "headers") and an entity body. The entity body is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF).Both types of message consist of a start-line,onezero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, andan optionalpossibly a message-body.
(完全)要求メッセージと(完全)応答メッセージは、start-line (開始行)、一つ零個以上の
Full-Request = Request-Line ; Section 5.1 *( General-Header ; Section 4.3 | Request-Header ; Section 5.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2Full-Response = Status-Line ; Section 6.1 *( General-Header ; Section 4.3 | Response-Header ; Section 6.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2
generic-message = start-line*message-header*(message-header CRLF) CRLF [ message-body ]- start-line = Request-Line | Status-Line
Simple-Request and Simple-Response do not allow the use of any header information and are limited to a single request method (GET).
Simple-Request (単純要求) と Simple-Response
は頭情報の使用を認めず、要求方式も1つ (
- Simple-Request = "GET" SP Request-URI CRLF
- Simple-Response = [ Entity-Body ]
Use of the Simple-Request format is discouraged because it prevents the server from identifying the media type of the returned entity.
Simple-Request 書式は、サーバーから返される実体の
In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.
頑強性の観点から、サーバーは
Note: certainCertain buggy HTTP/1.0 client implementations generateanextra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 clientmust notMUST NOT preface or follow a request with an extra CRLF.
ある蝕まれた HTTP/1.0 クライアント実装は
注: 追加・削除は 1945→2068 のもの。追加中の追加・削除は 2068→2616 のもの。
→
→
→
→
The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by
{1945} [17]{2068,2616} ANSI X3.4-1986 [21] .
次の規則はこの仕様書を通じて基本解析構造体を記述するために使用します。 US-ASCII 符号化文字集合は ANSI X 3.4‐1986 で定義されています。
- OCTET = <any 8-bit sequence of data>
- CHAR = <any US-ASCII character (octets 0 - 127)>
- UPALPHA = <any US-ASCII uppercase letter "A".."Z">
- LOALPHA = <any US-ASCII lowercase letter "a".."z">
- ALPHA = UPALPHA | LOALPHA
- DIGIT = <any US-ASCII digit "0".."9">
- CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
- CR = <US-ASCII CR, carriage return (13)>
- LF = <US-ASCII LF, linefeed (10)>
- SP = <US-ASCII SP, space (32)>
- HT = <US-ASCII HT, horizontal-tab (9)>
- <"> = <US-ASCII double-quote mark (34)>
HTTP/1.0HTTP/1.1 defines the{1945} octetsequence CR LF as the end-of-line marker for all protocol elements except the{1945} Entity-Bodyentity-body (see{1945} Appendix Bappendix 19.3 for tolerant applications). The end-of-line marker within an{1945} Entity-Bodyentity-body is defined by its associated media type, as described in{1945} Section 3.6section 3.7.
HTTP は実体本体を除くすべてのプロトコル要素で列
CR LF を行末の印と定義します。
実体本体中の行末の印はその関連付けられた
- CRLF = CR LF
HTTP/1.0HTTP/1.1{1945,2068} headers{2616} header field values{1945} maycan be folded onto multiple lines if{1945} eachthe continuation line begins with a space or horizontal tab. All linear{1945} whitespacewhite space, including folding, has the same semantics as SP. {2616} A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.
HTTP 頭欄値は、続く行が間隔又は水平タブで始まるのであれば複数行に折畳むことができます。
すべての線形空白は、折畳みも含み、 SP
と同じ意味を持ちます。受信者は、欄値を解釈したりSP に置換しても構いません。
- LWS = [CRLF] 1*( SP | HT )
{1945} However, folding of header lines is not expected by some applications, and should not be generated by HTTP/1.0 applications.
しかし、頭行の折畳みを予期していない応用もありますので、 HTTP/1.0 応用は生成するべきではありません。
The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT
{1945,2068} may{2616} MAY contain{1945} octetscharacters from character sets other than{1945} US-ASCII{2068,2616}ISO 8859-1ISO-8859-1 [22] only when encoded according to the rules of RFC15222047 [14] .
TEXT 規則は記述的欄内容とメッセージ解析器に解釈されることを意図しない値にのみ使います。
*TEXT の語は US-ASCII RFC 2047 の規則に従って符号化するときのみ ISO-8859-1
以外の文字集合のオクテット文字を含んでも構いません。
- TEXT = <any OCTET except CTLs, but including LWS>
{1945} Recipients of header field TEXT containing octets outside the US-ASCII character set may assume that they represent ISO-8859-1 characters.
US-ASCII 文字集合の外のオクテットを含んだ頭欄 TEXT の受信者は、
それが ISO-8859-1 文字を表現するものと仮定しても構いません。
{2616} A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT value.
CRLF は、 TEXT の定義の中では、
頭欄継続の一部としてのみ認められています。
折畳み LWS は TEXT 値の解釈の前に単一の
SP に置換されることを意図定しています。
Hexadecimal numeric characters are used in several protocol elements.
十六進数文字は幾つかのプロトコル要素で使います。
- HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
Many
HTTP/1.0HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters{1945} mustMUST be in a quoted string to be used within a parameter value {2616} (as defined in section 3.6).
多くの HTTP 頭欄値は、 LWS または特殊文字で分離される語で構成されます。
特殊文字は引数値中で使うためには引用文字列中にいれなければなりません。
{1945}
- word = token | quoted-string
{1945,2068}
- token = 1*<any CHAR except CTLs or tspecials>
- tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
{2616}
- token = 1*<any CHAR except CTLs or separators>
- separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
Comments
{1945} maycan be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.
注釈は、注釈文を括弧で囲むことで幾つかの HTTP 頭欄中に含めることができます。
注釈は、欄値定義の一部に comment を含んでいる欄でのみ認められます。
他のすべての欄では、括弧は欄値の一部とみなされます。
{1945,2068} comment = "(" *( ctext | comment ) ")"- {2616} comment = "(" *( ctext | quoted-pair | comment ) ")"
- ctext = <any TEXT excluding "(" and ")">
A string of text is parsed as a single word if it is quoted using double-quote marks.
二重引用符を使って引用されている文字列は単一の語として解析します。
{1945,2068} quoted-string = ( <"> *(qdtext) <"> )- {2616} quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
{1945} qdtext = <any CHAR except <"> and CTLs, but including LWS>- {2068,2616} qdtext = <any TEXT except <">>
{1945} Single-character quoting using the backslash ("\") character is not permitted in HTTP/1.0.
HTTP/1.0 では逆斜線 (\) 文字を使った単一文字引用は認められていません。
{2068,2616} The backslash character ("\")
mayMAY be used as a single-character quoting mechanism only within quoted-string and comment constructs.
逆斜線文字 (\) は、 quoted-string 構造体および
comment 構造体の中でのみ、
単一文字引用機構として使って構いません。
- quoted-pair = "\" CHAR
The RTSP syntax is described in an augmented Backus-Naur form (BNF) as used in RFC 2068 [2].
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
>
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
CRLF = CR LF
LWS = [CRLF] 1*( SP | HT )
TEXT = <any OCTET except CTLs>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
>
token = 1*<any CHAR except CTLs or tspecials>
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <any TEXT except <">>
quoted-pair = "\" CHAR
>
message-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value and
consisting of either *TEXT or
combinations of token, tspecials, and
quoted-string>
>
safe = "\$" | "-" | "_" | "." | "+"
extra = "!" | "*" | "$'$" | "(" | ")" | ","
>
hex = DIGIT | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
escape = "\%" hex hex
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
>
unreserved = alpha | digit | safe | extra
xchar = unreserved | reserved | escape訳注 : 編集上の誤りっぽいところがありますが、原文通りにしておきます。
The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986.
次の規則はこの仕様書を通じて基本解析構造体を記述するために使用します。 US-ASCII 符号化文字集合は ANSI X 3.4‐1986 で定義されています。
- OCTET = <any 8-bit sequence of data>
- CHAR = <any US-ASCII character (octets 0 - 127)>
- upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
- lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
- alpha = lowalpha | upalpha
- digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
- alphanum = alpha | digit
- CTL = <any US-ASCII control character
- (octets 0 -- 31) and DEL (127)>
- CR = %d13 ; US-ASCII CR, carriage return character
- LF = %d10 ; US-ASCII LF, line feed character
- SP = %d32 ; US-ASCII SP, space character
- HT = %d09 ; US-ASCII HT, horizontal tab character
- CRLF = CR LF ; typically the end of a line
- alphanum = ALPHA / DIGIT
The following are defined in RFC 2396 [12] for the SIP URI: Several rules are incorporated from RFC 2396 [5] but are updated to make them compliant with RFC 2234 [10]. These include:
次は
- unreserved = alphanum | mark
- mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
- escaped = "%" hex hex
- reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / ","
- unreserved = alphanum / mark
- mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
- escaped = "%" HEXDIG HEXDIG
SIP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8]. The SWS construct is used when linear white space is optional, generally between tokens and separators.
SIP 頭欄値は、続く行が間隔又は水平タブで始まるのであれば複数行に折畳むことができます。
すべての線形空白は、折畳みも含み、 SP
と同じ意味を持ちます。受信者は、欄値を解釈したりSP に置換しても構いません。これは RFC 2616 で説明されている HTTP/1.1 の場合と全く同じようになることを意図しています。 SWS 構造体は線形空白が省略可能である時、通常は字句と分離子の間で使います。
LWS = [CRLF] 1*( SP | HT ) ; linear whitespace- LWS = [*WSP CRLF] 1*WSP ; linear whitespace
- SWS = [LWS] ; sep whitespace
To separate the header name from the rest of value, a colon is used, which, by the above rule, allows whitespace before, but no line break, and whitespace after, including a linebreak. The HCOLON defines this construct.
頭名を残りの値と分離するためにコロンを使いますが、
これは上の規則により前に空白を求めるものの改行は認めず、
後には空白を改行も含めて認めます。 HCOLON
はこの構造体を定義します。
- HCOLON = *( SP / HTAB ) ":" SWS
The TEXT-UTF8 rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT-UTF8 contain characters from the UTF-8
character set (RFC 2279 [21])charset (RFC 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field contents that are n t quoted strings, where leading and trailing LWS is not meaningful. In this regard, SIP differs from HTTP, which uses the ISO 8859-1 character set.
TEXT-UTF8 規則は記述的欄内容とメッセージ解析器に解釈されることを意図しない値にのみ使います。
*TEXT-UTF8 の語は UTF-8 charset の文字だけを含めます。TEXT-UTF8-TRIM 規則は引用文字列ではなく、最初と最後の LWS が意味を持たない記述的欄内容に使用します。
この点では、 SIP は ISO 8859‐1 を使用する HTTP と異なります。
- TEXT-UTF8 = <any UTF-8 character encoding, except CTLs, but including LWS>
- TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)
- TEXT-UTF8char = %x21-7E / UTF8-NONASCII
- UTF8-NONASCII = %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-Fb 4UTF8-CONT / %xFC-FD 5UTF8-CONT
- UTF8-CONT = %x80-BF
A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT-UTF8-TRIM value.
CRLFは、TEXT-TRIMの定義の中では、 頭欄継続の一部としてのみ認められています。 折畳みLWSはTEXT-TRIM値の解釈の前に単一のSPに置換されることを意図定しています。Hexadecimal numeric characters are used in several protocol elements. Some elements (authentication) force hex alphas to be lower case.
十六進数文字は幾つかのプロトコル要素で使います。幾つかの要素 (認証) は十六進字母が小文字であることを強制します。
hex = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | digit- LHEX = DIGIT / %x61-66 ;lowercase a-f
Many SIP header field values consist of words separated by LWS or special characters. Unless otherwise stated, tokens are case-insensitive. These special characters MUST be in a quoted string to be used within a parameter value. The word construct is used in Call-ID to allow most separators to be used.
多くの SIP 頭欄値は、
LWSまたは特殊文字で分離される語で構成されます。別途言及されていない限り、字句は大文字・小文字を区別します。 特殊文字は引数値中で使うためには引用文字列中にいれなければなりません。word構造体はでほとんどの分離子を使用できるようにするために使います。Call-ID
token = 1*< any CHAR except CTL's or separators>- token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" )
separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT- separators = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" / SP / HTAB
- word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" / "(" / ")" / "<" / ">" / ":" / "\" / DQUOTE / "/" / "[" / "]" / "?" / "{" / "}" )
When tokens are used or separators are used between elements, whitespace is often allowed before or after these characters:
字句が使われる場合や分離子が要素間で使われる場合には、 空白がしばしばその文字の前後に認められます。
- STAR = SWS "*" SWS ; asterisk
- SLASH = SWS "/" SWS ; slash
- EQUAL = SWS "=" SWS ; equal
- LPAREN = SWS "(" SWS ; left parenthesis
- RPAREN = SWS ")" SWS ; right parenthesis
- RAQUOT = ">" SWS ; right angle quote
- LAQUOT = SWS "<"; left angle quote
- COMMA = SWS "," SWS ; comma
- SEMI = SWS ";" SWS ; semicolon
- COLON = SWS ":" SWS ; colon
- LDQUOT = SWS DQUOTE; open double quotation mark
- RDQUOT = DQUOTE SWS ; close double quotation mark
Comments can be included in some SIP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.
注釈は、注釈文を括弧で囲むことで幾つかの SIP 頭欄中に含めることができます。 注釈は、欄値定義の一部に
commentを含んでいる欄でのみ認められます。 他のすべての欄では、括弧は欄値の一部とみなされます。
comment = "(" *(ctext | quoted-pair | comment) ")"- comment = LPAREN *(ctext / quoted-pair / comment) RPAREN
ctext = < any TEXT-UTF8 excluding "(" and ")">- ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII / LWS
ctext includes all chars except left and right parens and backslash. A string of text is parsed as a single word if it is quoted using double-quote marks. In quoted strings, quotation marks (") and backslashes (\) need to be escaped.
;
ctextは左右の括弧と逆斜線を除くすべての文字を含みます。 二重引用符を使って引用されている文字列は単一の語として解析します。引用文字列中では、引用符 (") と逆斜線 (\) は escape する必要があります。
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )- quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
qdtext = <any TEXT-UTF8 except <">>- qdtext = LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII
The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this mechanism to avoid conflict with line folding and header separation.
逆斜線文字 (
\) は、quoted-string構造体およびcomment構造体の中でのみ、 単一文字引用機構として使って構いません。HTTP/1.1 とは異なり、文字CR及びLFは行折畳みや頭分離との衝突を避けるためにこの機構を使って escape することはできません。
quoted-pair = " \ " CHAR- quoted-pair = "\" (%x00-09 / %x0B-0C / %x0E-7F)
Message
Request or a response between an OpenID Relying Party and an OpenID Provider.
proxy-sendextracrlf
Causes proxy to send an extra CR-LF newline on the end of a request. This is a workaround for a bug in some browsers.
By default, the message bodies of NOTIFY messages for the http-
monitor event package will be of content-type "message/http," as
defined in RFC 2616 [2].