HTTPolice notices

This is the list of all notices produced by HTTPolice version 0.9.0.

See also the HTTPolice manual.

E 1000 Syntax error in place header

error

E 1001 Final Transfer-Encoding must be ‘chunked

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.

E 1002 Transfer-Encoding can’t have ‘chunked’ twice

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

D 1003 Not decoding Transfer-Encoding: coding

HTTPolice does not know how to decode the coding transfer coding. (This doesn’t mean that it’s wrong.)

E 1004 Message is incomplete according to Content-Length

This message’s Content-Length header indicates that the body is value bytes long, but there are fewer bytes remaining on the stream name.

E 1005 Malformed Transfer-Encoding: chunked

error

E 1006 Malformed request heading

error

D 1007 Stop parsing request stream

Due to previous notices, the data beginning at byte offset on the request stream name will not be parsed.

E 1008 Not enough requests

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.

E 1009 Malformed response heading

error

D 1010 Stop parsing response stream

Due to previous notices, the data beginning at byte offset on the response stream name will not be parsed.

D 1011 Switching protocols

The 101 status code means that the connection is switching to a different protocol. HTTPolice will not parse the rest of the streams.

D 1012 Switching to a tunnel

A status response to a CONNECT request means that the connection is becoming a tunnel. HTTPolice will not parse the remainder of the streams.

E 1013 Multiple header headers are forbidden

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

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.

E 1015 Bad whitespace (BWS) in place

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.

E 1016 Obsolete line folding in headers

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.

C 1017 Strange escaping in place

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

E 1018 Transfer-Encoding is forbidden in a status response

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

E 1019 Transfer-Encoding is forbidden in a status response to CONNECT

RFC 7230 § 3.3.1: A server MUST NOT send a Transfer-Encoding header field in any 2xx (Successful) response to a CONNECT request

E 1020 Can’t have both Transfer-Encoding and Content-Length

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.

C 1021 method request should have Content-Length

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

C 1022 Empty method request shouldn’t have Content-Length

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.

E 1023 Content-Length is forbidden in a status 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).

E 1024 Content-Length is forbidden in a status response to CONNECT

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

C 1025 Response delimited only by closing the connection

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.

E 1026 entry is forbidden in a trailer

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

E 1027 Could not decode Transfer-Encoding: coding

error

E 1028 TE: chunked” is forbidden

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.

E 1029 TE header requires “Connection: TE”

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.

C 1030 header was not announced in the Trailer header

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.

E 1031 Missing Host header

RFC 7230 § 5.4: A client MUST send a Host header field in all HTTP/1.1 request messages.

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.

E 1033 Request with a bad Host header must be rejected

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.

E 1034 Connection: header” is forbidden

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

C 1035 Deprecated media type value

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.

D 1036 Not decoding Content-Encoding: coding

HTTPolice does not know how to decode the coding content coding. (This doesn’t mean that it’s wrong.)

E 1037 Could not decode Content-Encoding: coding

error

E 1038 Bad JSON body

According to Content-Type, this message’s body is JSON, but HTTPolice tried to parse it as JSON and got the following error:

error

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:

error

E 1040 Bad URL-encoded body

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.

C 1041 Body should have a Content-Type

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.

C 1042 Duplicate ‘param’ parameter in Content-Type

RFC 6838 § 4.3: It is an error for a specific parameter to be specified more than once.

E 1045 Syntax error in request target

error

See also RFC 7230 § 5.3.

E 1046 Proxied response needs a Via header

According to RFC 7230 § 5.7.1, a proxy must add a Via header to each response that it forwards.

C 1047 Close-delimited response should have “Connection: close”

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.

E 1048 101 response needs an Upgrade header

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

E 1049 Switching to a protocol that was not requested

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.

E 1050 Upgrade header requires “Connection: upgrade”

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.

E 1051 101 response to an HTTP/1.0 request is forbidden

RFC 7230 § 6.7: A server MUST ignore an Upgrade header field that is received in an HTTP/1.0 request.

E 1052 header makes no sense in a status response

The header header provides representation metadata, but there can be no representation associated with a status response. The header should probably be removed.

C 1053 header makes no sense in an empty request

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.

E 1054 Trailer header makes no sense without a chunked body

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.

C 1055 Unnecessary Content-Location

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.

C 1056 GET request with a body may cause problems

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.

C 1057 HEAD request with a body may cause problems

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.

E 1058 PUT request with Content-Range must be rejected

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.

C 1059 DELETE request with a body may cause problems

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.

E 1060 Strange Content-Location in response to DELETE

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.

C 1061 CONNECT request with a body may cause problems

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.

E 1062 OPTIONS request with a body needs Content-Type

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.

E 1063 header header is for responses

This request has the header header, which is only defined for responses.

E 1064 header header is for requests

This response has the header header, which is only defined for requests.

E 1066 Expect: 100-continue” is forbidden on empty 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.

C 1067 Max-Forwards header is undefined for method requests

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.

E 1068 Unsecured request must not have a Referer with ‘https:’

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.

C 1070 Missing User-Agent header

RFC 7231 § 5.5.3: A user agent SHOULD send a User-Agent field in each request unless specifically configured not to do so.

E 1071 status response to an HTTP/1.0 request is forbidden

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.

E 1072 201 response to method makes no sense

The method method is defined as safe (read-only). But the 201 status code means that a new resource was created.

C 1073 Possibly missing Location header

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.

E 1074 202 response to method makes no sense

The method method is defined as safe (read-only). But the 202 status code means that the server started some kind of processing operation.

E 1076 205 response must not have a body

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.

C 1077 300 response should have a body

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.

C 1078 301 response should have a Location header

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.

C 1079 302 response should have a Location header

RFC 7231 § 6.4.3: The server SHOULD generate a Location header field in the response containing a URI reference for the different URI.

E 1080 303 response needs a Location header

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.

C 1081 303 response should have a body

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.

E 1082 Status code 305 is deprecated

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

E 1083 Status code 306 is reserved

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.

C 1084 307 response should have a Location header

RFC 7231 § 6.4.7: The server SHOULD generate a Location header field in the response containing a URI reference for the different URI.

E 1085 Redirection to the same URI

This status response includes a Location header that points to the same URI as the request URI. So the resource redirects to itself.

E 1086 status response to server-wide OPTIONS makes no sense

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.

C 1087 status response should include an explanation

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.

E 1088 Status code 402 is reserved

RFC 7231 § 6.5.2: The 402 (Payment Required) status code is reserved for future use.

E 1089 405 response needs an Allow header

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.

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.

C 1092 406 response should have a body

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.

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 library”.

Or simply “My-Product/1.0” or “My-Product”.

See RFC 7231 § 5.5.3.

C 1094 408 response should have “Connection: close”

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.

E 1095 409 response to method makes no sense

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.

C 1096 409 response should include an explanation

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.

E 1097 411 response, but request did have Content-Length

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.

E 1098 413 response, but request had no body

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.

E 1099 415 response, but request had no body

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.

E 1100 417 response, but request had no Expect

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.

E 1101 426 response needs an Upgrade header

RFC 7231 § 6.5.15: The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s)

E 1102 426 response, but client is ready to upgrade

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.

E 1103 Not proceeding with protocol upgrade

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.

C 1104 status response should include an explanation

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.

E 1105 505 response, but request had the same HTTP version

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.

C 1106 505 response should have a body

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.

E 1107 Obsolete date-time format in place

This message’s place uses an obsolete date-time format. See RFC 7231 § 7.1.1.1.

E 1108 Wrong day of week in place

This message’s place claims that date is claimed, but in reality it’s actual.

E 1109 Date header is in the future

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.

C 1110 Missing Date header

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

E 1111 201 response can’t have Location with a fragment (#)

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.

C 1112 Location header is undefined for status responses

RFC 7231 § 7.1.2 does not define what it means for a status response to have a Location header.

C 1113 Retry-After is undefined for status responses

As far as HTTPolice knows, the Retry-After header is defined for status codes 3xx, 413, 429, and 503, but not for status.

E 1114 405 response, but Allow includes method

The 405 status code means that the request method (method) is not allowed for this resource. But the Allow header does include method.

E 1115 Allow does not 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).

E 1116 Accept-Encoding: coding must not have a quality value

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.

C 1117 Accept-Language shouldn’t trigger a 406 response

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.

E 1118 Last-Modified can’t be later than Date

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

