Parse error at offset 0.
* 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)
This message’s Forwarded header contains a comma inside a quoted string. But experience shows that headers like Forwarded are often parsed without regard for quoted strings—such a naive parser might interpret this comma as a separator between Forwarded elements. If possible, avoiding this comma might help interoperability.
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 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 has the Content-Disposition header, which is only defined for responses.
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-requests/2.18.4”.
Or simply “My-Product/1.0” or “My-Product”.
See RFC 7231 § 5.5.3.
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:
See RFC 7617 § 2.
Parse error at offset 2.
A–Z or a–z as part of 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)
There is no such media type text/json. Probably application/json was intended.
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.
See also RFC 7231 § 5.3.