RFC 7230 § 7: In any production that uses the list construct, a sender MUST NOT
generate empty list elements.
Parse error at offset 0.
Found: N
Expected:
* as part of If-Match (RFC 7232)
or comma (,) as part of If-Match (RFC 7232)
or double quote (") as part of entity-tag (RFC 7232)
or W as part of entity-tag (RFC 7232)
According to Content-Type, this message’s body is XML, but HTTPolice tried to parse it as XML and got the following error:
not well-formed (invalid token): line 3, column 19
This request’s User-Agent header contains only the name of the underlying library, which isn’t very useful for identifying the request. It may be a good idea to include the name of the actual product.
For example: “My-Product/1.0 Python-urllib/2.7”.
Or simply “My-Product/1.0” or “My-Product”.
See RFC 7231 § 5.5.3.
This request’s Cache-Control header includes the must-revalidate directive, which is only defined for responses.
The PUT method is defined as non-cacheable, so the max-age directive in this request’s Cache-Control header makes no difference.
In the Basic authentication scheme, the user ID and password are combined with a colon ‘:’ and packed into Base64. In this request’s Authorization header, HTTPolice tried to decode them from Base64 and got the following error:
Incorrect padding
See RFC 7617 § 2.
RFC 7230 § 3.3.2: A server MUST NOT send a Content-Length header field in any response
with a status code of 1xx (Informational) or 204 (No Content).
Parse error at offset 2.
Found: _
Expected:
A–Z or a–z as part of language (RFC 5646)
or dash (-) as part of langtag (RFC 5646) or grandfathered (RFC 5646) or language (RFC 5646)
or end of data
or comma (,) as part of Content-Language (RFC 7231)
or tab or space as part of Content-Language (RFC 7231)
Adding an ‘X-’ prefix to “experimental” headers is an old practice that is now considered obsolete. See RFC 6648 § 3.
For custom headers that may be generally useful, it’s best to drop the ‘X-’ prefix (but check the IANA message headers registry to avoid collisions with existing names).
For private headers not intended to be used by others, ‘X-’ can be replaced with something like the organization’s name.
According to RFC 7231 § 7.1.1.2, every 406 response must have a Date header, unless the server has no usable clock.
This response contains the ‘no-cache’ pragma directive, which is defined by RFC 7234 § 5.4 only for requests.
This message’s Cache-Control header includes both the private and the no-store directives, which contradict each other.
The PATCH method should only be used with media types that define how to apply the patch. text/xml is not such a media type. But this response’s Accept-Patch header invites the client to send patches of type text/xml.
See RFC 5789 errata.
For example, application/merge-patch+json would be a suitable patch format for JSON.
The 406 status code means that the server cannot satisfy the request’s content negotiation headers, such as Accept. But this request doesn’t seem to have such headers.
See also RFC 7231 § 5.3.
C 1032 Host should be the first header
RFC 7230 § 5.4: