목차
MRCPv2는 MRCPv2(Media Resource Control Protocol Version 2)의 약어입니다. 이 문서는 RFC6787 섹션 6.2를 번역합니다. 일반 메시지 헤더
6.2 일반 메시지 헤더
다음 하위 섹션에 정의된 일반 헤더와 나중에 정의된 리소스별 헤더 필드를 포함한 모든 MRCPv2 헤더 필드는 RFC 5322 [RFC5322] 의 섹션 3.1에 제공된 것과 동일한 일반 형식을 따릅니다.
각 헤더 필드는 이름과 콜론(":") 및 값으로 구성됩니다. 헤더 필드 이름은 대소문자를 구분하지 않습니다. 값 앞에는 LWS(선형 공백)가 얼마든지 올 수 있지만 단일 SP(공백)가 선호됩니다.
헤더 필드는 각 추가 줄 앞에 하나 이상의 SP 또는 HT(가로 탭)를 사용하여 여러 줄로 확장할 수 있습니다.
generic-field = field-name ":" [ field-value ]
field-name = token
field-value = *LWS field-content *( CRLF 1*LWS field-content)
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
필드 내용은 선행 또는 후행 LWS(즉, 필드 값의 첫 번째 공백이 아닌 문자 앞 또는 필드 값의 공백이 아닌 마지막 문자 뒤에 발생하는 선형 공백)를 포함하지 않습니다. 이러한 선행 또는 후행 LWS는 필드 값 의미 체계를 변경하지 않고 제거할 수 있습니다.
필드 내용 사이에 발생하는 모든 LWS는 필드 값을 해석하거나 메시지 다운스트림을 전달하기 전에 단일 SP로 대체될 수 있습니다.
MRCPv2 서버와 클라이언트는 헤더 필드 순서에 의존해서는 안 됩니다 . 일반 헤더 필드를 먼저 보낸 다음 요청 또는 응답 헤더 필드, 마지막으로 엔터티 헤더 필드를 보내는 것이 좋습니다.
그러나 MRCPv2 서버와 클라이언트는 순서에 상관없이 헤더 필드를 처리할 준비가 되어 있어야 합니다. 이 규칙의 유일한 예외는 메시지에 이름이 같은 헤더 필드가 여러 개 있는 경우입니다.
이름이 같은 여러 헤더 필드는 해당 헤더 필드의 전체 값이 쉼표로 구분된 목록으로 정의된 경우에만 메시지에 나타날 수 있습니다.
공급업체/공급업체별 매개변수는 순서에 따라 달라질 수 있으므로 각 후속 값을 첫째, 각각은 쉼표로 구분됩니다. 따라서 동일한 이름의 헤더 필드가 수신되는 순서는 복합 헤더 필드 값의 해석에 중요하므로 중개자는 메시지를 전달할 때 이러한 값의 순서를 변경해서는 안 됩니다(MUST NOT).
generic-header = channel-identifier
/ accept
/ active-request-id-list
/ proxy-sync-id
/ accept-charset
/ content-type
/ content-id
/ content-base
/ content-encoding
/ content-location
/ content-length
/ fetch-timeout
/ cache-control
/ logging-tag
/ set-cookie
/ vendor-specific
6.2.1. 채널 식별자
모든 MRCPv2 요청, 응답 및 이벤트는 Channel-Identifier 헤더 필드를 포함해야 합니다 . 이 값은 제어 채널이 세션에 추가되고 서버의 SDP 응답에서 " a=channel " 속성을 통해 클라이언트와 통신할 때 서버에 의해 할당됩니다.
헤더 필드 값은 "@" 기호로 구분되는 두 부분으로 구성됩니다. 첫 번째 부분은 MRCPv2 세션을 식별하는 데 사용되는 명확한 문자열입니다. 두 번째 부분은 섹션 3.1에 나열된 미디어 처리 리소스 유형 중 하나를 지정하는 문자열 태그입니다.
모호하지 않은 문자열(첫 번째 부분)은 추측하기 어렵고 서버에서 관리하는 리소스 인스턴스 내에서 고유해야 하며 단일 SIP 대화를 통해 해당 서버와 설정된 모든 리소스 채널에 공통되어야 합니다.
channel-identifier = "Channel-Identifier" ":" channel-id CRLF
channel-id = 1*alphanum "@" 1*alphanum
6.2.2. 수용하다
Accept 헤더 필드는 [H14.1]에 정의된 구문을 따릅니다. Accept 헤더 필드가 없는 경우 서버가 제어되는 리소스 유형에 특정한 기본값을 가정해야 한다는 점을 제외하면 의미 체계도 동일합니다. 이 기본값은 SET-PARAMS 메서드에서 이 헤더 필드를 전송하여 세션의 리소스에 대해 변경할 수 있습니다. 세션의 리소스에 대한 이 헤더 필드의 현재 기본값은 GET-PARAMS 메서드를 통해 찾을 수 있습니다. 이 헤더 필드는 모든 요청에 존재할 수 있습니다.
6.2.3. 활성 요청 ID 목록
요청에서 이 헤더 필드는 요청이 적용되는 요청 ID 목록을 나타냅니다. 이것은 PENDING 또는 IN-PROGRESS 상태에 있는 여러 요청이 있고 클라이언트가 이 요청이 하나 이상의 요청에만 적용되기를 원할 때 유용합니다.
응답에서 이 헤더 필드는 이 메서드에 의해 수정되거나 영향을 받는 요청 ID 목록을 반환합니다. PENDING 또는 IN-PROGRESS 요청 상태 인 요청이 하나 이상 있을 수 있습니다 . 하나 이상의 PENDING 또는 IN-PROGRESS 요청에 영향을 미치는 메서드가 클라이언트에서 서버로 전송될 때 응답은 헤더에 이 명령에 의해 영향을 받거나 수정된 요청 ID 목록을 포함해야 합니다.
Active-Request-Id-List는 이벤트가 아닌 요청 및 응답에만 사용됩니다 .
예를 들어 Active-Request-Id-List가 없는 STOP 요청이 PENDING 또는 IN-PROGRESS 상태 에 있는 하나 이상의 SPEAK 요청이 있는 (음성) 합성 리소스로 전송되면 상태를 포함하여 모든 SPEAK 요청을 취소해야 합니다. 진행 중입니다.
STOP 요청에 대한 응답에는 Active-Request-Id-List 값 에 종료된 모든 SPEAK 요청의 요청 ID가 포함됩니다 . STOP 응답을 보낸 후 서버는 종료된 요청에 대해 SPEAK-COMPLETE 또는 RECOGNITION-COMPLETE 이벤트를 보내면 안 됩니다(MUST NOT).
active-request-id-list = "Active-Request-Id-List" ":"
request-id *("," request-id) CRLF
6.2.4. 프록시 동기화 ID
모든 서버 자원이 " barge -in-able " 이벤트를 생성할 때 고유한 태그 도 생성합니다 . 토큰은 이 헤더 필드의 값으로 이벤트의 클라이언트에 전송됩니다. 그런 다음 클라이언트는 서버 리소스 간의 중개자 역할을 하고 서버 리소스에서 받은 Proxy-Sync-Id 를 사용하여 BARGE-IN-OCCURRED 메서드를 (음성) 합성 서버 리소스로 보냅니다 . (음성) 인식기 및 (음성) 합성기 리소스가 동일한 세션에 속할 때 더 빠른 상호 작용 및 응답을 위해 함께 작동하도록 선택할 수 있습니다. 여기에서 Proxy-Sync-Id는 이벤트를 수신하는 리소스(클라이언트가 중재함)가 이 이벤트가 리소스의 직접적인 상호 작용에 의해 처리되었는지 여부를 결정하는 데 도움이 됩니다.
이 헤더 필드는 **이벤트(이벤트)** 및 BARGE-IN-OCCURRED 메서드 에만 나타날 수 있습니다 . 이 헤더 필드의 이름에는 역사적 이유로만 "프록시"라는 단어가 포함되어 있으며 프록시 서버가 관련되어 있음을 의미하지는 않습니다.
proxy-sync-id = "Proxy-Sync-Id" ":" 1*VCHAR CRLF
6.2.5. Accept-Charset
[H14.2] 참조. 이것은 이 요청과 관련된 응답 또는 이벤트에서 반환된 엔터티에 허용되는 문자 집합을 지정합니다. 이는 RECOGNITION-COMPLETE 이벤트의 NLSML(Natural Language Semantic Markup Language) 결과에 사용할 문자 집합을 지정하는 데 유용합니다 . 이 헤더 필드는 요청에만 사용됩니다 .
6.2.6. 컨텐츠 타입
[H14.17] 참조. MRCPv2는 음성 마크업 , 문법(gramma) 및 인식 결과(인식 결과)를 포함하여 콘텐츠 등록을 위한 제한된 미디어 유형 세트를 지원합니다 . 각 MRCPv2 리소스 유형에 적용 가능한 콘텐츠 유형은 문서의 해당 섹션에 지정되고 IANA에서 관리하는 MIME 미디어 유형 레지스트리에 등록됩니다. 멀티파트 콘텐츠 유형 " multipart/mixed "는 위 콘텐츠의 배수를 전달하기 위해 지원되며, 이 경우 본문 부분은 MRCPv2 특정 헤더 필드를 포함해서는 안 됩니다. 이 헤더 필드는 모든 메시지에 나타날 수 있습니다 .
content-type = "Content-Type" ":" media-type-value CRLF
media-type-value = type "/" subtype *( ";" parameter )
type = token
subtype = token
parameter = attribute "=" value
attribute = token
value = token / quoted-string
6.2.7. 콘텐츠 ID
이 헤더 필드에는 참조 가능한 콘텐츠의 ID 또는 이름이 포함됩니다. 이 헤더 필드는 RFC 2392[RFC2392]의 사양에 따라 작동하며 다중 부분 메시지의 내용 명확성에 필요합니다. MRCPv2에서는 클라이언트나 서버가 관련 콘텐츠를 저장할 때마다 이 ID를 사용하여 검색할 수 있어야 합니다. 이러한 콘텐츠는 섹션 13.6에 설명된 "세션" URI 체계를 사용하여 주소를 지정하여 나중에 세션에서 참조할 수 있습니다. 이 헤더 필드는 모든 메시지에 나타날 수 있습니다 .
6.2.8. 콘텐츠 기반
Content-Base 엔터티 헤더는 엔터티 내의 상대 URI를 확인하는 데 사용되는 기본 URI를 지정하는 데 사용할 수 있습니다.
content-base = "Content-Base" ":" absoluteURI CRLF
그러나 엔터티 본문의 콘텐츠에 대한 기본 URI는 해당 엔터티 본문 내에서 재정의할 수 있습니다. 예를 들어 멀티파트 미디어는 그 안에 여러 엔터티를 포함할 수 있습니다. 이 헤더 필드는 모든 메시지에 나타날 수 있습니다 .
6.2.9. 콘텐츠 인코딩
Content-Encoding 엔터티 헤더는 Content-Type의 수정자로 사용됩니다. 존재하는 경우 해당 값은 entity-body에 적용된 추가 콘텐츠 인코딩과 Content-Type 헤더 필드에서 참조하는 미디어 유형을 얻기 위해 적용해야 하는 디코딩 메커니즘을 나타냅니다. 콘텐츠 인코딩은 주로 기본 미디어 유형의 ID를 잃지 않고 문서를 압축할 수 있도록 하는 데 사용됩니다. SIP 세션을 사용하여 허용되는 인코딩을 결정할 수 있습니다(섹션 7 참조). 이 헤더 필드는 모든 메시지에 나타날 수 있습니다.
content-encoding = "Content-Encoding" ":"
*WSP content-coding
*(*WSP "," *WSP content-coding *WSP )
CRLF
콘텐츠 인코딩은 [H3.5]에 정의되어 있습니다. 사용법의 예는 Content-Encoding:gzip입니다.
엔터티에 여러 인코딩이 적용된 경우 콘텐츠 인코딩은 적용된 순서대로 나열되어야 합니다.
6.2.10. 콘텐츠 위치
Content-Location 엔터티 헤더는 엔터티가 요청된 리소스의 URI와 다른 위치에서 액세스할 수 있는 경우 메시지에 포함된 엔터티에 대한 리소스 위치를 제공하는 데 사용될 수 있습니다(MAY). [H14.14] 참조.
content-location = "Content-Location" ":"
( absoluteURI / relativeURI ) CRLF
Content-Location 값은 요청 시 이 특정 엔터티에 해당하는 리소스의 위치 선언입니다. 이 헤더 필드는 최적화 목적으로만 사용됩니다. 이 헤더의 수신자는 전송되는 엔터티가 Content-Location URI 에서 검색되었거나 검색되었을 수 있는 동일한 엔터티 라고 가정할 수 있습니다(MAY).
예를 들어 클라이언트가 인라인 구문 마크업을 제공하고 이전에 URI에서 검색한 경우 URI는 Content-Location 헤더 필드를 사용하여 엔터티의 일부로 제공될 수 있습니다. 이를 통해 인식기와 같은 리소스가 캐시를 조사하여 이 문법이 이전에 검색, 컴파일 및 캐시되었는지 확인할 수 있습니다. 이 경우 최적화를 위해 이전에 컴파일된 구문 개체를 사용할 수 있습니다.
Content-Location이 상대 URI인 경우 상대 URI는 Content-Base URI 에 상대적으로 해석됩니다 . 이 헤더 필드는 모든 메시지에 나타날 수 있습니다.
6.2.11. 콘텐츠 길이
이 헤더 필드는 메시지 본문 내용의 길이를 포함합니다(즉, 마지막 헤더 필드 뒤의 이중 CRLF 뒤). HTTP와 달리 헤더 이외의 콘텐츠를 전달하는 모든 메시지에 포함되어야 합니다. 누락된 경우 기본값 0이 가정됩니다 . 그렇지 않으면 [H14.13]과 같이 해석한다. 메시지 본문을 사용하지 않는 메시지가 메시지를 포함하는 경우(예: Content-Length가 0이 아닌 경우) 수신자는 메시지 본문의 내용을 무시해야 합니다. 이 헤더 필드는 모든 메시지에 나타날 수 있습니다.
content-length = "Content-Length" ":" 1*19DIGIT CRLF
6.2.12. 가져오기 시간 초과
(음성) 인식기 또는 (음성) 합성기가 문서 또는 기타 리소스를 검색해야 하는 경우 이 헤더 필드는 해당 URI 액세스 속성을 제어합니다. 이는 서버가 네트워크를 통해 가져와야 하는 콘텐츠에 대한 시간 제한을 정의합니다. 값은 밀리초로 해석되며 범위는 0에서 구현별 최대값까지입니다. 서버는 긴 제한 시간 값을 수락할 때 주의해야 합니다. 이 헤더 필드의 기본값은 구현에 따라 다릅니다. 이 헤더 필드는 DEFINE-GRAMMAR, RECOGNIZE, SPEAK, SET-PARAMS 또는 GET-PARAMS에 나타날 수 있습니다.
fetch-timeout = "Fetch-Timeout" ":" 1*19DIGIT CRLF
6.2.13. 캐시 제어
서버가 콘텐츠 캐싱을 구현하는 경우 저장된 콘텐츠에 액세스하고 캐싱할 때 HTTP 1.1 [ RFC2616 ] 의 캐시 정확성 규칙을 준수해야 합니다. 특히, 캐시된 URI 또는 문서의 "expires" 및 "cache-control" 헤더 필드는 이 헤더 필드에 의해 설정된 Cache-Control 기본값 보다 우선적으로 존중되어야 합니다 .
Cache-Control 지시문은 세션 또는 요청에 대해 서버에서 기본 캐싱 알고리즘을 정의하는 데 사용됩니다. 명령의 범위는 명령이 전송되는 방법을 기반으로 합니다. 이 지시문이 SET-PARAMS 메서드 로 전송되면 개별 요청의 Cache-Control 헤더 필드에 의해 재정의되지 않는 한 해당 세션 동안 외부 문서에 대해 서버가 만든 모든 요청에 적용됩니다.
다른 요청에 대해 지시문을 보낸 경우 해당 요청에 대해 서버에서 수행한 외부 문서 요청에만 적용됩니다. GET-PARAMS 메서드의 빈 Cache-Control 헤더 필드는 서버의 현재 Cache-Control 지시문 설정을 반환하라는 서버에 대한 요청입니다. 이 헤더 필드는 요청 시에만 제공될 수 있습니다.
cache-control = "Cache-Control" ":"
[*WSP cache-directive
*( *WSP "," *WSP cache-directive *WSP )]
CRLF
cache-directive = "max-age" "=" delta-seconds
/ "max-stale" [ "=" delta-seconds ]
/ "min-fresh" "=" delta-seconds
delta-seconds = 1*19DIGIT
여기서 delta-seconds는 서버가 메시지 응답 또는 데이터를 수신한 순간부터 경과된 초 수를 지정하는 십진법 시간 값입니다.
다른 캐시 지시문 옵션을 사용하면 클라이언트가 기본 캐시 만료 메커니즘을 무시하도록 서버에 요청할 수 있습니다.
max-age Indicates that the client can tolerate the server
using content whose age is no greater than the
specified time in seconds. Unless a "max-stale"
directive is also included, the client is not willing
to accept a response based on stale data.
min-fresh Indicates that the client is willing to accept a
server response with cached data whose expiration is
no less than its current age plus the specified time
in seconds. If the server's cache time-to-live
exceeds the client-supplied min-fresh value, the
server MUST NOT utilize cached content.
max-stale Indicates that the client is willing to allow a server
to utilize cached data that has exceeded its
expiration time. If "max-stale" is assigned a value,
then the client is willing to allow the server to use
cached data that has exceeded its expiration time by
no more than the specified number of seconds. If no
value is assigned to "max-stale", then the client is
willing to allow the server to use stale data of any
age.
검증되지 않은 오래된 캐시 검증과 관련된 "반드시" 수준 요구 사항(예: "반드시 재검증" 캐시 제어 지시문)과 충돌하지 않는 경우에만 그렇게 합니다. 해당 URI와 연결된 HTTP 1.1 사양에 따라 수행됨).
MRCPv2 Cache-Control 지시문과 서버의 캐시 항목 모두 "max-age" 지시문을 포함하는 경우 두 값 중 작은 값이 해당 요청에 대한 캐시 항목의 신선도를 결정하는 데 사용됩니다.
6.2.14. 로깅 태그
이 헤더 필드는 SET-PARAMS/GET-PARAMS 메서드의 일부로 전송되어 서버 생성 로그에 대한 로깅 태그를 설정하거나 검색할 수 있습니다. 일단 설정되면 값은 새 값이 설정되거나 세션이 종료될 때까지 지속됩니다. MRCPv2 서버는 시스템 관리자가 로그 플래그가 특정 값으로 설정된 동안 로그 파일의 일부만 검사하거나 추출할 수 있도록 출력 로그의 하위 집합을 만드는 메커니즘을 제공할 수 있습니다.
클라이언트는 서버에서 주어진 로그 메시지를 생성한 MRCPv2 클라이언트 요청을 확인할 수 있도록 로깅 태그 정보에 MRCPv2 클라이언트 사용자 에이전트를 식별하는 정보를 포함하는 것이 좋습니다. 또한 MRCPv2 클라이언트는 신용 카드 번호 및 주민등록번호와 같은 개인 식별 정보를 기록하지 않는 것이 좋습니다.
logging-tag = "Logging-Tag" ":" 1*UTFCHAR CRLF
6.2.15. 세트 쿠키
MRCPv2 서버의 연결된 HTTP 클라이언트는 MRCPv2 클라이언트를 대신하여 처리할 문서를 가져오므로 MRCPv2 서버의 HTTP 클라이언트에 있는 쿠키 저장소는 MRCPv2 클라이언트의 HTTP 클라이언트에 있는 쿠키 저장소의 확장으로 간주됩니다.
이를 위해서는 MRCPv2 클라이언트와 서버가 필요에 따라 공통 쿠키 저장소를 동기화할 수 있어야 합니다. MRCPv2 클라이언트가 저장된 쿠키를 MRCPv2 서버에 푸시하고 MRCPv2 서버에서 새 쿠키를 가져와 MRCPv2 클라이언트에 다시 저장하려면 Set-Cookie 엔터티 헤더 필드를 MRCPv2 요청에 포함할 수 있습니다 . 서버에 저장된 쿠키를 업데이트하고 최종 MRCPv2 응답 또는 이벤트에서 반환되어 클라이언트의 자체 쿠키 저장소를 이후에 업데이트합니다. 서버에 저장된 쿠키는 MRCPv2 세션이 지속되는 동안 유지되며 세션이 끝나면 삭제되어야 합니다. 쿠키 지원을 보장하려면 MRCPv2 클라이언트와 서버가 Set-Cookie 엔터티 헤더 필드를 지원해야 합니다.
서버로 보낼 쿠키(있는 경우)를 결정하는 것은 MRCPv2 클라이언트입니다. 모든 쿠키를 공유해야 하는 것은 아닙니다. 대신 MRCPv2 클라이언트는 MRCPv2 서버가 요청을 처리하는 데 필요한 쿠키만 전송하는 것이 좋습니다.
set-cookie = "Set-Cookie:" cookies CRLF
cookies = cookie *("," *LWS cookie)
cookie = attribute "=" value *(";" cookie-av)
cookie-av = "Comment" "=" value
/ "Domain" "=" value
/ "Max-Age" "=" value
/ "Path" "=" value
/ "Secure"
/ "Version" "=" 1*19DIGIT
/ "Age" "=" delta-seconds
set-cookie = "Set-Cookie:" SP set-cookie-string
set-cookie-string = cookie-pair *( ";" SP cookie-av )
cookie-pair = cookie-name "=" cookie-value
cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
token = <token, defined in [RFC2616], Section 2.2>
cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av /
extension-av / age-av
expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT
non-zero-digit = %x31-39
domain-av = "Domain=" domain-value
domain-value = <subdomain>
path-av = "Path=" path-value
path-value = <any CHAR except CTLs or ";">
secure-av = "Secure"
httponly-av = "HttpOnly"
extension-av = <any CHAR except CTLs or ";">
age-av = "Age=" delta-seconds
Set-Cookie 헤더 필드는 RFC 6265 [RFC6265] 에 지정되어 있습니다 . " Age " 속성은 쿠키의 수명을 나타내기 위해 이 사양에 도입되었으며 선택 사항입니다. MRCPv2 클라이언트 또는 서버는 HTTP/1.1 사양 [RFC2616]의 나이 계산 규칙에 따라 쿠키의 나이를 계산하고 그에 따라 " Age " 속성을 추가해야 합니다. 이 속성은 클라이언트가 HTTP 서버에서 쿠키를 받은 후 일정 시간이 경과했을 수 있기 때문에 제공됩니다.
클라이언트가 실제 나이만큼 Max-Age를 감소시키는 대신 "Age" 속성이 추가된 Max-Age 약어를 전달하므로 시간이 경과했다는 사실을 고려하면서 수신된 쿠키를 유지합니다.
MRCPv2 클라이언트 또는 서버는 HTTP 원본 서버에서 생략된 경우 RFC 6265에 지정된 " 도메인 " 및 " 경로 " 속성 에 대한 기본값을 제공해야 합니다 . 이 경우 "도메인" 속성 값에 선행 점이 없다는 점에 유의하십시오. MRCPv2 클라이언트 또는 서버는 HTTP 프로토콜을 통해 수신된 명시적으로 지정된 "도메인" 값이 선행 점을 포함하도록 수정될 수 있지만 MRCPv2 프로토콜을 통해 수신될 때 "도메인" 값을 수정해서는 안 됩니다(MUST NOT).
MRCPv2 클라이언트 또는 서버는 섹션 6.2에 설명된 대로 동일한 유형의 여러 쿠키 헤더 필드를 "필드 이름: 필드 값" 쌍으로 결합할 수 있습니다(MAY).
Set-Cookie 헤더 필드는 이후에 서버가 HTTP 액세스를 수행하게 하는 모든 요청에 지정할 수 있습니다. 서버가 HTTP 원본 서버로부터 새 쿠키 정보를 수신할 때 쿠키 저장소가 RFC 6265에 따라 수정되었다고 가정하면 서버는 클라이언트가 자신의 쿠키를 업데이트할 수 있도록 필요에 따라 MRCPv2 COMPLETE 응답 또는 이벤트 에서 새 쿠키 정보를 반환 해야 합니다(MUST). 가게.
SET-PARAMS 요청은 Set-Cookie 헤더 필드를 지정하여 서버의 쿠키 저장소를 업데이트할 수 있습니다. GET-PARAMS 요청은 "Set-Cookie" 유형 쿠키에 대한 전체 쿠키 저장소를 클라이언트에 반환하는 데 사용할 수 있습니다.
6.2.16. 공급업체별 매개변수
이 헤더 필드 집합을 통해 클라이언트는 공급업체별 매개변수를 설정하거나 검색할 수 있습니다.
vendor-specific = "Vendor-Specific-Parameters" ":"
[vendor-specific-av-pair
*(";" vendor-specific-av-pair)] CRLF
vendor-specific-av-pair = vendor-av-pair-name "="
value
vendor-av-pair-name = 1*UTFCHAR
이 형식의 헤더 필드는 모든 메서드(요청)로 보낼 수 있으며 서버 측에서 구현 관련 매개 변수를 관리하는 데 사용됩니다.
vendor-av-pair-name은 역방향 인터넷 도메인 이름 규칙을 따릅니다(구문 및 등록 정보는 섹션 13.1.6 참조). 공급업체 속성 값은 "=" 기호 뒤에 지정되며 따옴표로 묶을 수 있습니다. 예를 들어:
com.example.companyA.paramxyz=256
com.example.companyA.paramabc=High
com.example.companyB.paramxyz=Low
서버에서 이러한 매개변수의 현재 값을 얻기 위해 GET-PARAMS 에서 사용되는 경우 이 헤더 필드 값에는 세미콜론으로 구분된 구현별 속성 이름 목록이 포함될 수 있습니다.