메시징 프로토콜

WCF(Windows Communication Foundation) 채널 스택은 인코딩 및 전송 채널을 사용하여 내부 메시지 표현을 와이어 형식으로 변환하고 특정 전송을 사용하여 전송합니다. 웹 서비스 상호 운용성에 사용되는 가장 일반적인 전송은 HTTP이며, 웹 서비스에서 사용하는 가장 일반적인 인코딩은 XML 기반 SOAP 1.1, SOAP 1.2 및 MTOM(메시지 전송 최적화 메커니즘)입니다.

이 항목에서는 다음 프로토콜에 대한 WCF 구현 세부 정보를 다룹니다 HttpTransportBindingElement.

사양/문서:

이 항목에서는 사용하고 있는 다음 프로토콜에 대한 WCF 구현 세부 정보를 다룹니다 TextMessageEncodingBindingElement MtomMessageEncodingBindingElement .

사양/문서:

이 항목에서는 사용하는 다음 프로토콜 MtomMessageEncodingBindingElement 에 대한 WCF 구현 세부 정보를 다룹니다.

사양/문서:

이 항목 전체에서 사용되는 XML 네임스페이스 및 관련 접두사는 다음과 같습니다.

프리픽스	네임스페이스 URI(통합 자원 식별자)
s11	`http://schemas.xmlsoap.org/soap/envelope`
s12	`http://www.w3.org/2003/05/soap-envelope`
wsa	`http://www.w3.org/2004/08/addressing`
wsam	`http://www.w3.org/2007/05/addressing/metadata`
wsap	`http://schemas.xmlsoap.org/ws/2004/09/policy/addressing`
wsa10	`http://www.w3.org/2005/08/addressing`
wsaw10	`http://www.w3.org/2006/05/addressing/wsdl`
xop	`http://www.w3.org/2004/08/xop/include`
xmime	`http://www.w3.org/2004/06/xmlmime` `http://www.w3.org/2005/05/xmlmime`
디피(DP)	`http://schemas.microsoft.com/net/2006/06/duplex`

SOAP 1.1 및 SOAP 1.2

봉투 및 처리 모델

WCF는 기본 프로필 1.1(BP11) 및 기본 프로필 1.0(SSBP10)에 따라 SOAP 1.1 봉투 처리를 구현합니다. SOAP 1.2 봉투 처리는 SOAP12-Part1 다음에 구현됩니다.

이 섹션에서는 BP11 및 SOAP12-Part1과 관련하여 WCF에서 선택한 특정 구현에 대해 설명합니다.

필수 헤더 처리

WCF는 SOAP 1.1 및 SOAP 1.2 사양에 설명된 헤더 mustUnderstand 처리 규칙을 따르며 다음과 같은 변형이 있습니다.

WCF 채널 스택에 들어가는 메시지는 연결된 바인딩 요소(예: 텍스트 메시지 인코딩, 보안, 신뢰할 수 있는 메시징 및 트랜잭션)로 구성된 개별 채널에서 처리됩니다. 각 채널은 연결된 네임스페이스의 헤더를 인식하고 인식된 것으로 표시합니다. 메시지가 디스패처에 들어가면 작업 포맷터는 해당 메시지/작업 계약에서 예상하는 헤더를 읽고 인식된 것으로 표시합니다. 그런 다음 디스패처는 이해되지 않는 나머지 헤더가 mustUnderstand로 표시되어 있는지 확인하고 예외를 발생시킵니다. 받는 사람을 대상으로 하는 헤더가 포함된 mustUnderstand 메시지는 받는 사람 애플리케이션 코드에서 처리되지 않습니다.

이러한 계층화된 처리를 사용하면 SOAP 노드의 인프라 계층과 애플리케이션 계층을 분리할 수 있습니다.

B1111: WCF 인프라 채널 스택에서 메시지를 처리한 후 애플리케이션에서 처리되기 전에 인식되지 않는 헤더가 검색됩니다.

헤더 값은 mustUnderstand SOAP 1.1과 SOAP 1.2 간에 다릅니다. 기본 프로필 1.1에서는 SOAP 1.1 메시지의 mustUnderstand 값이 0 또는 1이어야 합니다. SOAP 1.2는 0, false1 및 true 값을 허용하지만 값(xs:boolean, false)의 true 정식 표현을 내보내는 것이 좋습니다.
B1112: WCF는 SOAP 봉투의 SOAP 1.1 및 SOAP 1.2 버전 모두에서 값 0과 1을 내보낸다. WCF는 헤더의 전체 값 공간을 xs:booleanmustUnderstand 허용합니다(0, 1, false, true)

SOAP 오류

다음은 WCF 관련 SOAP 오류 구현 목록입니다.

B2121: WCF는 다음 SOAP 1.1 오류 코드를 반환합니다. s11:mustUnderstands11:Clients11:Server
B2122: WCF는 다음 SOAP 1.2 오류 코드를 반환합니다. s12:MustUnderstands12:Senders12:Receiver

HTTP 바인딩

SOAP 1.1 HTTP 바인딩

WCF는 다음 설명과 함께 기본 프로필 1.1 사양 섹션 3.4에 따라 SOAP1.1 HTTP 바인딩을 구현합니다.

B2211: WCF 서비스는 HTTP POST 요청의 리디렉션을 구현하지 않습니다.
B2212: WCF 클라이언트는 3.4.8에 따라 HTTP 쿠키를 지원합니다.

SOAP 1.2 HTTP 바인딩

WCF는 다음 설명과 함께 SOAP 1.2부 2(SOAP12Part2) 사양에 설명된 대로 SOAP 1.2 HTTP 바인딩을 구현합니다.

SOAP 1.2에는 미디어 형식에 대한 선택적 작업 매개 변수가 application/soap+xml 도입되었습니다. 이 매개 변수는 WS-Addressing 사용하지 않을 때 SOAP 메시지의 본문을 구문 분석할 필요 없이 메시지 디스패치를 최적화하는 데 유용합니다.

