6 Appendix A: Product Behavior

  • Article

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

  • Windows NT operating system

  • Windows 2000 operating system

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows 7 operating system

  • Windows Server 2008 R2 operating system

  • Windows 8 operating system

  • Windows Server 2012 operating system

  • Windows 8.1 operating system

  • Windows Server 2012 R2 operating system

  • Windows 10 operating system

  • Windows Server 2016 operating system

  • Windows Server operating system

  • Windows Server 2019 operating system

  • Windows Server 2022 operating system

  • Windows 11 operating system

  • Windows Server 2025 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.3.2: RPC over HTTP v2 is not supported Windows NT , Windows 2000 and Windows XP, without SP1.

<2> Section 1.6: Windows NT does not support RPC over HTTP v1; otherwise Windows supports RPC over HTTP v1. Windows still supports RPC over HTTP v1 for backward compatibility reasons, but Microsoft is actively looking to remove support for RPC over HTTP v1 in future versions of Windows. Windows NT, Windows 2000, and Windows XP without SP1 do not support RPC over HTTP v2.

<3> Section 2.1: RPC over HTTP v1 does not support IPv6 addresses, and RPC over HTTP v2 supports IPv6 addresses but not on Windows 2000 and Windows XP.

<4> Section 2.1: RPC over HTTP v1 and RPC over HTTP v2 on Windows allow a higher-level protocol to specify an HTTP proxy to be used by this protocol.

<5> Section 2.1.2.1: For HTTPS, the RPC over HTTP Protocol uses the machine default settings for negotiating security options and does not modify them.

<6> Section 2.1.2.1: Windows NT, Windows 2000 and Windows XP do not support authentication using a client-side SSL/TLS certificate.

<7> Section 2.1.2.1: Windows implementations of this protocol request the HTTP protocol stack to use a 30-minute time-out.

<8> Section 2.1.2.1.1: Windows clients will set this value to 1 gigabyte by default, but this can be overridden by client configuration.

<9> Section 2.1.2.1.3: Windows implementations use Windows error codes, as specified in [MS-ERREF].

<10> Section 2.1.2.1.4: Windows outbound proxies will set this value to 1 gigabyte by default, but this can be overridden by outbound proxy configuration.

<11> Section 2.1.2.1.5: Windows clients will set this value to 4.

<12> Section 2.1.2.1.5: Windows clients will send an array of four octets in the message body with the successive values being 0xF8, 0xE8, 0x18, 0x08. These values have no special significance and serve only as a signature for this message.

<13> Section 2.2.2: Windows versions prior to Windows Server 2003 operating system with Service Pack 1 (SP1) do not accept the second version of abs-path.

<14> Section 2.2.3.1: Windows implementations of this protocol use a UUID for all RTS cookies.

<15> Section 2.2.3.5.1: Windows uses 64-kilobyte receive windows by default, but registry configuration can override that.

<16> Section 2.2.3.5.5: Windows clients will set this value to 1 gigabyte by default, but this can be overridden by configuration.

<17> Section 2.2.3.5.15: Windows-based servers impose a limit that an outbound proxy does not send more than 8 kilobytes of ping traffic within a window of 4 minutes.

<18> Section 3: Windows implementations of this protocol will return one of the errors, as specified in [MS-ERREF], to higher-level protocols. The exact error depends on the failure condition that occurred.

<19> Section 3.1: Windows implementations of this protocol pass data arriving from the Winsock APIs to the Windows implementation of the RPCE Protocol extensions, as specified in [MS-RPCE], and send data from the Windows implementations of the Remote Procedure Call Protocol Extensions [MS-RPCE] to the Winsock APIs.

<20> Section 3.1.1.5.1: Windows implementations of this protocol hand off data received from the Winsock APIs to the Windows implementation of the Remote Procedure Call Protocol Extensions, as specified in [MS-RPCE].

<21> Section 3.1.1.5.2: Windows implementations of this protocol will return an error to the Windows implementation of the Remote Procedure Call Protocol Extensions, as specified in [MS-RPCE], indicating that an error has occurred.

<22> Section 3.1.3.4.2: Windows implementations of this protocol pass on received data from the Winsock APIs to the Windows implementation of the RPC extensions specified in [MS-RPCE].

<23> Section 3.1.3.4.3: Windows implementations of this protocol will return an error to the Windows implementation of the Remote Procedure Call Protocol Extensions, as specified in [MS-RPCE] to indicate the occurrence of an error.

<24> Section 3.2.1.1.5.1: Windows implementations of this protocol choose by default a receive window of 64 kilobytes. Administrators can override this size via configuration.

<25> Section 3.2.1.1.5.1.4: Windows implementations of this protocol maintain the AvailableWindowAdvertised variable.

<26> Section 3.2.1.3: Windows implementations initialize the value to 30 seconds by default.

<27> Section 3.2.1.4.1.1: When an RPC PDU is consumed on the receiver, if the size of AvailableWindowAdvertised is less than half of the originally advertised ReceiveWindow, a new FlowControlAck RTS PDU is sent by the recipient to the sender.