C 1119 Backslash in place may cause problems

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.

E 1120 Weak entity tag in If-Match is not supposed to work

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.

E 1121 If-None-Match was ignored

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.

E 1122 If-Modified-Since in method requests is not supposed to work

According to RFC 7232 § 3.3, an If-Modified-Since header must be ignored in requests that are neither GET nor HEAD.

C 1123 If-Modified-Since was ignored

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.

E 1124 304 response is undefined for method requests

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.

E 1125 status response, but request has no preconditions

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.

C 1127 304 response should not have header

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

E 1128 If-Modified-Since on method must be ignored

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.

E 1129 Preconditions on method 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.

E 1130 header on method makes no sense

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.

C 1131 Conditional HEAD request is pointless

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.

E 1132 Range header on method is not supposed to work

RFC 7233 § 3.1: A server MUST ignore a Range header field received with a request method other than GET.

E 1133 Invalid byte range in place

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.

E 1134 If-Range requires a Range header

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.

E 1135 Weak entity tags are forbidden in If-Range

RFC 7233 § 3.2: A client MUST NOT generate an If-Range header field containing an entity-tag that is marked as weak.

E 1136 206 response, but request had no Range

The 206 status code only makes sense in responses to partial requests—that is, requests with a Range header. See RFC 7233 § 4.1.

E 1137 206 response to method is forbidden

RFC 7233 § 3.1: A server MUST ignore a Range header field received with a request method other than GET.

E 1138 206 response needs range specifiers

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.

E 1139 Multipart boundary not declared

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.

E 1140 Multipart boundary not found

The multipart boundary declared in this message’s Content-Type was not found in the body.

See RFC 2046 § 5.1.1.

E 1141 No Content-Range in part #part_num

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.

C 1142 No Content-Type in part #part_num

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.

E 1143 Content-Range in a multipart/byteranges response is forbidden

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

E 1144 multipart/byteranges response can’t be used for a single Range

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.

E 1145 206 response, but ETag doesn’t match If-Range

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.

C 1146 Unnecessary header header

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.

E 1147 Content-Range is undefined for status responses

The Content-Range header is defined by RFC 7233 § 4.2 for responses with status codes 206 and 416, but not status.

E 1148 Invalid byte range in place

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.

E 1149 416 response to request without Range makes no sense

The 416 status code is defined by RFC 7233 § 4.4 only for responses to requests that have a Range header.

C 1150 416 response should have Content-Range

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

E 1151 Empty list elements in place are forbidden

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

E 1152 Cache-Control: directive is for responses

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

E 1153 Cache-Control: directive is for requests

This response’s Cache-Control header includes the directive directive, which is only defined for requests.

C 1154 Cache-Control: directive should be quoted

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.

C 1155 Cache-Control: directive should not be 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.

E 1156 entry: name needs an argument

According to the specification, ‘name’ in entry must have an argument. But in this message, it doesn’t.

E 1157 entry: name can’t have an argument

In this message’s entry header, ‘name’ has an argument. But the specification defines no argument for ‘name’.

E 1158 Syntax error in place: name

value” is not a correct value for ‘name’ in place.

error

E 1159 Cache-Control: no-cache can’t have an argument

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.

C 1160 Pragma other than ‘no-cache’ is deprecated

This message’s Pragma header includes ‘pragma’, but all pragmas other than ‘no-cache’ are deprecated in RFC 7234 § 5.4.

C 1161 Cache-Control: no-cache” should also have “Pragma: no-cache”

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.

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 1163 Warn code code not in range 100—299

RFC 7234 § 5.5 defines two classes of warn codes: 1xx and 2xx. But this message’s Warning header contains a code code.

E 1164 Warning date must match the Date header

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.

E 1165 Warning: code” is for responses

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.

E 1166 Response from cache needs an Age header

According to RFC 7234 § 4, a cache must add an Age header to every response that is served without contacting the origin server.

E 1167 Status code status not in range 100—599

According to RFC 7231 § 6, HTTP status codes can only range from 100 to 599.

D 1168 Age header implies response from cache

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.

D 1169 Warning: code” implies response from cache

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.

C 1170 Response from cache older than max-age

This response’s Age of value is greater than the max-age of max_age requested by the client’s Cache-Control header.