R2221: SOAP 1.2 요청에 application/soap+xml 동작 매개 변수가 있는 경우, 해당 WSDL 바인딩의 soapAction 요소 내에 있는 wsoap12:operation 속성(attribute)과 일치해야 합니다.
R2222: application/soap+xml 동작 매개 변수는 SOAP 1.2 메시지에 포함될 경우 WS-Addressing 2004/08 또는 WS-Addressing 1.0을 사용할 때 wsa:Action와 일치해야 합니다.

WS-Addressing 사용하지 않도록 설정되고 들어오는 요청에 작업 매개 변수가 포함되어 있지 않으면 메시지가 Action 지정되지 않은 것으로 간주됩니다.

WS-Addressing

WCF는 3가지 버전의 WS-Addressing을 구현합니다.

WS-Addressing 2004/08
W3C Web Services Addressing 1.0 Core(ADDR10-CORE) 및 SOAP Binding(ADDR10-SOAP)
WS-Addressing 1.0 - 메타데이터

엔드포인트 참조

WCF에서 구현하는 모든 버전의 WS-Addressing 엔드포인트 참조를 사용하여 엔드포인트를 설명합니다.

엔드포인트 참조 및 WS-Addressing 버전

WCF는 EndpointReference 요소 및 W3C.WsAddressing.EndpointReferenceType 클래스를 사용하는 WS-Addressing을 포함한 여러 인프라 프로토콜(예: WS-ReliableMessaging, WS-SecureConversation 및 WS-Trust)을 구현합니다. WCF는 다른 인프라 프로토콜과 함께 두 버전의 WS-Addressing 사용을 지원합니다. WCF 엔드포인트는 엔드포인트당 하나의 버전의 WS-Addressing 지원합니다.

R3111의 경우 WCF 엔드포인트와 교환된 메시지에 사용되는 요소 또는 형식의 네임스페이스는 EndpointReference 이 엔드포인트에서 구현한 WS-Addressing 버전과 일치해야 합니다.

예를 들어, WS-ReliableMessaging을 구현한 WCF 엔드포인트에서는 AcksTo로부터 반환된 CreateSequenceResponse 헤더가 이 엔드포인트에 대해 EncodingBinding 요소가 지정한 WS-Addressing 버전을 사용합니다.

엔드포인트 참조 및 메타데이터

다양한 시나리오에서는 지정된 엔드포인트에 대한 메타데이터 또는 메타데이터에 대한 참조를 전달해야 합니다.

B3121: WCF는 MEX(WS-MetadataExchange) 사양 섹션 6에 설명된 메커니즘을 사용하여 값 또는 참조로 엔드포인트 참조에 대한 메타데이터를 포함합니다.

WCF 서비스에서 토큰 발급자가 http://sts.fabrikam123.com발급한 SAML(Security Assertions Markup Language) 토큰을 사용하여 인증이 필요한 시나리오를 고려합니다. WCF 엔드포인트는 토큰 발급자를 가리키는 중첩된 sp:IssuedToken 어설션과 함께 sp:Issuer 어설션을 사용하여 이 인증 요구 사항을 설명합니다. 어설션에 액세스하는 클라이언트 애플리케이션은 sp:Issuer 토큰 발급자 엔드포인트와 통신하는 방법을 알아야 합니다. 클라이언트는 토큰 발급자 관련 메타데이터를 알고 있어야 합니다. WCF는 MEX에 정의된 엔드포인트 참조 메타데이터 확장을 사용하여 토큰 발급자 메타데이터에 대한 참조를 제공합니다.

<sp:IssuedToken>
  <sp:Issuer>
    <wsa10:Address>
      http://sts.fabrikam123.com
    </wsa10:Address>
    <wsa10:Metadata>
      <mex:Metadata>
        <mex:MetadataSection>
          <mex:MetadataReference>
            <wsa10:Address>
              http://sts.fabrikam123.com/mex
            </wsa10:Address>
          </mex:MetadataReference>
        </mex:MetadataSection>
      </mex:Metadata>
    </wsa10:Metadata>
  </sp:Issuer>
</sp:IssuedToken>

메시지 주소 지정 헤더

메시지 헤더

두 WS-Addressing 버전의 경우 WCF는 사양에 따라 wsa:To, wsa:ReplyTo, wsa:Action, wsa:MessageID, wsa:RelatesTo와 같은 메시지 헤더를 사용합니다.

B3211: 모든 WS-Addressing 버전의 경우 WCF는 메시지 헤더 wsa:FaultTo 를 wsa:FromWS-Addressing.

WCF 애플리케이션과 상호 작용하는 애플리케이션은 이러한 메시지 헤더를 추가할 수 있으며 WCF는 이에 따라 이를 처리합니다.

참조 매개 변수 및 속성

WCF는 각 사양에 따라 엔드포인트 참조 매개 변수 및 참조 속성의 처리를 구현합니다.

B3221: WS-Addressing 2004/08을 사용하도록 구성된 경우 WCF 엔드포인트는 참조 속성 처리와 참조 매개 변수를 구분하지 않습니다.

메시지 교환 패턴

웹 서비스 작업 호출과 관련된 메시지 시퀀스를 메시지 교환 패턴이라고 합니다. WCF는 단방향, 요청-회신 및 이중 메시지 교환 패턴을 지원합니다. 이 섹션에서는 사용 중인 메시지 교환 패턴에 따라 메시지 처리에 대한 WS-Addressing 요구 사항을 명확히 설명합니다.

이 섹션 전체에서 요청자는 첫 번째 메시지를 보내고 응답자는 첫 번째 메시지를 받습니다.

One-Way 메시지

WCF 엔드포인트가 단방향 패턴을 따르도록 지정된 Action 메시지를 지원하도록 구성된 경우 WCF 엔드포인트는 다음과 같은 동작 및 요구 사항을 따릅니다. 달리 지정하지 않는 한 WCF에서 지원되는 두 버전의 WS-Addressing 동작 및 규칙이 적용됩니다.