<28> Section 3.2.2.2.1: Windows clients allow a system administrator to force a lower connection time-out interval through the registry.

<29> Section 3.2.2.2.3: Windows always uses 200 milliseconds.

<30> Section 3.2.2.3: Higher-level protocols indicate whether HTTP or HTTPS will be used by specifying the RPC_C_HTTP_FLAG_USE_SSL flag in the RPC_SECURITY_QOS_V2 structure when calling the RpcBindingSetAuthInfoEx API as documented in [MSDN-RPCSECQOSV2]. HTTP authentication or client certificate authentication is specified by setting the authentication schemes in the RPC_SECURITY_QOS_V2 structure when calling the pcBindingSetAuthInfoEx API, as documented in [MSDN-RPCHTTPTRCRED].

<31> Section 3.2.2.4.1.1: Windows consults registry configuration to see if it should do Proxy use determination, and depending on registry contents, it uses WinHttp autoproxy discovery to find out if it is required to use an HTTP proxy.

<32> Section 3.2.2.4.2: Windows implementations of this protocol will start IN channel recycling on the client when 4 kilobytes remain of the channel lifetime.

<33> Section 3.2.2.5.11: The Windows implementation of this protocol returns the value of the RPC-Error field as an error code to the RPC method call during which the error was encountered.

<34> Section 3.2.2.5.11: Windows NT, Windows 2000, Windows XP, and Windows Server 2003 send EncodedEEInfo only in the message header; otherwise Windows sends EncodedEEInfo in both the message header and message body.

<35> Section 3.2.2.6.1: Windows implementations interpret "recently" to mean that another RPC or RTS PDU was sent on this channel more recently than one-half of the value of the connection time-out protocol variable.

<36> Section 3.2.2.6.2: Windows implementations interpret "recently" to mean that another RPC or RTS PDU was sent on this channel more recently than one-half of the value of the KeepAlive interval protocol variable.

<37> Section 3.2.3.1.4: Windows inbound proxies leave the system default value for the keep-alive value for the TCP stack.

<38> Section 3.2.3.1.5: Windows maintains the Resource Type UUID protocol variable as specified in this section.

<39> Section 3.2.3.1.6: Windows maintains the Session UUID protocol variable as specified in this section.

<40> Section 3.2.3.3: Windows NT, Windows 2000, Windows XP and Windows Server 2003 without SP 1 do not listen on HTTP/HTTPS URL namespace "/rpcwithcert/rpcproxy.dll".

<41> Section 3.2.3.3: The Windows implementation of this protocol reads the value of the ConnectionTimeout variable from the local machine configuration. The default value is 900.

<42> Section 3.2.4.1.1: The Windows implementation of this protocol maintains the Resource Type UUID protocol variable.

<43> Section 3.2.4.1.2: The Windows implementation of this protocol maintains the Session UUID protocol variable.

<44> Section 3.2.4.3: Windows Server 2003 with SP1 and subsequent service packs, Windows Vista, and subssequent listen on HTTP/HTTPS URL namespace "/rpcwithcert/rpcproxy.dll".

<45> Section 3.2.4.5.3: Windows outbound proxies will set the value of the Content-Length field to 1 gigabyte by default, but this setting can be overridden by the outbound proxy configuration.

<46> Section 3.2.4.5.8: Windows Server 2003 and Windows Server 2008 send UNDEFINED additional bytes after the OUT_R1/A10 RTS PDU and before closing the connection.

<47> Section 3.2.4.5.9: Windows outbound proxies will set the value of the Content-Length field to 1 gigabyte by default, but this setting can be overridden by the outbound proxy configuration.

<48> Section 3.2.4.5.10: Windows Server 2003 and Windows Server 2008 send UNDEFINED additional bytes after the OUT_R2/B3 RTS PDU and before closing the connection.

<49> Section 3.2.4.5.10: Windows Server 2003 and Windows Server 2008 send UNDEFINED additional bytes after the OUT_R2/B3 RTS PDU and before closing the connection.

<50> Section 3.2.4.6: The Windows implementation of this protocol notifies the server that it sent a Ping RTS PDU as follows: Each time it sends a Ping RTS PDU, it increments a protocol variable by the size in bytes of the Ping RTS PDU. Each time this protocol variable exceeds 1031, the protocol implementation will send a Ping Traffic Sent Notify RTS PDU with the size of this protocol variable being set in the PingTrafficSent field of the PingTrafficSentNotify (section 2.2.3.5.15) command, and it will reset the protocol variable to zero.

<51> Section 3.2.5.4.1: Windows implementations of this protocol will start OUT channel recycling on the client when 8 kilobytes remain of the channel lifetime.

<52> Section 3.2.5.5.2: The Windows implementation of this protocol will pass on PDUs it received from the Winsock APIs to the Windows implementation as specified in [MS-RPCE].