Compartir a través de


3.2.3.5.11 Processing Errors

If an implementation of this protocol on the inbound proxy encounters a processing error outside protocol errors, it SHOULD try to send an IN channel response as specified in section 2.1.2.1.3. If an implementation runs out of local resources to create a well-formed IN channel response as defined in this section, it SHOULD close the connection as if a protocol error was encountered as specified in section 3.2.3.5.10. If it is able to create a well-formed IN channel response, an implementation of this protocol performs the following steps:

  • MUST set the status-code to 503.

  • MUST set the RPC-Error field from the IN channel response to a hexadecimal representation of an implementation-specific error code. Windows implementations use Windows error codes as specified in [MS-ERREF].

  • SHOULD set the ee-info part of the reason-phrase from the IN channel response whenever the inbound proxy has additional error information in the format specified in [MS-EERR], as follows: EncodedEEInfo from the IN channel response SHOULD be set to a base64-encoded BLOB of the extended error information, as specified in [MS-EERR]. The base64 encoding MUST be as specified in [RFC4648] section 4. The content of the BLOB itself is specified in [MS-EERR]. Implementations of this protocol SHOULD ensure that the total length of the reason-phrase line does not exceed 1,024 bytes.

  • SHOULD set the message body as specified in section 2.1.2.1.3, and the EncodedEEInfo SHOULD be set to a base64-encoded BLOB. The base64 encoding MUST be as specified in [RFC3548] section 4. The content of the BLOB is as specified in [MS-EERR].