Standards compliance
Prev | Chapter 1. Introduction | Next

## Standards compliance

neon is intended to be compliant with the IETF and W3C standards which it implements, with a few exceptions due to practical necessity or interoperability issues. These exceptions are documented in this section.

### RFC 2518, HTTP Extensions for Distributed Authoring—WebDAV

neon is deliberately not compliant with section 23.4.2, and treats property names as a (namespace-URI, name) pair. This is generally considered to be correct behaviour by the WebDAV working group, and is likely to formally adopted in a future revision of the specification.

### RFC 2616, Hypertext Transfer Protocol—HTTP/1.1

There is some confusion in this specification about the use of the “identity” transfer-coding. neon ignores the `Transfer-Encoding` response header if it contains only the (now deprecated) “identity” token, and will determine the response message length as if the header was not present. neon will give an error if a response includes a `Transfer-Encoding` header with a value other than “identity” or “chunked”.

### RFC 3986 Uniform Resource Identifier (URI): Generic Syntax and RFC 6874, Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers

neon parses and handles scoped IPv6 link-local literal addresses passed to ne_session_create since version `0.34`, following the syntax in RFC 6874. An example `host` argument would be `"[fe80::cafe%25eth0]"` where `"eth0"` is the scope ID. Since RFC 9110 does not reference the extended syntax of scoped IPv6 literals, and a scope ID has no meaningful interpretation outside of the client host, it is omitted from the `Host` header sent over the wire. So the example argument here translates to an HTTP/1.1 header field of `Host: [fe80::cafe]`.

### RFC 7616, HTTP Digest Access Authentication

neon is not strictly compliant with the quoting rules given in the grammar for the `Authorization` header. The grammar requires that the `qop` and `algorithm` parameters are not quoted, however one widely deployed server implementation (Microsoft® IIS 5) rejects the request if these parameters are not quoted. neon sends these parameters with quotes—this is not known to cause any problems with other server implementations.

RFC 7616 predates RFC 9112 and uses conflicting language around URIs. neon uses the RFC 9112 `request-target` in both the `A2` grammar and the `uri=` parameter of the `Authorization` header. neon will accept (and resolve) any URI-reference in the `domain=` parameter for `WWW-Authenticate` response header field.

### Namespaces in XML

The neon XML parser interface will accept and parse without error some XML documents which are well-formed according to the XML specification but do not conform to the "Namespaces in XML" specification [REC-XML-names]. Specifically: the restrictions on the first character of the `NCName` rule are not all implemented; neon will allow any `CombiningChar`, `Extender` and some characters from the `Digit` class in this position.

Prev | Up | Next
Example application | Home | HTTP Client Security