R3311: 요청자는 엔드포인트 참조로 지정된 모든 참조 매개 변수에 대해 wsa:To, wsa:Action, 그리고 헤더를 포함해야 합니다. WS-Addressing 2004/08을 사용하고 엔드포인트 참조로 [참조 속성]을 지정하는 경우 해당 헤더도 메시지에 추가해야 합니다.
B3312: 요청자는 MessageID, ReplyTo, 및 FaultTo 헤더를 포함할 수 있습니다. 수신기 인프라는 이를 무시하고 애플리케이션에 전달됩니다.
R3313: HTTP가 사용되고 HTTP 응답 레그에 메시지가 전송되지 않는 경우 응답자는 빈 본문과 HTTP 202 상태 코드를 사용하여 HTTP 응답을 보내야 합니다.

HTTP 전송이 사용 중이고 작업 계약이 메시지를 단방향으로 선언하는 경우 인프라 메시지를 보내는 데 HTTP 응답을 계속 사용할 수 있습니다. 예를 들어 신뢰할 수 있는 메시징은 HTTP 응답에 메시지를 보낼 SequenceAcknowledgement 수 있습니다.
B3314: WCF 응답자는 단방향 메시지에 대한 응답으로 오류 메시지를 보내지 않습니다.

Request-Reply

요청-회신 패턴을 따르도록 지정된 Action 메시지에 대해 WCF 엔드포인트가 구성된 경우 WCF 엔드포인트는 아래의 동작 및 요구 사항을 따릅니다. 달리 지정하지 않는 한 WCF에서 지원되는 두 버전의 WS-Addressing 동작 및 규칙이 적용됩니다.

R3321: 요청에는 엔드포인트 참조로 지정된 모든 참조 매개변수나 참조 속성(또는 둘 다), wsa:To, wsa:Action, wsa:MessageID 및 헤더가 포함되어야 합니다.
R3322: WS-Addressing 2004/08이 사용될 때, ReplyTo도 요청에 포함해야 합니다.
R3323: WS-Addressing 1.0이 사용되고 ReplyTo 요청에 없는 경우 [address] 속성이 같은 http://www.w3.org/2005/08/addressing/anonymous 기본 엔드포인트 참조가 사용됩니다.
R3324: 요청자는 회신 메시지에 wsa:To, wsa:Action, wsa:RelatesTo 헤더와 요청의 ReplyTo 엔드포인트 참조에 의해 지정된 모든 참조 매개 변수 또는 참조 속성(또는 둘 다)에 대한 헤더를 포함해야 합니다.

웹 서비스 오류 해결

R3411: WCF는 WS-Addressing 2004/08에서 정의한 다음과 같은 오류를 생성합니다.

코드	원인
`wsa:DestinationUnreachable`	이 채널에 대해 설정된 회신 주소와 다른 `ReplyTo`와 함께 메시지가 도착했습니다. To 헤더에 명시된 주소에서 수신하는 엔드포인트가 없습니다.
`wsa:ActionNotSupported`	엔드포인트와 연결된 인프라 채널 또는 디스패처가 헤더에 `Action` 지정된 작업을 인식하지 않습니다.

R3412: WCF는 WS-Addressing 1.0으로 정의된 다음 오류를 생성합니다.

코드	원인
`wsa10:InvalidAddressingHeader`	복제 `wsa:To`, `wsa:ReplyTo`, `wsa:From` 또는 `wsa:MessageID`. `wsa:RelatesTo`와 동일한 `RelationshipType`을 복제합니다.
`wsa10:MessageAddressingHeaderRequired`	필요한 주소 지정 헤더가 없습니다.
`wsa10:DestinationUnreachable`	이 채널에 `ReplyTo` 대해 설정된 회신 주소와 다른 메시지와 함께 메시지가 도착했습니다. To 헤더에 지정된 주소에서 수신 대기하는 엔드포인트가 없습니다.
`wsa10:ActionNotSupported`	헤더에 `Action` 지정된 작업은 엔드포인트와 연결된 인프라 채널 또는 디스패처에서 인식되지 않습니다.
`wsa10:EndpointUnavailable`	RM 채널은 `CreateSequence` 메시지의 주소 지정 헤더 검사를 기반으로 엔드포인트가 시퀀스를 처리하지 않음을 나타내는 이 오류를 다시 전달합니다.

SOAP 1.1의 경우 FaultCode 에, SOAP 1.2의 경우 (코드=발신자)에는 SubCode 에 매핑됩니다.

WSDL 1.1 바인딩 및 WS-Policy 어설션

WS-Addressing 사용 표시

WCF는 정책 어설션을 사용하여 특정 WS-Addressing 버전에 대한 엔드포인트 지원을 나타냅니다.

다음 정책 어설션에는 엔드포인트 정책 주체 [WS-PA]가 있으며 엔드포인트에서 보내고 받은 메시지가 2004/08 WS-Addressing 사용해야 임을 나타냅니다.

<wsap:UsingAddressing />

이 정책 어설션은 WS-Addressing 2004/08 사양을 보강합니다.

다음 정책 어설션은 전송/수신된 메시지가 WS-Addressing 1.0을 사용해야 임을 나타냅니다.

<wsam:Addressing/>

다음 정책 어설션에는 엔드포인트 정책 주체 [WS-PA]가 있으며 엔드포인트에서 보내고 받은 메시지가 2004/08 WS-Addressing 사용해야 임을 나타냅니다.

<wsaw10:UsingAddressing />

요소는 wsaw10:UsingAddressing [WS-Addressing-WSDL]에서 대여되며 해당 사양인 섹션 3.1.2에 따라 WS-Policy 컨텍스트에서 사용됩니다.

주소 지정을 사용하면 WSDL 1.1, SOAP 1.1 및 SOAP 1.2 HTTP 바인딩의 의미 체계가 변경되지 않습니다. 예를 들어 Addressing 및 WSDL SOAP 1.x HTTP 바인딩을 사용하는 엔드포인트로 전송되는 요청에 회신이 필요한 경우 HTTP 응답을 사용하여 회신을 보내야 합니다.

http 응답을 통해 전송된 회신의 경우 WS-AM 어설션은 다음과 같습니다.

<wsam:AnonymousResponses/>

전체 정책 어설션은 다음과 같을 수 있습니다.

<wsam:Addressing>
    <wsp:Policy>
        <wsam:AnonymousResponses />
    </wsp:Policy>
</wsam:Addressing>

