HTTPolice report


from ../test/combined_data/showcase.https (inbound), offset 0

PUT /articles/109226/ HTTP/1.1

Authorization: Basic SecretToken123
Host: api.example.com
User-agent: Python-urllib/2.7
Expect: 100-continue
content-type: text/xml; charset=utf-8
content-encoding: gzip
Cache-Control: max-age=0, must-revalidate,
If-Match: Nx2DMvqzPDt4
Content-Length: 3942

Body after removing Content-Encoding and taking the first 1000 characters

<?xml version="1.0"?>
<article>
  <title>The Rise & Fall of Lorem Ipsum</title>
  <text align="left">
    Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas venenatis posuere leo, ac facilisis lectus interdum vitae. Vestibulum venenatis facilisis turpis vel sagittis. Aenean interdum eget metus sed tincidunt. Aliquam leo metus, viverra ut fringilla id, molestie sit amet ipsum. Mauris fringilla, odio nec pretium iaculis, orci nisi luctus sapien, at efficitur odio nisi condimentum mi. Suspendisse eleifend fermentum elit in dictum. Ut ac bibendum est. Proin pretium dignissim leo ut fermentum. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus dignissim dolor ut vestibulum ultrices. Phasellus et quam bibendum, tincidunt lorem eget, laoreet ligula. Vivamus semper, metus at fringilla malesuada, metus lacus mollis dolor, quis bibendum libero augue quis mi. Curabitur suscipit enim vel lorem ornare commodo. Vestibulum a nibh bibendum, commodo lacus sit amet, molest

E 1151 Empty list elements in Cache-Control are forbidden

RFC 7230 § 7: In any production that uses the list construct, a sender MUST NOT generate empty list elements.

E 1000 Syntax error in If-Match header

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)

E 1039 Bad XML body

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

C 1032 Host should be the first header

RFC 7230 § 5.4: Since the Host field-value is critical information for handling a request, a user agent SHOULD generate Host as the first header field following the request-line.

C 1093 User-Agent contains no actual product

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.

E 1152 Cache-Control: must-revalidate is for responses

This request’s Cache-Control header includes the must-revalidate directive, which is only defined for responses.

C 1171 Cache-Control: max-age has no effect on PUT

The PUT method is defined as non-cacheable, so the max-age directive in this request’s Cache-Control header makes no difference.

E 1210 Malformed Authorization: Basic

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.


from ../test/combined_data/showcase.https (outbound), offset 0

HTTP/1.1 100 Continue

Content-Length: 0

E 1023 Content-Length is forbidden in a 100 response

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).


from ../test/combined_data/showcase.https (outbound), offset 44

HTTP/1.1 406 Not Acceptable

Server: MyHTTPd/1.2.1 (Unix)
X-Request-ID: b66e79ea61332ab0
Content-Type: application/vnd.example+json
Content-Language: en_US
Link: <http://example.com/api/docs>; rel=help
Accept-Patch: text/xml;charset=utf-8
Strict-Transport-Security: max-age=15768000
Cache-Control: private,no-cache,no-store
Pragma: no-cache
Transfer-Encoding: chunked

Body after removing Transfer-Encoding and pretty-printing

{
  "status": "error", 
  "errors": [
    {
      "code": "bad-format", 
      "description": "the article body was malformed"
    }
  ]
}

E 1000 Syntax error in Content-Language header

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)

C 1277 Obsolete ‘X-’ prefix in headers

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.

C 1110 Missing Date header

According to RFC 7231 § 7.1.1.2, every 406 response must have a Date header, unless the server has no usable clock.

C 1162 Pragma: no-cache is for requests

This response contains the ‘no-cache’ pragma directive, which is defined by RFC 7234 § 5.4 only for requests.

E 1193 Cache-Control: private contradicts no-store

This message’s Cache-Control header includes both the private and the no-store directives, which contradict each other.

C 1227 text/xml is not suitable for Accept-Patch

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.

E 1090 406 response, but request wasn’t negotiating

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.