Known Limitations

The following features are intentionally out-of-scope for the current release. Behaviour is well-defined in each case (documented exception or graceful exposure).

Area	Status	Notes
MTOM/XOP	Fully implemented	parse_mtom / build_mtom handle multipart/related MIME packaging and XOP Include resolution. AsgiSoapApp and WsgiSoapApp decode inbound MTOM automatically. SoapClient sends MTOM when use_mtom=True.
WS-Security	Fully implemented	UsernameTokenCredential / UsernameTokenValidator for PasswordText and PasswordDigest. sign_envelope / verify_envelope for XML-DSIG. encrypt_body / decrypt_body for XML Encryption (AES-256-GCM authenticated + RSA-OAEP). sign_envelope_bsp / verify_envelope_bsp + build_binary_security_token for WS-I BSP X.509 token profile (S10). All require soapbar[security].
WS-Addressing	Fully parsed + response headers generated	Inbound headers (MessageID, To, Action, ReplyTo, FaultTo, ReferenceParameters) are parsed into WsaHeaders. Response headers (MessageID, RelatesTo, Action, ReferenceParameters) are generated automatically when use_wsa=True.
SOAP 1.2 relay attribute	Parsed and exposed on SoapHeaderBlock	The relay boolean is available on each SoapHeaderBlock instance. Full SOAP intermediary forwarding (actually relaying the message) is not implemented.
xsd:complexType / xsd:array / xsd:choice	Fully supported for round-trip serialization	Recursive (self-referencing) complex types are resolved lazily. xsd:complexContent/restriction for SOAP-encoded arrays is also parsed from WSDL.
External schema xsd:import / xsd:include	Resolved recursively (since 0.6.2)	wsdl:import (document-level) and xsd:import / xsd:include children of <xsd:schema> inside <wsdl:types> are both resolved, with the same SSRF guard (allow_remote_imports=False by default blocks http(s):// fetches). Complex types from imported/included schemas are registered alongside inline ones. Circular imports are cycle-detected; depth is capped at 8 levels.
WS-Addressing reply / fault routing (A04, A05)	EPRs validated, not routed	wsa:ReplyTo and wsa:FaultTo Endpoint References are parsed and validated as absolute URIs. Responses and faults are always returned on the request's HTTP back-channel — soapbar does not dispatch outbound HTTP from the server, and the client does not consume EPRs from a peer's response. The well-known constants WSA_ANONYMOUS and WSA_NONE are exported at the top level (from soapbar import WSA_ANONYMOUS, WSA_NONE) for callers building EPR-aware logic on top of handle_request(). See SECURITY.md for the full scope note.
SOAP 1.2 recursive Subcode	Supported on SoapFault	SoapFault(subcodes=[(ns_uri, local_name), …]) emits nested <env:Subcode>/<env:Value> hierarchy per SOAP 1.2 Part 1 §5.4.1. SOAP 1.1 uses dot-notation (Client.Authentication) which is a convention, not a formal grammar, and is not parsed into structured form.
WSDL 2.0	Not supported	soapbar generates and parses WSDL 1.1 only. WSDL 2.0 adoption is low outside JAX-WS/Metro; 1.1 remains the de facto industry standard and interoperates cleanly with zeep / spyne / WCF / CXF / WSS4J.
WS-Policy / WS-PolicyAttachment	Out of scope	Generated WSDL does not include <wsp:Policy> or <wsp:PolicyReference> elements. Deployers requiring declarative policy (algorithm suites, transport bindings, token assertions) should run a WS-Policy processor upstream or document the policy out-of-band. WS-SecurityPolicy assertions are likewise not emitted.
WS-ReliableMessaging / WS-Trust / WS-SecureConversation / WS-Federation	Out of scope	These WS-* specifications are not implemented. soapbar's WS-Security surface covers UsernameToken, XML Signature, XML Encryption, Timestamp, and the BSP X.509 token profile — sufficient for the audit-checkpoint matrix items F01–S10 but not the token-issuance / session-continuity / federation specs.