그러나 요청자와 응답자 간에 두 개의 독립적인 대화 HTTP 연결을 설정하면 도움이 되는 메시지 교환 패턴이 있습니다(예: 응답자가 보낸 원치 않는 단방향 메시지).

WCF는 두 개의 기본 전송 채널이 복합 이중 채널을 형성할 수 있는 기능을 제공합니다. 여기서 한 채널은 입력 메시지에 사용되고 다른 채널은 출력 메시지에 사용됩니다. HTTP 전송의 경우 복합 이중은 두 개의 대화형 HTTP 연결을 제공합니다. 요청자는 하나의 연결을 사용하여 메시지를 응답자에게 보내고, 응답자는 다른 연결을 사용하여 메시지를 다시 요청자에게 보냅니다.

별도의 http 요청을 통해 전송된 회신의 경우 ws-am 어설션은

<wsam:NonAnonymousResponses/>

전체 정책 어설션은 다음과 같을 수 있습니다.

<wsam:Addressing>
    <wsp:Policy>
        <wsam:NonAnonymousResponses />
    </wsp:Policy>
</wsam:Addressing>

WSDL 1.1 SOAP 1.x HTTP 바인딩을 사용하는 엔드포인트에서 엔드포인트 정책 주체 [WS-PA]가 있는 다음 어설션을 사용하려면 요청자에서 응답자로 흐르는 메시지와 요청자에게 각각 두 개의 별도 대화형 HTTP 연결을 사용해야 합니다.

<cdp:CompositeDuplex/>

이전 문장은 요청 메시지의 헤더에 대한 wsa:ReplyTo 다음과 같은 요구 사항으로 이어집니다.

R3514: 엔드포인트가 WSDL 1.1 SOAP 1.x HTTP 바인딩을 사용하고 ReplyTo 또는 [address] 어설션이 http://www.w3.org/2005/08/addressing/anonymous에 연결된 정책 대안을 가진 경우, 해당 엔드포인트로 전송된 요청 메시지는 속성이 wsap10:UsingAddressing와 같지 않은 wsap:UsingAddressing 헤더를 포함해야 합니다.
R3515: 엔드포인트가 WSDL 1.1 SOAP 1.x HTTP 바인딩을 사용하고, ReplyTo 어설션 없이 [address] 어설션을 포함한 정책 대안을 가지고 있는 경우, 엔드포인트로 전송되는 요청 메시지에는 http://www.w3.org/2005/08/addressing/anonymous 속성이 ReplyTo인 wsap10:UsingAddressing 헤더가 반드시 있어야 하며, 그렇지 않으면 cdp:CompositeDuplex 헤더가 전혀 없어야 합니다.
R3516: 엔드포인트가 WSDL 1.1 SOAP 1.x HTTP 바인딩을 사용하고, ReplyTo 어설션이 있고 [address] 어설션이 없는 정책 대안을 가지고 있는 경우, 엔드포인트로 전송된 요청 메시지에는 http://www.w3.org/2005/08/addressing/anonymous 속성이 wsap:UsingAddressing인 cdp:CompositeDuplex 헤더가 있어야 합니다.

WS-addressing WSDL 사양은 <wsaw:Anonymous/> 헤더(섹션 3.2)에 대한 요구 사항을 나타내기 위해 필수, 선택 사항, 금지됨이라는 세 가지 텍스트 값을 가진 wsa:ReplyTo 요소를 도입하여 유사한 프로토콜 바인딩을 설명하려고 시도합니다. 아쉽게도 이러한 요소 정의는 WS-Policy 컨텍스트에서 어설션으로 특별히 사용할 수 없습니다. 이러한 요소를 어설션으로 사용하는 대안의 교집합을 지원하기 위해 도메인별 확장이 필요하기 때문입니다. 또한 이러한 요소 정의는 와이어의 엔드포인트 동작과 달리 헤더 값을 ReplyTo 나타내며 이는 HTTP 전송과 관련이 있습니다.

작업 정의

WS-Addressing 2004/08은 wsa:Action 요소에 대한 wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] 속성을 정의합니다. WS-Addressing 1.0 WSDL 바인딩(WS-ADDR10-WSDL)은 유사한 특성을 wsaw10:Action정의합니다.

둘 사이의 유일한 차이점은 WS-ADDR10-WSDL의 WS-ADDR 섹션 3.3.2 및 섹션 4.4.4에 설명된 기본 작업 패턴 의미 체계입니다.

동일한 portType (또는 WCF 용어에서 계약)을 공유하지만 다른 버전의 WS-Addressing을 사용하는 두 개의 엔드포인트가 있는 것이 합리적입니다. 그러나 동작이 정의 portType 되어 있고 이를 구현 portType하는 엔드포인트에서 변경해서는 안 된다는 점을 감안할 때 두 기본 작업 패턴을 모두 지원하는 것은 불가능해집니다.

이 논란을 해결하기 위해 WCF는 특성의 Action 단일 버전을 지원합니다.

B3521: WCF는 WS-ADDR10-WSDL에 정의된 요소에서 wsaw10:Action 특성을 사용하여 wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] 엔드포인트가 사용하는 WS-Addressing 버전과 관계없이 해당 메시지에 대한 URI를 Action 결정합니다.

WSDL 포트 내에서 엔드포인트 참조 사용

WS-ADDR10-WSDL 섹션 4.1은 wsdl:port 요소를 <wsa10:EndpointReference…/> 자식 요소가 포함되도록 확장하여, WS-Addressing 용어로 엔드포인트를 설명합니다. WCF는 2004/08에 WS-Addressing을 확장하여 <wsa:EndpointReference…/>의 자식 요소로 wsdl:port가 나타날 수 있도록 합니다.