C 1171 Cache-Control: directive has no effect on method

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

E 1172 Response to method can’t be served from cache

The method method is defined as non-cacheable.

E 1173 Response to “Cache-Control: no-cache” can’t be served from cache

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.

E 1174 Response to “Pragma: no-cache” can’t be served from cache

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

E 1175 Response with “Cache-Control: no-cache” can’t be served from cache

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.

E 1176 Response with “Cache-Control: no-store” can’t be served from cache

According to RFC 7234 § 3, a cache cannot store a response that includes the no-store directive in its Cache-Control header.

E 1177 status response can’t be served from cache by default

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.

D 1178 Heuristic freshness

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.

D 1179 Warning: 113” implies heuristic freshness

The 113 warn code in this response’s Warning header means that the expiration time for this response was chosen heuristically by the cache.

C 1180 Heuristic freshness should have “Warning: 113

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.

E 1181 Heuristic freshness can’t be used when Expires is 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.

E 1182 Heuristic freshness can’t be used when max-age is 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.

C 1183 Warning: code” implies response is stale

The code warn code in this response’s Warning header means that the response is stale, as defined by RFC 7234 § 4.2.

C 1184 Response is stale because Age > max-age

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.

C 1185 Response is stale because Age > Expires − Date

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.

C 1186 Stale response should have “Warning: 110

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.

E 1187 Response with “Cache-Control: must-revalidate” can’t be served stale

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.

C 1188 Possibly wrong stale response

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.

D 1189 Warning: 214” means transformed by proxy

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.

D 1190 Status 203 means transformed by proxy

The 203 status code means that this response was transformed by a proxy.

See also RFC 7230 § 5.7.2.

E 1191 Transformed message needs “Warning: 214

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

E 1192 Transformation forbidden by “Cache-Control: no-transform

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

E 1193 Cache-Control: directive1 contradicts directive2

This message’s Cache-Control header includes both the directive1 and the directive2 directives, which contradict each other.

E 1194 401 response needs a WWW-Authenticate header

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.

E 1195 407 response needs a Proxy-Authenticate header

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.

E 1196 ‘realm’ parameter in place must be quoted

According to RFC 7235 § 2.2, the value of the ‘realm’ parameter must be enclosed in double quotes.

C 1197 Deprecated header header

This message has the header header, which is listed as “obsoleted” or “deprecated” in the IANA message headers registry.

E 1198 Connection: close” makes no sense in status response

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.

E 1199 Connection: close” makes no sense in status response to CONNECT

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.

C 1200 428 response, but request has a header precondition

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.

C 1201 428 response should include an explanation

RFC 6585 § 3: Responses using this status code SHOULD explain how to resubmit the request successfully.

E 1202 status response can’t be served from cache

According to the specification, the status status code cannot be served from a cache.

C 1203 429 response should include an explanation

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.

C 1204 511 response should have a body

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

C 1205 308 response should have a Location header

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.

E 1206 header: Basic must have ‘realm’

The Basic authentication scheme requires a ‘realm’ parameter. See RFC 7617 § 2.

E 1207 header: Basic can’t have a ‘param’ parameter

No ‘param’ parameter is defined for the Basic authentication scheme. See RFC 7617 § 2.

E 1208 header: Basic can’t have a ‘charset’ charset

According to RFC 7617 § 2.1, the ‘charset’ parameter to the Basic authentication scheme can only have the value “UTF-8”.

E 1209 Malformed header: Basic

In the Basic authentication scheme, credentials are sent as a single Base64 string. See RFC 7617 § 2.

E 1210 Malformed header: Basic

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.

E 1211 Malformed header: Basic

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.

E 1212 header: Basic can’t contain character char

RFC 7617 § 2: The user-id and password MUST NOT contain any control characters (see "CTL" in Appendix B.1 of [RFC5234]).

C 1213 Content-Type: value is not suitable for PATCH

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.

C 1214 value patch should be rejected

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.

C 1215 415 response to PATCH should have Accept-Patch

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.

C 1216 Should send Accept-Patch with “AllowPATCH

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.

E 1217 Accept-Patch implies “AllowPATCH

This response’s Accept-Patch header means that this resource supports the PATCH method, but it’s missing from the Allow header.

E 1218 HSTS needs a ‘max-age’ directive

