Go to the latest version of this document.
search in docstrings

Search bar offers the following options:

- Term presence. The below example searches for documents that must contain “foo”, might contain “bar” and must not contain “baz”: `+foo bar -baz`
- Wildcards. The below example searches for documents with words beginning with “foo”: `foo*`
- Search in specific fields. The following search matches all objects in "twisted.mail" that matches “search”: `+qname:twisted.mail.* +search`

  Possible fields: 'name', 'qname' (fully qualified name), 'docstring', and 'kind'. Last two fields are only applicable if "search in docstrings" is enabled.

- Fuzzy matches. The following search matches all documents that have a word within 1 edit distance of “foo”: `foo~1`

Results provided by Lunr.js

# ``twisted`.`words`.`protocols`.`jabber`.`sasl`.`SASLIncorrectEncodingError``

exception documentation

`class SASLIncorrectEncodingError(SASLError): (source)`

View In Hierarchy

SASL base64 encoding was incorrect.

RFC 3920 specifies that any characters not in the base64 alphabet and padding characters present elsewhere than at the end of the string MUST be rejected. See also `fromBase64`.

This exception is raised whenever the encoded string does not adhere to these additional restrictions or when the decoding itself fails.

The recommended behaviour for so-called receiving entities (like servers in client-to-server connections, see RFC 3920 for terminology) is to fail the SASL negotiation with a `'incorrect-encoding'` condition. For initiating entities, one should assume the receiving entity to be either buggy or malevolent. The stream should be terminated and reconnecting is not advised.