R3531: 엔드포인트에 정책 어설션이 <wsaw10:UsingAddressing/> 있는 연결된 정책 대안이 있는 경우 해당 wsdl:port 요소에 자식 요소가 <wsa10:EndpointReference …/>포함될 수 있습니다.
R3532: wsdl:port 요소에 자식 요소로 <wsa10:EndpointReference …/>가 포함된 경우, wsa10:EndpointReference/wsa10:Address 자식 요소의 값은 형제 @addresswsdl:port/ 요소의 wsdl:location 특성 값과 일치해야 합니다.
R3533: 엔드포인트에 정책 어설션이 <wsap:UsingAddressing/> 포함된 연결된 정책 대안이 있는 경우 해당 wsdl:port 요소에 자식 요소가 <wsa:EndpointReference …/>포함될 수 있습니다.
R3534: wsdl:port에 자식 요소 <wsa:EndpointReference …/>가 포함된 경우, wsa:EndpointReference/wsa:Address 자식 요소의 값은 형제 @addresswsdl:port/ 요소의 wsdl:location 특성 값과 일치해야 합니다.

WS-Security 있는 컴퍼지션

WS-ADDR 및 WS-ADDR10의 보안 고려 사항 섹션에 따르면 모든 주소 지정 메시지 헤더를 함께 바인딩하려면 메시지 본문과 함께 서명하는 것이 좋습니다.

WS-Security 메시지 무결성 보호에 사용되는 경우 WS-Addressing 메시지 헤더와 참조 매개 변수 또는 속성(또는 둘 다)에서 생성된 헤더를 메시지 본문과 함께 서명해야 합니다.

예시

One-Way 메시지

이 시나리오에서 발신자는 받는 사람에게 단방향 메시지를 보냅니다. SOAP 1.2, HTTP 1.1 및 W3C WS-Addressing 1.0이 사용됩니다.

요청 메시지 구조: 메시지 헤더에는 wsa10:To 및 wsa10:Action 요소가 포함됩니다. 메시지 본문에는 애플리케이션 네임스페이스의 특정 <app:Ping> 요소가 포함됩니다.

HTTP 헤더: POST의 대상이 요소의 URI와 일치합니다 wsa10:To .

Content-Type 헤더의 값 application/soap+xml 은 SOAP 1.2에 필요한 값입니다. 매개 변수 charset 및 action 포함됩니다. Content-Type 헤더의 매개 변수는 action 메시지 헤더의 값과 일치합니다 wsa10:Action .

POST http://fabrikam123.com/Service HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8;  
              action="http://fabrikam123.com/Service/OneWay"
Host: 131.107.72.15
Content-Length: 1501
Expect: 100-continue
Proxy-Connection: Keep-Alive
<s12:Envelope>
  <s12:Header>
    <wsa10:To s12:mustUnderstand="1">
        http://fabrikam123.com/Service
    </wsa10:To>
    <wsa10:Action s12:mustUnderstand="1">
        http://fabrikam123.com/Service/OneWay
    </wsa10:Action>
  </s12:Header>
  <s12:Body>
    <Ping xmlns="http://fabrikam123.com/Service/">
      <Text>Hello World</Text>
    </Ping>
  </s12:Body>
</s12:Envelope>

수신자가 빈 HTTP 응답 및 상태 202로 응답합니다. HTTP 응답의 예:

HTTP/1.1 202 Accepted
Date: Fri, 15 Jul 2005 08:56:07 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50215
Cache-Control: private
Content-Length: 0

SOAP 메시지 전송 최적화 메커니즘

이 섹션에서는 HTTP SOAP MTOM에 대한 WCF 구현 세부 정보를 설명합니다. MTOM 기술은 기존 텍스트/XML 인코딩 또는 WCF 이진 인코딩과 동일한 클래스의 SOAP 메시지 인코딩 메커니즘입니다. MTOM에는 다음이 포함됩니다.

base64로 인코딩된 이진 데이터를 포함하는 XML 정보 항목을 별도의 이진 부분으로 최적화하는 [XOP]에서 설명하는 XML 인코딩 및 패키징 메커니즘입니다.
XML Infoset 및 XOP 패키지의 각 이진 부분을 별도의 MIME 부분으로 직렬화하는 XOP 패키지의 MIME 캡슐화입니다.
SOAP 1.x Envelope에 적용된 MIME XOP 인코딩입니다.
HTTP 전송 바인딩입니다.

WCF에서 비 HTTP 전송과 함께 MTOM을 사용할 수 있습니다. 그러나 이 항목에서는 HTTP에 집중합니다.

MTOM 형식은 MTOM 자체, XOP 및 MIME를 포함하는 많은 사양 집합을 활용합니다. 이 사양 집합의 모듈화는 형식 및 처리 의미 체계에 대한 정확한 요구 사항을 재구성하기가 다소 어렵습니다. 이 섹션에서는 MTOM HTTP 바인딩에 대한 형식 및 처리 요구 사항을 설명합니다.

MTOM 메시지 인코딩

MTOM 메시지 생성

[XOP] 섹션 3.1에서는 base64 값을 포함하는 요소 정보 항목을 사용하여 XML을 추상적으로 정의된 XOP 패키지로 인코딩하는 프로세스를 설명합니다.

다음 단계 시퀀스는 MTOM별 인코딩 프로세스에 대해 설명합니다.