According to RFC 6797 § 6.1.1, a Strict-Transport-Security header must have a max-age directive.

C 1219 HSTS: includeSubDomains has no effect with max-age=0

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.

E 1220 Duplicate ‘directive’ directive in HSTS

RFC 6797 § 6.1: All directives MUST appear only once in an STS header field.

E 1221 Strict-Transport-Security can’t be used without TLS

RFC 6797 § 7.2: An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.

E 1222 Impossible date in place

date” is not a valid date.

E 1223 Impossible time in place

time” is not a valid time.

E 1224 LF without CR in place

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.

E 1225 Duplicate ‘name’ parameter in place

According to RFC 8288 § 3, the ‘name’ parameter must not occur more than once in a single link.

C 1226 Deprecated ‘rev’ parameter in place

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.

C 1227 patch_type is not suitable for Accept-Patch

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.

E 1228 Upgrade: h2 is wrong

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.

E 1230 HTTP2-Settings needs “Connection: http2-settings”

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

E 1231 Upgrade: h2c needs HTTP2-Settings

RFC 7540 § 3.2.1: A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly one "HTTP2-Settings" header field.

E 1232 Upgrading to HTTP/2 despite bad HTTP2-Settings

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.

E 1233 Upgrade: h2c can’t be used on a TLS connection

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.

E 1234 Malformed HTTP2-Settings

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

C 1235 Vary: Host is useless

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.

D 1236 Absolute URI implies request to proxy

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.

E 1237 Response to a direct request can’t be transformed by a proxy

It seems like this response was transformed by a proxy, but the request was not directed to a proxy.

C 1238 Cache-Control: directive1 has no effect with directive2

This response’s Cache-Control header includes both the directive1 and the directive2 directives. But directive1 makes no difference when directive2 is present.

E 1239 Response to HEAD can’t have a body

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

E 1240 204 response can’t have a body

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.

E 1241 Date + Age is in the future

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.

C 1242 451 response should include an explanation

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.

C 1243 451 response should have a ‘blocked-by’ link

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

E 1244 header header can’t be used in HTTP/2

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

E 1245 Upgrade header can’t be used in HTTP/2

RFC 7540 § 8.1.2.2: HTTP/2 purposefully does not support upgrade to another protocol.

E 1246 101 response can’t be used in HTTP/2

RFC 7540 § 8.1.1: HTTP/2 removes support for the 101 (Switching Protocols) informational status code

E 1247 Duplicate ‘param’ parameter in Content-Disposition

RFC 6266 § 4.1: Content-Disposition header field values with multiple instances of the same parameter name are invalid.

C 1248 Percent-encoded filename in Content-Disposition may cause problems

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.

C 1249 Backslash in filename in Content-Disposition may cause problems

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.

C 1250 Non-ASCII filename in Content-Disposition may cause problems

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.

C 1251 Content-Disposition: ‘filename*’ should also have ‘filename’ as fallback

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.

C 1252 Content-Disposition: ‘filename*’ should come after ‘filename’

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.

E 1253 Bad charset ‘charset’ in place

RFC 8187 § 3.2.1: Producers MUST use the "UTF-8" ([RFC3629]) character encoding. Extension character encodings (mime-charset) are reserved for future use.

E 1254 Bad charset value in place

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

E 1256 Bad encoding of protocol ID in Alt-Svc

This message’s Alt-Svc contains a protocol ID encoded as “actual”. But according to RFC 7838 § 3, it must be encoded as “correct”.

E 1257 Malformed authority in Alt-Svc

authority” is not a valid Alt-Svc authority, according to RFC 7838 § 3.

error

C 1258 HTTP/2 should use ALTSVC frame instead of Alt-Svc header

RFC 7838 § 3 recommends using ALTSVC frames instead of the Alt-Svc header on HTTP/2 connections.

E 1260 421 response can’t have Alt-Svc

RFC 7838 § 6: An Alt-Svc header field in a 421 (Misdirected Request) response MUST be ignored.

E 1261 Authorization: Bearer requires TLS

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.

E 1262 Malformed Authorization: Bearer

In the Bearer authentication scheme, credentials are sent as a single token. See RFC 6750 § 2.1.

E 1263 WWW-Authenticate: Bearer requires TLS

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.

