Protocol compliance
Prev | Chapter 1. Introduction | Next

## Protocol compliance

neon is intended to be compliant with the IETF protocol standards it implements, with a few exceptions where real-world use has necessitated minor deviations. 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 treats the presence of any `Transfer-Encoding` response header as an indication that the response message uses the “chunked” transfer-coding. This was the suggested resolution proposed by Larry Masinter.

### RFC 2617, HTTP Authentication: Basic and 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.

Prev | Up | Next
How to use neon from your application | Home | Chapter 2. The neon C language interface