인코딩할 SOAP 봉투에 [namespace name]가 http://www.w3.org/2004/08/xop/include이고 [local name]가 Include인 요소 정보 항목이 포함되어 있지 않은지 확인합니다.
빈 MIME 패키지를 만듭니다.
원래 XML Infoset 내에서 최적화할 요소 정보 항목을 식별합니다. 최적화할 항목의 경우 요소 정보 항목을 구성하는 [children] 문자는 정식 형식 xs:base64Binary (XSD-2, 3.2.16 base64Binary 참조)이어야 하며 공백이 아닌 콘텐츠의 앞, 인라인 또는 다음에 공백 문자를 포함해서는 안 됩니다.
원본 SOAP 봉투의 복사본을 만들되, 이전 단계에서 식별된 각 요소 정보 항목의 자식들이 다음과 같이 생성된 xop:Include 요소 정보 항목으로 대체된 XOP SOAP 봉투가 되도록 합니다.
1. 바뀐 문자를 base64로 인코딩된 데이터로 처리하여 이진 데이터로 변환합니다.
2. 요구 사항 R3133 및 R3134를 충족하는 고유한 Content-ID 헤더 값을 생성합니다.
3. 값 이진을 사용하여 Content-Transfer-Encoding MIME 헤더를 생성합니다.
4. 최적화 중인 요소 정보 항목(새로 삽입된 xop:Include 요소 정보 항목의 [부모])에 특성 정보 항목이 xmime:contentType 있는 경우 특성 값이 있는 Content-Type MIME 헤더를 xmime:contentType 생성합니다.
5. base64로 처리된 대체 문자에서 디코딩된 이진 데이터로 구성된 콘텐츠를 사용하여 새 이진 MIME 파트를 생성하고, 4b의 Content-ID 헤더, 4c의 Content-Transfer-Encoding 헤더, 4d단계에서 생성된 경우 Content-Type 헤더를 생성합니다.
6. 4b단계에서 생성된 Content-ID 헤더 값에서 파생된 cid: uri 값을 href 요소의 xop:Include 특성으로 추가합니다. 바깥쪽 "<" 및 ">" 문자를 제거하고, 남은 문자열을 URL 형식으로 변환한 후, cid: 접두사를 추가합니다. RFC1738 및 RFC2396에 따라 다음 최소 문자 집합은 이스케이프해야 합니다. 다른 문자는 이스케이프할 수 있습니다.
```
Hexadecimal 00-1F , 7F, 20, "<" | ">" | "#" | "%" | <">
"{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" | "~" | "^"
```
4단계에서 XOP SOAP 봉투를 사용하여 루트 MIME 파트를 만듭니다.
HTTP Content-Type 헤더를 포함하여 HTTP 헤더를 작성합니다.
MIME 패키지를 작성합니다.

MTOM 메시지 처리

MTOM 메시지 처리는 앞의 "MTOM 메시지 생성" 섹션에서 설명한 프로세스의 정확한 반대입니다.

루트 MIME 부분에 Content-Type application/xop+xml이 있는지 확인합니다.
패키지의 루트 MIME 부분을 XML 문서로 구문 분석하여 SOAP 봉투를 생성합니다. 문자 인코딩은 루트 MIME 파트의 Content-Type 매개 변수에 의해 charset 결정됩니다.
구성된 SOAP Envelope의 각 요소 정보 항목 중 [children] 속성의 유일한 구성원이 xop:Include 요소 정보 항목인 경우:
1. cid: 접두사를 제거하고 @href 요소의 xop:Include 속성 값에서 모든 URI 이스케이프 시퀀스(RFC 2396)를 해제합니다. 결과 문자열을 "",< ">"로 묶습니다.
2. 3a단계에서 파생된 문자열과 일치하는 Content-ID 헤더 값이 있는 MIME 부분을 찾습니다.
3. xop:Include 각 항목의 속성에 표시되는 요소 정보 항목을 3b단계에서 children 식별된 MIME 파트의 엔터티 본문에 대한 정식 base64 인코딩(XSD-2, 3.2.16 base64Binary 참조)을 나타내는 문자 정보 항목으로 바꿉니다(요소 정보 항목을 패키지 파트에서 재구성된 데이터로 효과적으로 대체xop:Include).

HTTP 콘텐츠 형식 헤더

다음은 MTOM 사양 자체에 명시된 요구 사항에서 파생되고 MTOM 및 RFC 2387에서 파생된 SOAP 1.x MTOM 인코딩 메시지의 HTTP Content-Type 헤더 형식에 대한 WCF 설명 목록입니다.

R4131: HTTP Content-Type 헤더에는 대소문자를 구분하지 않는 다중 파트/관련 값과 해당 매개변수가 있어야 합니다. 매개 변수 이름은 대/소문자를 구분하지 않습니다. 매개 변수 순서는 중요하지 않습니다.
MIME 메시지에 대한 Content-Type 헤더의 전체 Backus-Naur 양식(BNF)은 RFC 2045 섹션 5.1에 나열됩니다.
R4132: HTTP Content-Type 헤더에는 값이 큰따옴표로 묶인 형식 매개 변수가 있어야 합니다.

RFC 2387에서는 큰따옴표를 사용해야 하는 요구 사항이 명시적이지 않지만 텍스트는 모든 다중 파트/관련 미디어 형식 매개 변수에 "@" 또는 "/"와 같은 예약 문자를 포함할 가능성이 높으므로 큰따옴표가 필요합니다.

R4133: HTTP Content-Type 헤더에는 큰따옴표로 묶인 SOAP 1.x 봉투가 포함된 MIME 파트의 Content-ID 헤더 값이 있는 시작 매개 변수가 있어야 합니다. 시작 매개 변수를 생략하면 첫 번째 MIME 부분에 SOAP 1.x Envelope가 포함되어야 합니다.
R4134: SOAP 1.1 MTOM으로 인코딩된 메시지에 대한 HTTP Content-Type 헤더에는 큰따옴표로 묶인 text/xml 값이 포함된 시작 정보 매개 변수가 포함되어야 합니다.
R4135: SOAP 1.2 MTOM으로 인코딩된 메시지에 대한 HTTP Content-Type 헤더에는 큰따옴표로 묶인 값 application/soap+xml이 포함된 시작 정보 매개 변수가 포함되어야 합니다.

R4136: SOAP 1.x MTOM으로 인코딩된 메시지의 HTTP 콘텐츠 형식 헤더에는 RFC 2046, 섹션 5.1.1에 정의된 MIME 경계 BNF와 일치하는 값(큰따옴표로 묶음)이 있는 경계 매개 변수가 있어야 합니다.

boundary := 0*69<bchars> bcharsnospace
bchars := bcharsnospace / " "
bcharsnospace :=    DIGIT / ALPHA / "'" / "(" / ")" / "+"
                    / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"

예제:

맞는

Content-Type: multipart/related; type="application/xop+xml";start=" <part0@tempuri.org>";boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1";start-info="text/xml"

맞는

Content-Type: Multipart/Related; type="application/xop+xml";start-info="text/xml";boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1"

잘못된

Content-Type: Multipart/Related; type=application/xop+xml;start=" <part0@tempuri.org>";start-info="text/xml";boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1"

Infoset MIME 파트

SOAP 1.x Envelope는 XOP MIME 패키지의 루트 부분으로 캡슐화되며 종종 infoset 파트라고 불립니다.