E 1264 Malformed WWW-Authenticate: Bearer

A Bearer authentication challenge must have “key=value” parameters. See RFC 6750 § 3.

E 1265 Duplicate ‘param’ parameter in “WWW-Authenticate: Bearer

According to RFC 6750 § 3, the ‘param’ parameter must not appear more than once.

E 1266 Malformed ‘param’ parameter in WWW-Authenticate

value” is not a correct value for a ‘param’ parameter in a Bearer challenge. See RFC 6750 § 3.

error

C 1267 Declined a Bearer token, but no ‘error’ parameter

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.

C 1268 Response with “error=error_code” should be expected_status

According to RFC 6750 § 3.1, when the server’s Bearer challenge has “error=error_code”, the status code should be expected_status.

C 1269 Unneeded ‘param’ in WWW-Authenticate

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.

C 1270 Access token in URI is insecure

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.

C 1271 Access token may need TLS

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.

C 1272 Access token in URI needs “Cache-Control: no-store”

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.

E 1273 Malformed header: Basic

A Basic authentication challenge must have parameters as “key=value” pairs. See RFC 7617 § 2.

E 1274 header header without credentials

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 “headerBearer item” intended?

See also RFC 7235 § 2.

C 1275 Entity declarations in XML may cause problems

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.

C 1276 header: wildcard is as good as value

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.

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 1278 Missing reverse stream

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.

E 1279 Unprocessable streams

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.

C 1280 ‘charset’ parameter is undefined for application/json

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.

E 1281 guessed_charset is a bad encoding for JSON

RFC 8259 § 8.1: JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8

E 1282 Wrong media type bad in place

There is no such media type bad. Probably good was intended.

C 1283 Cacheable 421 response may cause problems

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.

C 1284 202 response should have a body

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.

C 1285 Duplicate ‘name’ token in Prefer

RFC 7240 § 2: To avoid any possible ambiguity, individual preference tokens SHOULD NOT appear multiple times within a single request.

E 1286 Preference-Applied: namevalue was not requested

Preference-Applied: namevalue” means that the server honored the client’s preference namevalue. But the client did not request namevalue in its Prefer header.

E 1287 method request cannot Prefer: respond-async

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.

E 1288 GET request cannot Prefer: return=minimal

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.

E 1289 Prefer: return=minimal contradicts return=representation

RFC 7240 § 4.2: The "return=minimal" and "return=representation" preferences are mutually exclusive directives.

E 1290 Prefer: handling=strict contradicts handling=lenient

RFC 7240 § 4.4: The "handling=strict" and "handling=lenient" preferences are mutually exclusive directives.

C 1291 Response with Preference-Applied may need “Vary: Prefer

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

E 1292 Invalid method ‘method

error

E 1293 Invalid field name ‘header

error

E 1294 Syntax error in reason phrase

error

E 1295 Method ‘method’ should probably be ‘uppercase

RFC 7231 § 4.1: The method token is case-sensitive

E 1296 Duplicate ‘param’ parameter in entry

RFC 7239 § 4: Each parameter MUST NOT occur more than once per field-value.

C 1297 Possibly bad syntax in entry

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.

D 1298 Body is too long to be checked

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.

C 1299 Quoted comma in entry might confuse a naive parser

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.

C 1300 Quoted semicolon in entry might confuse a naive parser

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.

C 1301 Cache-Control: immutable probably needs max-age

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.

C 1302 Cache-Control: immutable may be ignored without TLS

RFC 8246: Clients SHOULD ignore the immutable extension from resources that are not part of an authenticated context such as HTTPS.

C 1303 Cache-Control: immutable may be ignored without response length

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.

E 1304 status response after status

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.

E 1305 Expected 100 (Continue) before switching protocols

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.

E 1306 Response to version can’t have Transfer-Encoding

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

C 1307 Unquoted ‘title’ parameter in place may cause problems

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.

C 1308 Quoted ‘hreflang’ parameter in place may cause problems

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.

E 1309 Missing ‘rel’ parameter in place

RFC 8288 § 3.3: The rel parameter MUST be present

E 1310 Accept-Post implies “AllowPOST

This response’s Accept-Post header means that this resource supports the POST method, but it’s missing from the Allow header.