This is the list of all notices produced by HTTPolice version 0.9.0.
See also the HTTPolice manual.
error
RFC 7230 § 3.3.1: If any transfer coding
other than chunked is applied to a request payload body, the sender
MUST apply chunked as the final transfer coding to ensure that the
message is properly framed.
RFC 7230 § 3.3.1: A sender MUST
NOT apply chunked more than once to a message body (i.e., chunking an
already chunked message is not allowed).
HTTPolice does not know how to decode the coding transfer coding. (This doesn’t mean that it’s wrong.)
This message’s Content-Length header indicates that the body is value bytes long, but there are fewer bytes remaining on the stream name.
error
error
Due to previous notices, the data beginning at byte offset on the request stream name will not be parsed.
There are unparsed bytes remaining on the response stream name, but no requests that would correspond to them. HTTPolice will try to parse and analyze the remaining responses on their own.
error
Due to previous notices, the data beginning at byte offset on the response stream name will not be parsed.
The 101 status code means that the connection is switching to a different protocol. HTTPolice will not parse the rest of the streams.
A status response to a CONNECT request means that the connection is becoming a tunnel. HTTPolice will not parse the remainder of the streams.
RFC 7230 § 3.2.2: A sender MUST NOT generate multiple header fields with the same field
name in a message unless either the entire field value for that
header field is defined as a comma-separated list [i.e., #(values)]
or the header field is a well-known exception (as noted below).
The syntax of place includes the rule named BWS, which is whitespace allowed for historical reasons; it must not be produced by current implementations. See RFC 7230 § 3.2.3.
This message uses line folding (the “obs-fold” rule) to split one header field over several physical lines, but this is deprecated and prohibited in most cases. See RFC 7230 § 3.2.4.
This message uses the “quoted-pair” rule to escape the character char in a context where this escaping is unnecessary and should not be used. See RFC 7230 § 3.2.6.
If a literal backslash \ was intended here, it must itself be escaped as \\.
RFC 7230 § 3.3.1: A server MUST NOT send a Transfer-Encoding header field in any
response with a status code of 1xx (Informational) or 204 (No
Content).
RFC 7230 § 3.3.1: A server MUST NOT send a Transfer-Encoding header field in
any 2xx (Successful) response to a CONNECT request
RFC 7230 § 3.3.2: A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field.
RFC 7230 § 3.3.2: A user agent SHOULD send a Content-Length in a request message when
no Transfer-Encoding is sent and the request method defines a meaning
for an enclosed payload body. For example, a Content-Length header
field is normally sent in a POST request even when the value is 0
(indicating an empty payload body).
RFC 7230 § 3.3.2: A user agent SHOULD NOT send a
Content-Length header field when the request message does not contain
a payload body and the method semantics do not anticipate such a
body.
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).
RFC 7230 § 3.3.2: A
server MUST NOT send a Content-Length header field in any 2xx
(Successful) response to a CONNECT request (Section 4.3.6 of
[RFC7231]).
This response has no Content-Length header and no “Transfer-Encoding: chunked” that would delimit its body. Therefore, the body is assumed to consist of everything the server sends until closing the connection. But then the client cannot be sure that it received the entire response (that there were no network failures).
See RFC 7230 § 3.3.3.
RFC 7230 § 4.1.2: A sender MUST NOT generate a trailer that contains a field necessary
for message framing (e.g., Transfer-Encoding and Content-Length),
routing (e.g., Host), request modifiers (e.g., controls and
conditionals in Section 5 of [RFC7231]), authentication (e.g., see
[RFC7235] and [RFC6265]), response control data (e.g., see Section
7.1 of [RFC7231]), or determining how to process the payload (e.g.,
Content-Encoding, Content-Type, Content-Range, and Trailer).
error
RFC 7230 § 4.3: A client MUST NOT send
the chunked transfer coding name in TE; chunked is always acceptable
for HTTP/1.1 recipients.
RFC 7230 § 4.3: Since the TE header field only applies to the immediate connection, a
sender of TE MUST also send a "TE" connection option within the
Connection header field (Section 6.1) in order to prevent the TE
field from being forwarded by intermediaries that do not support its
semantics.
RFC 7230 § 4.4: When a message includes a message body encoded with the chunked
transfer coding and the sender desires to send metadata in the form
of trailer fields at the end of the message, the sender SHOULD
generate a Trailer header field before the message body to indicate
which fields will be present in the trailers.
RFC 7230 § 5.4: A client MUST send a Host header field in all HTTP/1.1 request
messages.
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.
RFC 7230 § 5.4: A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a
Host header field with an invalid field-value.
RFC 7230 § 5.4: A sender MUST NOT send a connection option corresponding to a header
field that is intended for all recipients of the payload. For
example, Cache-Control is never appropriate as a connection option
(Section 5.2 of [RFC7234]).
According to Content-Type, this message’s body is of type value, which is listed as “deprecated” or “obsoleted” in the IANA media types registry.
HTTPolice does not know how to decode the coding content coding. (This doesn’t mean that it’s wrong.)
error
According to Content-Type, this message’s body is JSON, but HTTPolice tried to parse it as JSON and got the following error:
error
According to Content-Type, this message’s body is XML, but HTTPolice tried to parse it as XML and got the following error:
error
According to Content-Type, this message’s body is URL-encoded. But it doesn’t look like a proper URL-encoded string, as defined by HTML5, because it contains the character: char.
This often means that the Content-Type header is wrong.
RFC 7231 § 3.1.1.5: A sender that generates a message containing a payload body SHOULD
generate a Content-Type header field in that message unless the
intended media type of the enclosed representation is unknown to the
sender.
RFC 6838 § 4.3: It is an error for a specific
parameter to be specified more than once.
According to RFC 7230 § 5.7.1, a proxy must add a Via header to each response that it forwards.
When a response is delimited only by closing the connection, it should have a Connection header with a ‘close’ option. See RFC 7230 § 6.3 and RFC 7230 § 6.6.
RFC 7230 § 6.7: A server that sends a 101 (Switching Protocols) response MUST send an
Upgrade header field to indicate the new protocol(s) to which the
connection is being switched
RFC 7230 § 6.7: A server MUST NOT switch to a protocol that was not indicated
by the client in the corresponding request's Upgrade header field.
RFC 7230 § 6.7: When Upgrade is sent, the sender MUST also send a Connection header
field (Section 6.1) that contains an "upgrade" connection option, in
order to prevent Upgrade from being accidentally forwarded by
intermediaries that might not implement the listed protocols.
RFC 7230 § 6.7: A
server MUST ignore an Upgrade header field that is received in an
HTTP/1.0 request.
The header header provides representation metadata, but there can be no representation associated with a status response. The header should probably be removed.
The header header provides representation metadata. It would make sense in a request with a body, but this one has no body.
See also RFC 7231 § 3.1.
The Trailer header announces what other headers will be sent in the trailer part of a chunked message. It doesn’t make sense here because this message does not use the chunked transfer coding.
See also RFC 7230 § 4.1.2.
This is a status response to a method request. By definition, its body is a representation of the requested resource. But it also has a Content-Location header that points to the same URI as the request URI. In this case, the header provides no additional information.
See also RFC 7231 § 3.1.4.1.
RFC 7231 § 4.3.1: A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.
RFC 7231 § 4.3.2: A payload within a HEAD request message has no defined semantics;
sending a payload body on a HEAD request might cause some existing
implementations to reject the request.
RFC 7231 § 4.3.4: An origin server that allows PUT on a given target resource MUST send
a 400 (Bad Request) response to a PUT request that contains a
Content-Range header field (Section 4.2 of [RFC7233]), since the
payload is likely to be partial content that has been mistakenly PUT
as a full representation.
RFC 7231 § 4.3.5: A payload within a DELETE request message has no defined semantics;
sending a payload body on a DELETE request might cause some existing
implementations to reject the request.
This is an ostensibly successful (status) response to a DELETE request. However, according to its Content-Location header, it carries a representation of the target resource—the one that should have been deleted. Either the Content-Location is wrong, or the request did not actually succeed.
RFC 7231 § 4.3.6: A payload within a CONNECT request message has no defined semantics;
sending a payload body on a CONNECT request might cause some existing
implementations to reject the request.
RFC 7231 § 4.3.7: A client that generates an OPTIONS request containing a payload body
MUST send a valid Content-Type header field describing the
representation media type.
This request has the header header, which is only defined for responses.
This response has the header header, which is only defined for requests.
RFC 7231 § 5.1.1: A client MUST NOT generate a 100-continue expectation in a request
that does not include a message body.
The Max-Forwards header is only defined for OPTIONS and TRACE requests. RFC 7231 § 5.1.2: A recipient MAY ignore a Max-Forwards header field received with any other request methods.
RFC 7231 § 5.5.2: A user agent MUST NOT send a Referer header field in an
unsecured HTTP request if the referring page was received with a
secure protocol.
RFC 7231 § 5.5.3: A user agent SHOULD send a User-Agent field in each request
unless specifically configured not to do so.
RFC 7231 § 6.2: Since HTTP/1.0 did not define any 1xx status codes, a
server MUST NOT send a 1xx response to an HTTP/1.0 client.
The method method is defined as safe (read-only). But the 201 status code means that a new resource was created.
This 201 response indicates that a new resource was created. Because there is no Location header in the response, it is assumed that the created resource is the same as the request target (RFC 7231 § 6.3.2). But POST requests are usually intended to create a sub-resource of the target. It’s likely that this response needs an explicit Location.
The method method is defined as safe (read-only). But the 202 status code means that the server started some kind of processing operation.
RFC 7231 § 6.3.6: Since the 205 status code implies that no additional content will be
provided, a server MUST NOT generate a payload in a 205 response.
RFC 7231 § 6.4.1: For request methods other than HEAD, the server SHOULD generate a
payload in the 300 response containing a list of representation
metadata and URI reference(s) from which the user or user agent can
choose the one most preferred.
RFC 7231 § 6.4.2: The server SHOULD generate a Location header field in the response
containing a preferred URI reference for the new permanent URI.
RFC 7231 § 6.4.3: The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI.
RFC 7231 § 6.4.4: The 303 (See Other) status code indicates that the server is
redirecting the user agent to a different resource, as indicated by a
URI in the Location header field, which is intended to provide an
indirect response to the original request.
RFC 7231 § 6.4.4: Except for responses to a HEAD request, the representation of a 303
response ought to contain a short hypertext note with a hyperlink to
the same URI reference provided in the Location header field.
RFC 7231 § 6.4.5: The 305 (Use Proxy) status code was defined in a previous version of
this specification and is now deprecated (Appendix B).
RFC 7231 § 6.4.6: The 306 status code was defined in a previous version of this
specification, is no longer used, and the code is reserved.
RFC 7231 § 6.4.7: The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI.
This status response includes a Location header that points to the same URI as the request URI. So the resource redirects to itself.
The status status code means that the target resource can be found at a different URI. But this was an “ OPTIONS * ” request—it targets the entire server, not any particular resource. So the status status code makes no sense here.
Perhaps the 303 status code would fit better.
RFC 7231 § 6.5: Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent
condition.
RFC 7231 § 6.5.2: The 402 (Payment Required) status code is reserved for future use.
RFC 7231 § 6.5.5: The origin server MUST generate an
Allow header field in a 405 response containing a list of the target
resource's currently supported methods.
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.
RFC 7231 § 6.5.6: The server SHOULD generate a payload containing a list of available
representation characteristics and corresponding resource identifiers
from which the user or user agent can choose the one most
appropriate.
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 library”.
Or simply “My-Product/1.0” or “My-Product”.
See RFC 7231 § 5.5.3.
RFC 7231 § 6.5.7: A server SHOULD send the "close" connection option
(Section 6.1 of [RFC7230]) in the response, since 408 implies that
the server has decided to close the connection rather than continue
waiting.
The 409 status code means that the request conflicted with the current state of the resource. But a method request is, by definition, safe (read-only): it must not affect the state, so there can be no conflict.
RFC 7231 § 6.5.8: The server
SHOULD generate a payload that includes enough information for a user
to recognize the source of the conflict.
The 411 status code means that the server wants to see a Content-Length header in the request. But this request did, in fact, include a valid Content-Length of value.
RFC 7231 § 6.5.11: The 413 (Payload Too Large) status code indicates that the server is
refusing to process a request because the request payload is larger
than the server is willing or able to process.
RFC 7231 § 6.5.13: The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource.
RFC 7231 § 6.5.14: The 417 (Expectation Failed) status code indicates that the
expectation given in the request's Expect header field
(Section 5.1.1) could not be met by at least one of the inbound
servers.
RFC 7231 § 6.5.15: The server MUST send an Upgrade header field in a 426
response to indicate the required protocol(s)
In this response, the server demands that the client upgrade to protocol. But the client’s request is already offering that same upgrade in its own Upgrade header. The server can just send a 101 response and switch to protocol.
See RFC 7230 § 6.7.
This response’s Upgrade header indicates that the server is ready to upgrade to protocol. But the client’s request is already offering that same upgrade in its own Upgrade header. If the server actually wants to switch to protocol, it should go ahead, send a 101 response, and switch.
See RFC 7230 § 6.7.
RFC 7231 § 6.6: Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent
condition.
The 505 status code means that the server does not support the HTTP version used in the request—which is version—but the response itself is version, too.
RFC 7230 § 2.6: A server MUST NOT send
a version to which it is not conformant.
RFC 7231 § 6.6.6: The server SHOULD
generate a representation for the 505 response that describes why
that version is not supported and what other protocols are supported
by that server.
This message’s place uses an obsolete date-time format. See RFC 7231 § 7.1.1.1.
This message’s place claims that date is claimed, but in reality it’s actual.
The Date header contains the date and time at which the message was originated. But here it seems to be in the future.
This might be due to wrong timezone settings.
According to RFC 7231 § 7.1.1.2, every status response must have a Date header, unless the server has no usable clock.
RFC 7231 § 7.1.2: There are circumstances in which a fragment identifier in a Location
value would not be appropriate. For example, the Location header
field in a 201 (Created) response is supposed to provide a URI that
is specific to the created resource.
RFC 7231 § 7.1.2 does not define what it means for a status response to have a Location header.
As far as HTTPolice knows, the Retry-After header is defined for status codes 3xx, 413, 429, and 503, but not for status.
The 405 status code means that the request method (method) is not allowed for this resource. But the Allow header does include method.
The status status code means that this method request was handled successfully. But the Allow header does not include method, so it should have been disallowed (status code 405).
RFC 7231 § 5.3.4: Most HTTP/1.0 applications do not recognize or obey qvalues
associated with content-codings. This means that qvalues might
not work and are not permitted with x-gzip or x-compress.
The 406 status code means that the server cannot satisfy the request’s content negotiation headers. The only such header (known to HTTPolice) in this request is Accept-Language. However, RFC 7231 § 5.3.5 discourages sending a 406 response in this case: it’s better to send a representation in a different language, because the user may still be able to understand some of it.
RFC 7232 § 2.2.1: An origin server with a clock MUST NOT send a Last-Modified date that
is later than the server's time of message origination (Date).
RFC 7232 § 2.3: Previously, opaque-tag was defined to be a quoted-string
([RFC2616], Section 3.11); thus, some recipients might perform
backslash unescaping. Servers therefore ought to avoid backslash
characters in entity tags.
RFC 7232 § 3.1: An origin server MUST use the strong comparison function when
comparing entity-tags for If-Match (Section 2.3.2), since the client
intends this precondition to prevent the method from being applied if
there have been any changes to the representation data.
In other words, a conformant server will never consider two weak entity tags as equal for purposes of the If-Match header.
This is a status response to a method request, but its ETag header matches the If-None-Match header of the request. The server is supposed to send a 304 response in this situation.
See RFC 7232 § 3.2.
According to RFC 7232 § 3.3, an If-Modified-Since header must be ignored in requests that are neither GET nor HEAD.
This is a status response to a method request, but its Last-Modified date is no later than the If-Modified-Since header of the request. The server should send a 304 response in this situation.
See RFC 7232 § 3.3.
The 304 status code is only defined by RFC 7232 § 4.1 for responses to GET and HEAD. With other methods, the 412 status code may be useful.
The status status code is only used when the request includes a precondition, such as If-Modified-Since. But this request doesn’t seem to have any preconditions.
See RFC 7232.
RFC 7232 § 4.1: Since the goal of a 304 response is to minimize information transfer
when the recipient already has one or more cached representations, a
sender SHOULD NOT generate representation metadata other than the
above listed fields unless said metadata exists for the purpose of
guiding cache updates (e.g., Last-Modified might be useful if the
response does not have an ETag field).
The 412 status code means that the server could not satisfy a precondition included in the request. The only such precondition (known to HTTPolice) in this request is If-Modified-Since. But RFC 7232 § 3.3 says that an If-Modified-Since header in a method request must be ignored.
The 412 status code means that the server could not satisfy a precondition included in the request. But, as defined in RFC 7232 § 5, such preconditions must be ignored in a method request.
RFC 7232 § 5: Likewise, a server
MUST ignore the conditional request header fields defined by this
specification when received with a request method that does not
involve the selection or modification of a selected representation,
such as CONNECT, OPTIONS, or TRACE.
RFC 7232 § 5: Although conditional request header fields are defined as being
usable with the HEAD method (to keep HEAD's semantics consistent with
those of GET), there is no point in sending a conditional HEAD
because a successful response is around the same size as a 304 (Not
Modified) response and more useful than a 412 (Precondition Failed)
response.
RFC 7233 § 3.1: A server
MUST ignore a Range header field received with a request method other
than GET.
RFC 7233 § 2.1: A byte-range-spec is invalid if the last-byte-pos value is present
and less than the first-byte-pos.
RFC 7233 § 3.2: A client MUST NOT generate an If-Range header field in a request that
does not contain a Range header field.
RFC 7233 § 3.2: A client MUST NOT generate an If-Range header field containing an
entity-tag that is marked as weak.
The 206 status code only makes sense in responses to partial requests—that is, requests with a Range header. See RFC 7233 § 4.1.
RFC 7233 § 3.1: A server
MUST ignore a Range header field received with a request method other
than GET.
The 206 status code means that the response contains one or more parts of the data. When it contains one part, the response must have a Content-Range header. When it contains several parts, the response must have a Content-Type of multipart/byteranges. But this response has neither.
See RFC 7233 § 4.1.
According to Content-Type, this message has a multipart body, but Content-Type does not include the ‘boundary’ parameter that is necessary to parse such a body.
See RFC 2046 § 5.1.1.
The multipart boundary declared in this message’s Content-Type was not found in the body.
See RFC 2046 § 5.1.1.
RFC 7233 § 4.1: Within the header area of each body part in the multipart payload,
the server MUST generate a Content-Range header field corresponding
to the range being enclosed in that body part.
RFC 7233 § 4.1: If the selected
representation would have had a Content-Type header field in a 200
(OK) response, the server SHOULD generate that same Content-Type
field in the header area of each body part.
RFC 7233 § 4.1: To avoid confusion with single-part responses, a server MUST NOT
generate a Content-Range header field in the HTTP header section of a
multiple part response (this field will be sent in each part
instead).
RFC 7233 § 4.1: A server MUST NOT generate a multipart response to a request for a
single range, since a client that does not request multiple parts
might not support multipart responses.
The request’s If-Range header means that the server is expected to send a 206 response only if the representation’s ETag matches the one specified in If-Range. In this case, it doesn’t match, so the server is supposed to send a 200 response with the complete data.
See RFC 7233 § 3.2.
RFC 7233 § 4.1: If a 206 is generated in response to a request with an If-Range
header field, the sender SHOULD NOT generate other representation
header fields beyond those required above, because the client is
understood to already have a prior response containing those header
fields.
The Content-Range header is defined by RFC 7233 § 4.2 for responses with status codes 206 and 416, but not status.
RFC 7233 § 4.2: A Content-Range field value is invalid if it contains a
byte-range-resp that has a last-byte-pos value less than its
first-byte-pos value, or a complete-length value less than or equal
to its last-byte-pos value.
The 416 status code is defined by RFC 7233 § 4.4 only for responses to requests that have a Range header.
RFC 7233 § 4.4: When this status
code is generated in response to a byte-range request, the sender
SHOULD generate a Content-Range header field specifying the current
length of the selected representation
RFC 7230 § 7: In any production that uses the list construct, a sender MUST NOT
generate empty list elements.
This request’s Cache-Control header includes the directive directive, which is only defined for responses.
This response’s Cache-Control header includes the directive directive, which is only defined for requests.
The specification for the directive directive recommends wrapping its argument in double quotes. But in this message’s Cache-Control header, it is not quoted.
In this message’s Cache-Control header, the argument to the directive directive is wrapped in double quotes. But the specification recommends writing it as a plain token, without quotes.
According to the specification, ‘name’ in entry must have an argument. But in this message, it doesn’t.
In this message’s entry header, ‘name’ has an argument. But the specification defines no argument for ‘name’.
“value” is not a correct value for ‘name’ in place.
error
In this request’s Cache-Control header, the no-cache directive has an argument. But the specification for no-cache only defines an argument when used in responses.
This message’s Pragma header includes ‘pragma’, but all pragmas other than ‘no-cache’ are deprecated in RFC 7234 § 5.4.
RFC 7234 § 5.4: When sending a no-cache request, a client ought to include both the
pragma and cache-control directives, unless Cache-Control: no-cache
is purposefully omitted to target other Cache-Control response
directives at HTTP/1.1 caches.
This response contains the ‘no-cache’ pragma directive, which is defined by RFC 7234 § 5.4 only for requests.
RFC 7234 § 5.5 defines two classes of warn codes: 1xx and 2xx. But this message’s Warning header contains a code code.
This message’s Warning header contains a warning (code code) with a date that does not match the Date header. This means that the warning was mistakenly kept after cache validation. As explained in RFC 7234 § 5.5, such warnings must be removed.
This request’s Warning header contains the code warn code. But, according to RFC 7234 § 5.5, 1xx warn codes can only be used on responses.
According to RFC 7234 § 4, a cache must add an Age header to every response that is served without contacting the origin server.
According to RFC 7231 § 6, HTTP status codes can only range from 100 to 599.
RFC 7234 § 5.1: The presence of an Age header field implies that the response was not
generated or validated by the origin server for this request.
This response’s Warning header contains the code warn code, which implies that it was served from a cache, without contacting the origin server. See RFC 7234 § 5.5.
This response’s Age of value is greater than the max-age of max_age requested by the client’s Cache-Control header.
The method method is defined as non-cacheable, so the directive directive in this request’s Cache-Control header makes no difference.
The method method is defined as non-cacheable.
RFC 7234 § 5.2.1.4: The "no-cache" request directive indicates that a cache MUST NOT use
a stored response to satisfy the request without successful
validation on the origin server.
RFC 7234 § 5.4: When the Cache-Control header field is not present in a request,
caches MUST consider the no-cache request pragma-directive as having
the same effect as if "Cache-Control: no-cache" were present
RFC 7234 § 5.2.2.2: The "no-cache" response directive indicates that the response MUST
NOT be used to satisfy a subsequent request without successful
validation on the origin server.
According to RFC 7234 § 3, a cache cannot store a response that includes the no-store directive in its Cache-Control header.
The status status code is not defined as cacheable by default. According to RFC 7234 § 3, such a response can only be cached if it explicitly allows caching, with headers such as Expires. But this response has no such headers, so it is not cacheable.
Because this response has no explicit freshness controls (such as Expires or max-age), HTTPolice will assume that its expiration time was chosen heuristically by the cache. See RFC 7234 § 4.2.2.
The 113 warn code in this response’s Warning header means that the expiration time for this response was chosen heuristically by the cache.
RFC 7234 § 4.2.2: When a heuristic is used to calculate freshness lifetime, a cache
SHOULD generate a Warning header field with a 113 warn-code (see
Section 5.5.4) in the response if its current_age is more than 24
hours and such a warning is not already present.
RFC 7234 § 4.2.2: A cache MUST NOT use heuristics to determine freshness when an
explicit expiration time is present in the stored response.
RFC 7234 § 4.2.2: A cache MUST NOT use heuristics to determine freshness when an
explicit expiration time is present in the stored response.
The code warn code in this response’s Warning header means that the response is stale, as defined by RFC 7234 § 4.2.
This response’s Age is greater than the max-age specified in its Cache-Control header. This means that the response is stale, as defined by RFC 7234 § 4.2.
This response’s Age is greater than the difference between its Expires date and its Date header. This means that the response is stale, as defined by RFC 7234 § 4.2.
RFC 7234 § 4.2.4: A cache SHOULD generate a Warning header field with the 110 warn-code
(see Section 5.5.1) in stale responses.
RFC 7234 § 5.2.2.1: The "must-revalidate" response directive indicates that once it has
become stale, a cache MUST NOT use the response to satisfy subsequent
requests without successful validation on the origin server.
RFC 7234 § 4.2.4: A cache MUST NOT send stale responses unless it is disconnected
(i.e., it cannot contact the origin server or otherwise find a
forward path) or doing so is explicitly allowed (e.g., by the
max-stale request directive; see Section 5.2.1).
If the cache is disconnected, it should have added a Warning header with a 112 or 111 warn code to indicate that.
The 214 warn code in this message’s Warning header means that it was transformed by a proxy.
See also RFC 7230 § 5.7.2.
The 203 status code means that this response was transformed by a proxy.
See also RFC 7230 § 5.7.2.
RFC 7230 § 5.7.2: A proxy that transforms a
payload MUST add a Warning header field with the warn-code of 214
("Transformation Applied") if one is not already in the message (see
Section 5.5 of [RFC7234]).
RFC 7230 § 5.7.2: A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
a message that contains a no-transform cache-control directive
(Section 5.2 of [RFC7234]).
This message’s Cache-Control header includes both the directive1 and the directive2 directives, which contradict each other.
RFC 7235 § 3.1: The server generating a 401 response MUST send
a WWW-Authenticate header field (Section 4.1) containing at least one
challenge applicable to the target resource.
RFC 7235 § 3.2: The proxy MUST send a
Proxy-Authenticate header field (Section 4.3) containing a challenge
applicable to that proxy for the target resource.
According to RFC 7235 § 2.2, the value of the ‘realm’ parameter must be enclosed in double quotes.
This message has the header header, which is listed as “obsoleted” or “deprecated” in the IANA message headers registry.
The status status code means that this is an interim response, and more responses will follow on the same connection. But the ‘close’ option in this response’s Connection header means that the server will close the connection after sending this response.
A status response to a CONNECT request means that this connection is becoming a tunnel. But the ‘close’ option in this response’s Connection header means that the server will close the connection after sending this response.
The 428 status code means that the server refuses to handle an unconditional request. But this request is conditional, because it has the header header.
RFC 6585 § 3: Responses using this status code SHOULD explain how to resubmit the
request successfully.
According to the specification, the status status code cannot be served from a cache.
RFC 6585 § 4: The response representations SHOULD include details explaining the
condition, and MAY include a Retry-After header indicating how long
to wait before making a new request.
RFC 6585 § 6: The response representation SHOULD contain a link to a resource that
allows the user to submit credentials (e.g., with an HTML form).
RFC 7538 § 3: The server SHOULD generate a Location header field ([RFC7231],
Section 7.1.2) in the response containing a preferred URI reference
for the new permanent URI.
The Basic authentication scheme requires a ‘realm’ parameter. See RFC 7617 § 2.
No ‘param’ parameter is defined for the Basic authentication scheme. See RFC 7617 § 2.
According to RFC 7617 § 2.1, the ‘charset’ parameter to the Basic authentication scheme can only have the value “UTF-8”.
In the Basic authentication scheme, credentials are sent as a single Base64 string. See RFC 7617 § 2.
In the Basic authentication scheme, the user ID and password are combined with a colon ‘:’ and packed into Base64. In this request’s header header, HTTPolice tried to decode them from Base64 and got the following error:
error
See RFC 7617 § 2.
In the Basic authentication scheme, the user ID and password are combined with a colon ‘:’ and packed into Base64. But in this request’s header header, there is no ‘:’ after decoding from Base64. See RFC 7617 § 2.
RFC 7617 § 2: The user-id and password MUST NOT contain any control characters (see
"CTL" in Appendix B.1 of [RFC5234]).
The PATCH method should only be used with media types that define how to apply the patch. value is not such a media type.
See RFC 5789 errata.
For example, application/merge-patch+json would be a suitable patch format for JSON.
RFC 5789 errata: If a server receives a PATCH
request with a media type whose specification does not define
semantics specific to PATCH, the server SHOULD reject the request by
returning the 415 Unsupported Media Type status code, unless a more
specific error status code takes priority.
RFC 5789 § 2.2: Such a response SHOULD include an
Accept-Patch response header as described in Section 3.1 to notify
the client what patch document media types are supported.
This OPTIONS response indicates in its Allow header that the PATCH method is supported. According to RFC 5789 § 3.1, in this case the server should also send an Accept-Patch header.
This response’s Accept-Patch header means that this resource supports the PATCH method, but it’s missing from the Allow header.
According to RFC 6797 § 6.1.1, a Strict-Transport-Security header must have a max-age directive.
The “max-age=0” directive in this response’s Strict-Transport-Security header tells the user agent to delete the HSTS policy for the domain. The includeSubDomains directive makes no difference in this case.
See RFC 6797 § 6.2.
RFC 6797 § 6.1: All directives MUST appear only once in an STS header field.
RFC 6797 § 7.2: An HSTS Host MUST NOT include the STS header field in HTTP responses
conveyed over non-secure transport.
“date” is not a valid date.
“time” is not a valid time.
Lines in HTTP message framing are terminated by two bytes: a carriage return (CR) followed by a line feed (LF). Some implementations accept a bare LF without CR, like in this message, but this is not reliable.
See also RFC 7230 § 3.5.
According to RFC 8288 § 3, the ‘name’ parameter must not occur more than once in a single link.
RFC 8288 § 3.3: rev is deprecated by this
specification because it often confuses authors and readers; in most
cases, using a separate relation type is preferable.
The PATCH method should only be used with media types that define how to apply the patch. patch_type is not such a media type. But this response’s Accept-Patch header invites the client to send patches of type patch_type.
See RFC 5789 errata.
For example, application/merge-patch+json would be a suitable patch format for JSON.
This message’s Upgrade header includes the token ‘h2’, which normally refers to HTTP/2 over TLS. But HTTP/2 over TLS does not use the Upgrade mechanism, and cleartext HTTP/2 uses the ‘h2c’ token instead, so “Upgrade: h2” is wrong.
See RFC 7540 § 3.
RFC 7540 § 3.2.1: Since the upgrade is only intended to apply to the immediate
connection, a client sending the HTTP2-Settings header field MUST
also send "HTTP2-Settings" as a connection option in the Connection
header field to prevent it from being forwarded
RFC 7540 § 3.2.1: A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly
one "HTTP2-Settings" header field.
According to RFC 7540 § 3.2.1, the server must not upgrade to HTTP/2 unless the request has exactly one valid HTTP2-Settings header.
An “Upgrade: h2c” header is used to switch to HTTP/2 from a cleartext HTTP/1.1 connection. But this message was sent on an encrypted (TLS) connection. HTTP/2 over TLS is negotiated by other means.
See RFC 7540 § 3.
According to RFC 7540 § 3.2.1, the HTTP2-Settings header must use the URL- and filename-safe Base64 encoding without padding. This means that it can only contain letters, digits, dash (-), and underscore (_).
There is no need to include Host in the Vary header, because Host is part of the request URI, and therefore, every HTTP response implicitly varies by Host already. “Vary: Host” can only scare caches away from storing the response.
See RFC 7231 § 7.1.4 and RFC 7234 § 2.
This request’s target is an absolute URI. According to RFC 7230 § 5.3, HTTP/1.1 clients only use this “absolute form” when connecting to proxies. Therefore, HTTPolice assumes that this request is to a proxy.
It seems like this response was transformed by a proxy, but the request was not directed to a proxy.
This response’s Cache-Control header includes both the directive1 and the directive2 directives. But directive1 makes no difference when directive2 is present.
RFC 7231 § 4.3.2: The HEAD method is identical to GET except that the server MUST NOT
send a message body in the response
RFC 7231 § 6.3.5: The 204 (No Content) status code indicates that the server has
successfully fulfilled the request and that there is no additional
content to send in the response payload body.
The Date header is the date and time when the response was originated. And the Age header is how long the response has been cached since then (or since it was revalidated). But in this response, the sum of Date + Age is in the future, so one of them must be wrong.
This can happen when a cache mistakenly changes the Date header, or adds an Age header even though it is not a true HTTP cache (according to RFC 7234).
Also, this error can be caused by wrong timezone settings.
RFC 7725 § 3: Responses using this status code SHOULD include an explanation, in
the response body, of the details of the legal demand: the party
making it, the applicable legislation or regulation, and what classes
of person and resource it applies to.
RFC 7725 § 4: When an entity blocks access to a resource and returns status 451, it
SHOULD include a "Link" HTTP header field [RFC5988] whose value is a
URI reference [RFC3986] identifying itself. When used for this
purpose, the "Link" header field MUST have a "rel" parameter whose
value is "blocked-by".
RFC 7540 § 8.1.2.2: An endpoint MUST NOT
generate an HTTP/2 message containing connection-specific header
fields
RFC 7540 § 8.1.2.2: The only exception to this is the TE header field, which MAY be
present in an HTTP/2 request; when it is, it MUST NOT contain any
value other than "trailers".
RFC 7540 § 8.1.2.2: HTTP/2 purposefully does not support upgrade to another
protocol.
RFC 7540 § 8.1.1: HTTP/2 removes support for the 101 (Switching Protocols)
informational status code
RFC 6266 § 4.1: Content-Disposition header field values with multiple instances of
the same parameter name are invalid.
RFC 6266 appendix D: Avoid including the percent character followed by two hexadecimal
characters (e.g., %A9) in the filename parameter, since some
existing implementations consider it to be an escape character,
while others will pass it through unchanged.
Such a filename can be sent in the special ‘filename*’ parameter instead. See RFC 6266 § 4.3.
RFC 6266 appendix D: Avoid including the "\" character in the quoted-string form of the
filename parameter, as escaping is not implemented by some user
agents, and "\" can be considered an illegal path character.
Such a filename can be sent in the special ‘filename*’ parameter instead. See RFC 6266 § 4.3.
RFC 6266 appendix D: Avoid using non-ASCII characters in the filename parameter.
Although most existing implementations will decode them as
ISO-8859-1, some will apply heuristics to detect UTF-8, and thus
might fail on certain names.
Such a filename can be sent in the special ‘filename*’ parameter instead. See RFC 6266 § 4.3.
RFC 6266 appendix D: When a "filename*" parameter is sent, to also generate a
"filename" parameter as a fallback for user agents that do not
support the "filename*" form, if possible.
RFC 6266 appendix D: When a "filename" parameter is included as a fallback (as per
above), "filename" should occur first, due to parsing problems in
some existing implementations.
RFC 8187 § 3.2.1: Producers MUST use the "UTF-8" ([RFC3629]) character encoding.
Extension character encodings (mime-charset) are reserved for future
use.
This message’s place contains a charset encoded value in the form defined by RFC 8187. But HTTPolice tried to decode it from charset and got the following error:
error
This message’s Alt-Svc contains a protocol ID encoded as “actual”. But according to RFC 7838 § 3, it must be encoded as “correct”.
“authority” is not a valid Alt-Svc authority, according to RFC 7838 § 3.
error
RFC 7838 § 3 recommends using ALTSVC frames instead of the Alt-Svc header on HTTP/2 connections.
RFC 7838 § 6: An Alt-Svc header field in a 421 (Misdirected Request) response MUST
be ignored.
RFC 6750 § 5.3: Clients MUST always use TLS [RFC5246]
(https) or equivalent transport security when making requests with
bearer tokens. Failing to do so exposes the token to numerous
attacks that could give attackers unintended access.
In the Bearer authentication scheme, credentials are sent as a single token. See RFC 6750 § 2.1.
According to RFC 6750 § 5.3, bearer tokens must not be used without TLS. Instead of prompting the client to send a token on an insecure connection, perhaps it would be better to redirect to an ‘https:’ URI first.
A Bearer authentication challenge must have “key=value” parameters. See RFC 6750 § 3.
According to RFC 6750 § 3, the ‘param’ parameter must not appear more than once.
“value” is not a correct value for a ‘param’ parameter in a Bearer challenge. See RFC 6750 § 3.
error
RFC 6750 § 3: If the protected resource request included an access token and failed
authentication, the resource server SHOULD include the "error"
attribute to provide the client with the reason why the access
request was declined.
According to RFC 6750 § 3.1, when the server’s Bearer challenge has “error=error_code”, the status code should be expected_status.
RFC 6750 § 3.1: If the request lacks any authentication information (e.g., the client
was unaware that authentication is necessary or attempted using an
unsupported authentication method), the resource server SHOULD NOT
include an error code or other error information.
The query string of this request’s URI contains an ‘access_token’ parameter. It’s probably a bearer token, as defined in RFC 6750.
RFC 6750 § 5.3: Bearer tokens SHOULD NOT be
passed in page URLs (for example, as query string parameters).
Instead, bearer tokens SHOULD be passed in HTTP message headers or
message bodies for which confidentiality measures are taken.
Browsers, web servers, and other software may not adequately
secure URLs in the browser history, web server logs, and other
data structures. If bearer tokens are passed in page URLs,
attackers might be able to steal them from the history data, logs,
or other unsecured locations.
This request has an ‘access_token’ parameter. It’s probably a bearer token, as defined in RFC 6750.
RFC 6750 § 5.3: Clients MUST always use TLS [RFC5246]
(https) or equivalent transport security when making requests with
bearer tokens. Failing to do so exposes the token to numerous
attacks that could give attackers unintended access.
According to RFC 6750 § 2.3, if an access token is sent in the request URI, then the request should at least have a “Cache-Control: no-store” header. This reduces the risk of caches saving this token.
A Basic authentication challenge must have parameters as “key=value” pairs. See RFC 7617 § 2.
An header header usually consists of two parts: the name of the authentication scheme, and the actual credentials. But in this request, it only contains the scheme (“item”).
Was something like “header: Bearer item” intended?
See also RFC 7235 § 2.
This message’s XML content includes entity declarations (<!ENTITY>). Many XML applications do not process such declarations because they can lead to denial-of-service attacks.
The header header is not an ordered list. Whether wildcard comes before or after value, does not affect its priority. Only explicit quality values (q=) count.
In other words, this request says that any wildcard is as acceptable as value.
If wildcard is intended to be a fallback, it should have a lower quality value, for example: wildcard;q=0.1
See RFC 7231 § 5.3.1.
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.
There is a stream file path, but there is no corresponding stream file for the reverse direction. HTTPolice will try to process this file on its own.
HTTPolice has found the following stream files:
file 1: path1
file 2: path2
but cannot detect which of them is the inbound stream and which is the outbound.
This means that the connection was not HTTP/1.x, or was encrypted, or that the files are somehow malformed. They will not be processed.
The application/json media type does not have a ‘charset’ parameter. RFC 8259 § 11: Adding one really has no effect on compliant recipients.
See also RFC 8259 § 8.1.
RFC 8259 § 8.1: JSON text exchanged between systems that are not part of a closed
ecosystem MUST be encoded using UTF-8
There is no such media type bad. Probably good was intended.
421 responses are defined as cacheable by default. However, because of how an HTTP cache works (RFC 7234 § 2), it is harmful to cache a 421 response, as it would be returned on subsequent requests to the same URI, without even trying to connect to the right server.
To avoid this, a 421 response to method should be marked as non-cacheable with a header like “Cache-Control: no-store”.
See RFC 7540 errata.
RFC 7231 § 6.3.3: The representation sent with this
response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled.
RFC 7240 § 2: To avoid any possible ambiguity, individual preference tokens SHOULD
NOT appear multiple times within a single request.
“Preference-Applied: namevalue” means that the server honored the client’s preference namevalue. But the client did not request namevalue in its Prefer header.
The whole point of a method request is to retrieve information from the server. It’s impossible to respond asynchronously to such a request: the response would not contain the requested information.
If the intention was to submit a task that would eventually send the results somewhere, this submission itself should probably be a POST.
The whole point of a GET request is to retrieve a representation of the resource (as in “return=representation”). There is no “minimal” response that could satisfy this request.
Instead, the Accept header could be used to select the desired kind of representation.
RFC 7240 § 4.2: The "return=minimal" and "return=representation" preferences are
mutually exclusive directives.
RFC 7240 § 4.4: The "handling=strict" and "handling=lenient" preferences are mutually
exclusive directives.
RFC 7240 § 2: If a server supports the optional
application of a preference that might result in a variance to a
cache's handling of a response entity, a Vary header field MUST be
included in the response listing the Prefer header field
error
error
error
RFC 7231 § 4.1: The method token is case-sensitive
RFC 7239 § 4: Each parameter MUST NOT occur more than once per field-value.
The Forwarded header here contains n_elements elements, describing n_elements proxy hops, with only one parameter for each proxy — yet all parameters have different names.
If this was intended to be n_elements parameters for a single proxy hop, then the pairs must be separated with semicolons, not commas.
This message’s place indicates that the body is at least size bytes long. HTTPolice does not attempt to process bodies longer than max_size bytes. The rest of the stream will not be processed either.
This message’s entry header contains a comma inside a quoted string. But experience shows that headers like entry are often parsed without regard for quoted strings—such a naive parser might interpret this comma as a separator between entry elements. If possible, avoiding this comma might help interoperability.
This message’s entry header contains a semicolon inside a quoted string. But experience shows that headers like entry are often parsed without regard for quoted strings—such a naive parser might interpret this semicolon as a separator between entry parameters. If possible, avoiding this semicolon might help interoperability.
“Cache-Control: immutable” is typically only useful with a large max-age or an Expires far in the future, because immutable applies only for as long as the response is considered fresh. Without explicit max-age or Expires, most caches will consider this response fresh only for a brief period or not at all.
RFC 8246: Clients SHOULD ignore the immutable extension from resources that
are not part of an authenticated context such as HTTPS.
RFC 8246: Clients SHOULD ignore the immutable extension for resources that
do not provide a strong indication that the stored response size
is the correct response size such as responses delimited by
connection close.
It appears like this status response was preceded by a status response to the same request. But a status response can only be the final response to a request. See also RFC 7231 § 6.2.
This is more likely to be a bug in your HTTPolice integration than in the actual HTTP traffic being inspected. For example, responses to different requests may have been mixed up somehow.
RFC 7230 § 6.7: If a server receives both an Upgrade and an Expect header field with
the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the
server MUST send a 100 (Continue) response before sending a 101
(Switching Protocols) response.
RFC 7231 § 3.3.1: A server MUST NOT send a
response containing Transfer-Encoding unless the corresponding
request indicates HTTP/1.1 (or later).
RFC 8288 § 3: Previous definitions of the Link header did not equate the token and
quoted-string forms explicitly; the title parameter was always
quoted, and the hreflang parameter was always a token. Senders
wishing to maximize interoperability will send them in those forms.
RFC 8288 § 3: Previous definitions of the Link header did not equate the token and
quoted-string forms explicitly; the title parameter was always
quoted, and the hreflang parameter was always a token. Senders
wishing to maximize interoperability will send them in those forms.
RFC 8288 § 3.3: The rel parameter MUST be
present
This response’s Accept-Post header means that this resource supports the POST method, but it’s missing from the Allow header.
C 1014 RWS in place should be a single space
The syntax of place includes the rule named RWS. It should be produced as just a single space, but here it was num characters. See RFC 7230 § 3.2.3.