R4141: SOAP 1.x Envelope는 'c0' 파트라고 불리는, 그리고 HTTP Content-Type에서 참조되는 XOP MIME 패키지의 루트 부분으로 캡슐화되어야 합니다.
R4142: SOAP Infoset 파트는 다음 MIME 헤더를 Content-IDContent-Transfer-Encoding포함해야 합니다. Content-Type

Content-ID 헤더의 형식은 RFC 2045에서 다음과 같이 정의됩니다.

"Content-ID" ":" msg-id

여기서 msg-id RFC 2822(RFC 2045에서 참조되는 RFC 822를 대체)에 다음과 같이 정의됩니다.

msg-id    =       [CFWS] "<" id-left "@" id-right ">" [CFWS]

"<"와 ">" 사이에 포함된 전자 메일 주소입니다. [CFWS] 접두사와 접미사는 주석을 전달하기 위해 RFC 2822에 추가되었으며 상호 운용성을 유지하는 데 사용하면 안 됩니다.

R4143: Infoset MIME 파트의 Content-ID 헤더 값은 msg-id 접두사 및 접미사 부분이 생략된 상태에서 RFC 2822의 [CFWS] 프로덕션을 따라야 합니다.

"많은 MIME 구현에서 전자 메일 주소로 묶이는 대신 "<" 및 ">"로 묶인 값에 대한 요구 사항을 완화하고, 전자 메일 주소 외에도 "absoluteURI"를 "<", ">"로 묶어 사용했습니다." 이 버전의 WCF는 양식의 Content-ID MIME 헤더 값을 사용합니다.

Content-ID: <http://tempuri.org/0>

R4144: MTOM 프로세서는 다음과 같은 완화 msg-id된 내용과 일치하는 Content-ID 헤더 값을 허용해야 합니다.

msg-id-relaxed =     [CFWS] "<" (absoluteURI | mail-address) ">" [CFWS]
mail-address   =     id-left "@" id-right

MIME(RFC 2045)는 MIME 파트의 콘텐츠 인코딩을 통신하는 Content-Transfer-Encoding 헤더를 제공합니다. Content-Transfer-Encoding 정의된 기본값은 대부분의 SOAP 메시지에 적합하지 않은 7비트이므로 상호 운용성을 높이기 위해 Content-Transfer-Encoding 헤더가 필요합니다.

R4145: SOAP Infoset 부분에 Content-Transfer-Encoding 헤더가 포함되어야 합니다.
R4146: SOAP Envelope 문자 인코딩이 UTF-8인 경우 Content-Transfer-Encoding 헤더의 값은 8비트여야 합니다.
R4147: SOAP Envelope 문자 인코딩이 UTF-16인 경우 Content-Transfer-Encoding 헤더의 값은 이진이어야 합니다.
[XOP] 섹션 5에 따르면
R4148: SOAP1.1 Infoset 파트에는 미디어 타입 애플리케이션/xop+xml과 매개변수 type="text/xml" 및 charset을 포함한 Content-Type 헤더가 있어야 합니다.
```
Content-Type: application/xop+xml;
              charset=utf-8;type="text/xml"
```
R4149: SOAP 1.2 Infoset 파트에는 미디어 형식 application/xop+xml 및 매개 변수 형식이 있는 Content-Type 헤더가 포함되어야 합니다.""application/soap+xml 및 charset.
```
Content-Type: application/xop+xml;
              charset=utf-8;type="application/soap+xml"
```
XOP는 charset에 대한 application/xop+xml 매개 변수를 선택 사항으로 정의하지만, charset 미디어 유형의 text/xml 매개 변수에 대한 BP 1.1 요구 사항과 유사하게 상호 운용성을 위해 필요합니다.
R41410: SOAP 1.x Infoset 파트의 Content-Type 헤더에는 매개 변수 type와 charset가 모두 있어야 합니다.

MTOM에 대한 WCF 엔드포인트 지원

MTOM의 목적은 BASE64로 인코딩된 데이터를 최적화하기 위해 SOAP 메시지를 인코딩하는 것입니다. 다음은 제약 조건 목록입니다.

R4151: base64로 인코딩된 데이터를 포함하는 모든 요소 정보 항목을 최적화할 수 있습니다.
B4152: WCF는 base64로 인코딩된 데이터를 포함하고 길이가 1024바이트인 요소 정보 항목을 최적화합니다.

MTOM을 사용하도록 구성된 WCF 엔드포인트는 항상 MTOM으로 인코딩된 메시지를 보냅니다. 필요한 조건을 충족하는 파트가 없더라도 메시지는 여전히 MTOM으로 인코딩됩니다(SOAP 봉투가 포함된 단일 MIME 부분이 있는 MIME 패키지로 직렬화됨).

WS-Policy MTOM에 대한 어설션

WCF는 다음 정책 어설션을 사용하여 엔드포인트별 MTOM 사용을 나타냅니다.

<wsoma:OptimizedMimeSerialization />

R4211: 이전 정책 어설션에는 엔드포인트 정책 주체가 있으며, 엔드포인트에서 보내고 받는 모든 메시지가 MTOM을 사용하여 최적화되어야 한다고 지정합니다.
B4212: MTOM 최적화를 사용하도록 구성된 경우 WCF 엔드포인트는 해당 wsdl:binding정책에 연결된 정책에 MTOM 정책 어설션을 추가합니다.

WS-Security 있는 컴퍼지션

MTOM은 WCF 이진 XML과 유사한 text/xml 인코딩 메커니즘입니다. MTOM은 WS-Security 및 기타 WS-* 프로토콜을 사용하여 자연 컴퍼지션을 제공합니다. WS-Security 사용하여 보호되는 메시지는 MTOM을 사용하여 최적화할 수 있습니다.

예시

MTOM을 사용하여 인코딩된 WCF SOAP 1.1 메시지

POST http://131.107.72.15/Mtom/svc/service.svc/Soap11MtomUTF8 HTTP/1.1
SOAPAction: "http://xmlsoap.org/echoBinaryAsString"
Content-Type: multipart/related;type="application/xop+xml";
              start="<http://tempuri.org/0>";start-info="text/xml";
       boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1"
Host: 131.107.72.15
Content-Length: 1501
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body>
    <EchoBinaryAsString xmlns="http://xmlsoap.org/Ping">
      <array>
        <xop:Include
         href="cid:http%3A%2F%2Ftempuri.org%2F1%2F632618206521093670"
         xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
      </array>
    </EchoBinaryAsString>
  </s:Body>
</s:Envelope>
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1
Content-ID: <http://tempuri.org/1/632618206521093670>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
…Binary Content..
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=1

MTOM을 사용하여 인코딩된 WCF 보안 SOAP 1.2 메시지

이 예제에서는 WS-Security를 사용하여 보호되는 MTOM 및 SOAP 1.2를 사용하여 메시지를 인코딩합니다. 인코딩 BinarySecurityTokenCipherValueEncryptedData 에 대해 식별된 이진 부분은 암호화된 서명 및 암호화된 본문에 해당하는 내용입니다. WCF에서는 CipherValue의 EncryptedKey가 최적화를 위해 식별되지 않았는데, 그 이유는 길이가 1024바이트 미만이기 때문입니다.

POST http://131.107.72.15/Mtom/service.svc/Soap12MtomSecureSignEncrypt HTTP/1.1
Content-Type: multipart/related; type="application/xop+xml";
              start="<http://tempuri.org/0>";
            boundary="uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3";
              start-info="application/soap+xml";
              action="http://xmlsoap.org/echoBinaryAsString"
Host: 131.107.72.15
Content-Length: 1941
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="application/soap+xml"
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
  <s:Header>
    <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <u:Timestamp u:Id="uuid-4d4ee765-5717-4d53-9ac9-99bddc07df6c-5">
        <u:Created>2005-09-09T06:57:32.488Z</u:Created>
        <u:Expires>2005-09-09T07:02:32.488Z</u:Expires>
      </u:Timestamp>
      <o:BinarySecurityToken u:Id="uuid-4d4ee765-5717-4d53-9ac9-99bddc07df6c-2" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
        <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F1%2F632618206525089430" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
      </o:BinarySecurityToken>
      <e:EncryptedKey Id="_1" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
        <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <o:SecurityTokenReference>
            <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">Xeg55vRyK3ZhAEhEf+YT0z986L0=</o:KeyIdentifier>
          </o:SecurityTokenReference>
        </KeyInfo>
        <e:CipherData>          <e:CipherValue>oQfpxwT8/SAGyZQzKE2b4yO6dXuQj7pwJ+5CGL3Rf7C06bQ5ttMoQ9GLJcQYkXTzin+WwHEgs5bj5ml9HKTW9QAU5JJ6lksdymmQvWP5ZtGPBVchO4sofEGoCKmBiZL/DYS/cnbzgnc/3a6NYnc10y2fWGaGLiqa00zijAw7o0Y=</e:CipherValue>
        </e:CipherData>
      </e:EncryptedKey>
      <c:DerivedKeyToken u:Id="_2" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
        <o:SecurityTokenReference>
          <o:Reference URI="#_1"/>
        </o:SecurityTokenReference>
        <c:Nonce>OrEPRX7fISIS4sXYWPMv3g==</c:Nonce>
      </c:DerivedKeyToken>
      <e:ReferenceList xmlns:e="http://www.w3.org/2001/04/xmlenc#">
        <e:DataReference URI="#_3"/>
        <e:DataReference URI="#_4"/>
      </e:ReferenceList>
      <e:EncryptedData Id="_4" Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
        <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <o:SecurityTokenReference>
            <o:Reference URI="#_2"/>
          </o:SecurityTokenReference>
        </KeyInfo>
        <e:CipherData>
          <e:CipherValue>
            <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F2%2F632618206525089430" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
          </e:CipherValue>
        </e:CipherData>
      </e:EncryptedData>
    </o:Security>
  </s:Header>
  <s:Body u:Id="_0">
    <e:EncryptedData Id="_3" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
      <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
          <o:Reference URI="#_2"/>
        </o:SecurityTokenReference>
      </KeyInfo>
      <e:CipherData>
        <e:CipherValue>
          <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F3%2F632618206525089430" xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
        </e:CipherValue>
      </e:CipherData>
    </e:EncryptedData>
  </s:Body>
</s:Envelope>
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3
Content-ID: <http://tempuri.org/1/632618206525089430>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
...Binary content of BinarySecurityToken - X509 Certificate...
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3
Content-ID: <http://tempuri.org/2/632618206525089430>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
...Binary serialization of the encrypted primary signature...
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3
Content-ID: <http://tempuri.org/3/632618206525089430>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream
...Binary serialization of the encrypted Body...
--uuid:0ca0e16e-feb1-426c-97d8-c4508ada5e82+id=3--

Last updated on 2025-06-17

다음을 통해 공유

메시징 프로토콜

SOAP 1.1 및 SOAP 1.2

봉투 및 처리 모델

필수 헤더 처리

SOAP 오류

HTTP 바인딩

SOAP 1.1 HTTP 바인딩

SOAP 1.2 HTTP 바인딩

WS-Addressing

엔드포인트 참조

엔드포인트 참조 및 WS-Addressing 버전

엔드포인트 참조 및 메타데이터

메시지 주소 지정 헤더

메시지 헤더

참조 매개 변수 및 속성

메시지 교환 패턴

One-Way 메시지

Request-Reply

웹 서비스 오류 해결

WSDL 1.1 바인딩 및 WS-Policy 어설션

WS-Addressing 사용 표시

작업 정의

WSDL 포트 내에서 엔드포인트 참조 사용

WS-Security 있는 컴퍼지션

예시

One-Way 메시지

SOAP 메시지 전송 최적화 메커니즘

MTOM 메시지 인코딩

MTOM 메시지 생성

MTOM 메시지 처리

HTTP 콘텐츠 형식 헤더

Infoset MIME 파트

MTOM에 대한 WCF 엔드포인트 지원

WS-Policy MTOM에 대한 어설션

WS-Security 있는 컴퍼지션

예시

MTOM을 사용하여 인코딩된 WCF SOAP 1.1 메시지

MTOM을 사용하여 인코딩된 WCF 보안 SOAP 1.2 메시지

추가 리소스