HTTPolice is a validator or “linter” for HTTP requests and responses.
It can spot bad header syntax, inappropriate status codes, and other potential
problems in your HTTP server or client.
This manual explains all features of HTTPolice in detail.
For a hands-on introduction, jump to the Quickstart.
If you’re running Google Chrome, Firefox, or Microsoft Edge,
you can use their developer tools to export HTTP requests and responses
as a HAR file, which can then be analyzed by HTTPolice.
For example, in Firefox,
press F12 to open the toolbox, and switch to its Network pane.
Then, open a simple Web site—I’m going to use h2o.examp1e.net here.
All HTTP exchanges made by the browser appear in the Network pane.
Right-click inside that pane and select “Save All As HAR”.
Then feed this HAR file to HTTPolice:
$ httpolice -i har /path/to/file.har
------------ request: GET /------------ response: 200 OKE 1000 Syntax error in Server headerE 1013 Multiple Date headers are forbidden------------ request: GET /search/oktavia-english-search.js------------ response: 200 OKE 1000 Syntax error in Server headerE 1013 Multiple Date headers are forbiddenC 1277 Obsolete 'X-' prefix in headers------------ request: GET /assets/8mbps100msec-nginx195-h2o150.pngC 1276 Accept: */* is as good as image/webp[...and so on...]
By default, HTTPolice prints a simple text report
which may be hard to understand.
Use the -ohtml option to make a detailed HTML report instead.
You will also need to redirect it to a file:
$ httpolice -i har -o html /path/to/file.har >report.html
Suppose you’re building a Web application with Django (1.11+).
You probably have a test suite
that makes requests to your app and checks responses.
You can easily instrument this test suite with HTTPolice
and get instant feedback when you break the protocol.
$ pip3 install Django-HTTPolice
Add the HTTPolice middleware to the top of your middleware list:
$ python manage.py test...E======================================================================ERROR: test_query_plain (example_app.test.ExampleTestCase)----------------------------------------------------------------------Traceback (most recent call last): [...] File "[...]/django_httpolice/middleware.py", line 92, in process_response raise ProtocolError(exchange)django_httpolice.common.ProtocolError: HTTPolice found problems in this response:------------ request: GET /api/v1/words/?query=er------------ response: 200 OKE 1038 Bad JSON body----------------------------------------------------------------------Ran 4 tests in 0.380sFAILED (errors=1)
In this example, the app sent a wrong Content-Type header
and HTTPolice caught it.
HTTPolice is a Python package that requires Python 3.4+.
PyPy is also supported.
Like other Python packages, HTTPolice is installed with pip from PyPI.
If you’re not familiar with pip,
you may need to install it manually or from your OS distribution.
But if pipinstall starts trying (and failing) to compile some libraries,
you may need to give it a hand: check the PyPI pages for those libraries
(such as lxml or Brotli) to find versions that have suitable
pre-built binares (*-win32.whl), and install those specific versions first.
For example:
HTTPolice takes HTTP exchanges (also known as transactions) as input.
An exchange can consist of one request and one or more responses.
Usually there is just one response,
but sometimes there are interim (1xx) responses before the main one.
If you only want to check the request,
you can omit responses from the exchange.
On the other hand, if you only want to check the responses,
you should still provide the request (if possible),
because responses cannot be properly analyzed without it.
If you really have no access to the request, you can omit it,
but many checks will be disabled.
The output of HTTPolice is a report containing notices.
Every notice has an ID (such as “1061”)
that can be used to silence it,
and one of three severities:
error
Something is clearly wrong.
For example, a “MUST” requirement of a standard is clearly violated.
Please note that not all errors may be actual problems.
Sometimes there is a good reason to violate a standard.
Sometimes you just don’t care.
You decide which errors to fix and which to ignore.
If you don’t want to see an error, you can silence it.
comment
Something is possibly wrong or sub-optimal, but HTTPolice isn’t sure.
For example, a “SHOULD” requirement of a standard is clearly violated.
debug
This just explains why HTTPolice did (or did not do) something.
For example, when HTTPolice thinks that a response was served from cache,
it will report a debug notice to explain why it thinks so.
This may help you understand further cache-related notices
for that response.
You can silence notices that you don’t want to see.
They will disappear from reports and from the Python API.
Please note that some notice IDs can stand for a range of problems.
For example, most errors in header syntax are reported as notices 1000 or 1158,
so if you silence them, you may lose a big chunk of HTTPolice’s functionality.
You can also silence notices on individual messages
by adding the special HTTPolice-Silence header to them.
Its value is a comma-separated list of notice IDs. For example:
HTTP/1.1 405 Method Not AllowedContent-Length: 0HTTPolice-Silence: 1089, 1110
Requests can also silence notices on responses (but not vice-versa)
by adding a resp keyword after an ID:
GET /index.html HTTP/1.1User-Agent: Mozilla/5.0HTTPolice-Silence: 1033 resp, 1031
An obvious way to capture HTTP requests and responses
is to dump them with a network sniffer.
This only works for cleartext connections (without TLS encryption),
but on the other hand, you don’t need to change your clients or servers.
HTTPolice can parse HTTP/1.x streams from the ground up.
Parsing HTTP/2 is not yet supported.
You may be familiar with tcpdump, but it won’t work:
HTTPolice needs the reassembled TCP streams, not individual packets.
You can get these streams with a tool called tcpflow:
$ mkdir dump
$cd dump/
$ sudo tcpflow -T'%t-%A-%a-%B-%b-%#' port 80reportfilename: ./report.xmlreportfilename: ./report.xmltcpflow: listening on wlp4s0
(Note the -T option—it is necessary to get the right output.)
tcpflow starts capturing all connections to or from TCP port 80.
For example, you can launch a Web browser and go to an ‘http:’ site.
Once you are done, exit the browser, then stop tcpflow with Ctrl+C.
(It is important that connections are closed before tcpflow shuts down,
otherwise they may be incomplete.)
Now you have one or more pairs of stream files:
$ ls
1469847441-054.175.219.008-00080-172.016.000.100-38656-0 report.xml1469847441-172.016.000.100-38656-054.175.219.008-00080-0
Tell HTTPolice to read this directory with the tcpflow input format:
$ httpolice -i tcpflow .
HTTPolice will combine the files into pairs based on their filenames.
Due to a limitation in tcpflow, this only works if
every combination of source+destination address+port is unique.
If there are duplicates, you will get an error.
It’s OK if you capture some streams that are not HTTP/1.x.
HTTPolice will just complain with notices such as 1279.
This means you can run tcpflow without a filter, capturing all TCP traffic
on a given network interface, and then let HTTPolice sort it out
while silencing those notices:
tcpick is another tool for reassembling TCP streams.
It doesn’t have the “unique port” limitation of tcpflow,
but it has a different problem:
sometimes it produces files that are clearly invalid HTTP streams
(HTTPolice will fail to parse them with notices like 1009).
Anyway, using it is very similar to using tcpflow:
$ mkdir dump
$cd dump/
$ sudo tcpick -wR -F2 'port 80'Starting tcpick 0.2.1 at 2016-07-30 06:14 MSKTimeout for connections is 600tcpick: listening on wlp4s0setting filter: "port 80"[...]^C3837 packets captured30 tcp sessions detected$ httpolice -i tcpick .
Sometimes you want to compose an HTTP exchange by hand, to test something.
To make this easier, there’s a special input format
that combines the request and response streams into one file:
The lines at the beginning are ignored.
You can use them for comments.
======== BEGIN INBOUND STREAM ========
GET / HTTP/1.1
Host: example.com
User-Agent: demo
======== BEGIN OUTBOUND STREAM ========
HTTP/1.1 200 OK
Date: Thu, 31 Dec 2015 18:26:56 GMT
Content-Type: text/plain
Connection: close
Hello world!
It must be saved with CRLF (Windows) line endings.
Also, for this format, the filename suffix (extension) is important.
If it is .https, the request URI is assumed to have an https: scheme.
If it is .noscheme, the scheme is unknown.
Otherwise, the http: scheme is assumed.
Now, tell HTTPolice to use the combined format:
$ httpolice -i combined exchange1.txt
More examples can be found in HTTPolice’s test suite.
HAR is a quasi-standardized JSON format for saving HTTP traffic.
It is supported by many HTTP-related tools,
including developer consoles of some Web browsers.
HTTPolice can analyze HAR files with the -ihar option:
$ httpolice -i har myfile.har
However, please note that HAR support in exporters is erratic.
HTTPolice tries to do a reasonable job on files exported from
major Web browsers and some other HTTP tools, but some information is lost
and some checks are skipped to avoid false positives.
If HTTPolice gives unexpected results on your HAR files,
feel free to submit an issue (don’t forget to attach the files),
and I’ll see what can be done about it.
By default, HTTPolice produces simple plain text reports like this:
------------ request: PUT /articles/109226/
E 1000 Malformed If-Match header
C 1093 User-Agent contains no actual product
------------ response: 204 No Content
C 1110 204 response with no Date header
E 1221 Strict-Transport-Security without TLS
------------ request: POST /articles/109226/comments/
...
They are intended to be suitable for grep and other Unix-like tools.
Use the -ohtml option to enable much more detailed HTML reports.
These include explanations for every notice,
cross-referenced with the standards,
as well as previews of the actual requests and responses.
Please note that these previews do not represent exactly
what was sent on the wire. For example, in an HTTP/1.x request,
a header may have been split into two physical lines,
but will be rendered as one line in the report.
In the top right hand corner of an HTML report, there’s an options menu.
The first three options allow you to filter the report on the fly.
This is independent from silencing:
you cannot undo silencing with these options.
Hide boring exchanges
Check this to hide all exchanges where no problems were found
(only debug notices or none at all).
Boring notices
Additional notice IDs or severities that should not be considered problems.
For example: 1089 1135 C (C for “comment”).
Hide boring notices
Check this if you don’t want to see those boring notices at all.
They will be hidden even from exchanges that have other problems.
Other options:
Show remarks
Check this to show remarks before requests and responses, if any.
The nature of these remarks depends on where the data comes from.
If you use the httpolice command-line tool,
remarks will contain the names of the input files
and (for streams input only)
the byte offsets within those files.
This can help with debugging.
When using the httpolice command-line tool,
there’s another channel of information besides the report itself:
the command’s exit status.
If you pass the --fail-on option, the exit status will be non-zero
if any notices with the given severity (or higher) have been reported.
For example:
$ httpolice -i combined --fail-on comment test/combined_data/1125_1
------------ request: GET /------------ response: 304 Not ModifiedE 1125 Probably wrong use of status code 304$echo$?1
This can be used to take automated action (like failing tests)
without parsing the report itself.
HTTPolice can be used as a Python library:
for example, to analyze requests or responses as part of a test suite.
It is not intended to be used inside live production processes.
importioimporthttpoliceexchanges=[httpolice.Exchange(httpolice.Request(u'https',u'GET',u'/index.html',u'HTTP/1.1',[(u'Host',b'example.com')],b''),[httpolice.Response(u'HTTP/1.1',401,u'Unauthorized',[(u'Content-Type',b'text/plain')],b'No way!'),])]bad_exchanges=[]forexchinexchanges:exch.silence([1089,1227])# Errors we don't care abouthttpolice.check_exchange(exch)ifany(notice.severity>httpolice.Severity.commentforrespinexch.responses# We only care about responsesfornoticeinresp.notices):bad_exchanges.append(exch)ifbad_exchanges:withio.open('report.html','wb')asf:httpolice.html_report(bad_exchanges,f)print('%d exchanges had problems; report written to file'%len(bad_exchanges))
The request’s protocol version, as a Unicode string,
or None if unknown (this disables some checks).
For requests sent over HTTP/1.x connections,
this should be the HTTP version sent in the request line,
such as u'HTTP/1.0' or u'HTTP/1.1'.
For requests sent over HTTP/2 connections,
this should be u'HTTP/2'.
header_entries –
A list of the request’s headers (may be empty).
It must not include HTTP/2 pseudo-headers.
Every item of the list must be a (name,value) pair.
name must be a Unicode string.
value may be a byte string or a Unicode string.
If it is Unicode, HTTPolice will assume that it has been decoded
from ISO-8859-1 (the historic encoding of HTTP),
and will encode it back into ISO-8859-1 before any processing.
body –
The request’s payload body, as a byte string,
or None if unknown (this disables some checks).
If the request has no payload (like a GET request),
this should be the empty string b''.
This must be the payload body as defined by RFC 7230:
after removing any Transfer-Encoding (like chunked),
but before removing any Content-Encoding (like gzip).
trailer_entries –
A list of headers from the request’s trailer part
(as found in chunked coding or HTTP/2),
or None if there is no trailer part.
The format is the same as for header_entries.
remark – If not None, this Unicode string will be shown
above the request in HTML reports
(when the appropriate option is enabled).
For example, it can be used to identify the source of the data:
u'fromsomefile.dat,offset1337'.
notice_ids – An iterable of notice IDs that will be silenced on this object,
so they don’t appear in notices or in reports.
class httpolice.Response(version, status, reason, header_entries, body, trailer_entries=None, remark=None)¶
Parameters:
version –
The response’s protocol version, as a Unicode string,
or None if unknown (this disables some checks).
For responses sent over HTTP/1.x connections,
this should be the HTTP version sent in the status line,
such as u'HTTP/1.0' or u'HTTP/1.1'.
For responses sent over HTTP/2 connections,
this should be u'HTTP/2'.
status – The response’s status code, as an integer.
reason – The response’s reason phrase (such as “OK” or “Not Found”),
as a Unicode string, or None if unknown (as in HTTP/2).
header_entries –
A list of the response’s headers (may be empty).
It must not include HTTP/2 pseudo-headers.
Every item of the list must be a (name,value) pair.
name must be a Unicode string.
value may be a byte string or a Unicode string.
If it is Unicode, HTTPolice will assume that it has been decoded
from ISO-8859-1 (the historic encoding of HTTP),
and will encode it back into ISO-8859-1 before any processing.
body –
The response’s payload body, as a byte string,
or None if unknown (this disables some checks).
If the response has no payload (like 204 or 304 responses),
this should be the empty string b''.
This must be the payload body as defined by RFC 7230:
after removing any Transfer-Encoding (like chunked),
but before removing any Content-Encoding (like gzip).
trailer_entries –
A list of headers from the response’s trailer part
(as found in chunked coding or HTTP/2),
or None if there is no trailer part.
The format is the same as for header_entries.
remark – If not None, this Unicode string will be shown
above this response in HTML reports
(when the appropriate option is enabled).
For example, it can be used to identify the source of the data:
u'fromsomefile.dat,offset1337'.
req – The request, as a Request object.
If it is not available, you can pass None,
and the responses will be checked on their own.
However, this disables many checks
which rely on context information from the request.
resps – The responses to req,
as a list of Response objects.
Usually this will be a list of 1 element.
If you only want to check the request, pass an empty list [].
Remove and return HTTP/2 pseudo-headers from a list of headers.
Parameters:
entries – A list of header name-value pairs,
as would be passed to httpolice.Request
or httpolice.Response.
It will be modified in-place by removing all names
that start with a colon (:).
Basic checks for most of the headers defined by WHATWG Fetch,
such as Access-Control-Allow-Origin.
Updated workarounds for HAR files exported from Chrome and Firefox.
More checks are now skipped on such files, which means
fewer false positives due to missing or mangled data.
Reflecting changes in RFC 8187 and RFC 8259,
notices 1253 (bad charset) and 1281 (bad encoding for JSON)
are now reported for all encodings other than UTF-8, and
notice 1255 (ISO-8859-1 in Content-Disposition) has been removed.
Notice 1277 (obsolete ‘X-‘ prefix) is now reported only once per message.
When parsing TCP streams, HTTPolice no longer attempts to process very long
header lines (currently 16K; they will fail with notice 1006/1009)
and message bodies (currently 1G; notice 1298).
Notice 1259 (malformed parameter in Alt-Svc) has been removed: the same
problem is now reported as notice 1158.
When analyzing TCP streams, HTTPolice now reorders exchanges
based on the Date header. In other words, messages sent at the same time
on different connections are now close to each other in the report.
Checks for the Prefer mechanism (notices 1285 through 1291).
The syntax of method and header names and reason phrases is now checked
for all messages, not only for those parsed from TCP streams
(notices 1292, 1293, 1294).
Check for method names that are not uppercase (notice 1295).
The XML-related features removed in 0.4.0 have been restored.
Check for cacheable 421 (Misdirected Request) responses (notice 1283).
Check for 202 (Accepted) responses with no body (notice 1284).
HTML reports have been optimized to load slightly faster in browsers.
Titles of many notices were changed to make more sense when viewed alone
(as in text reports). If you depend on their wording (which you shouldn’t),
you may need to adjust.
The deprecated constants
httpolice.ERROR, httpolice.COMMENT, httpolice.DEBUG
have been removed. Use httpolice.Severity instead.
When checking XML payloads, HTTPolice
no longer takes precautions against denial-of-service attacks,
because the defusedxml module does not currently work with Python 3.6.
DoS attacks against HTTPolice are considered unlikely and non-critical.
Notice 1275 (“XML with entity declarations”) has been removed
for the same reason.
HTTPolice now caches more intermediate values in memory,
which makes it significantly faster in many cases.
HTTPolice now works correctly under PyPy (the 2.7 variant),
which, too, can make it faster on large inputs.
You will probably need a recent version of PyPy (5.3.1 is OK).
HTML reports now have an “options” menu
to filter exchanges and notices on the fly.
The httpolice command-line tool now has
a --fail-on option to exit with a non-zero status
if any notices with a given severity have been reported.
Work around various problems in HAR files exported by Firefox and Fiddler.
HTML reports can now display a remark before every request and response
(enabled with the Show remarks checkbox in the “options” menu).
The httpolice command-line tool puts the input filename in this remark.
With the Python API, you can put anything there
using the remark argument to Request and Response constructors.
Notices about HTTP/1.x framing errors (such as 1006)
now include the input filename as well.
Check for missing scheme name in authorization headers (notice 1274).
Check for missing quality values in headers like Accept (notice 1276).
Check for obsolete ‘X-‘ prefix in experimental headers (notice 1277).
Notice 1093 recognizes a few more product names as client libraries.
In the Python API,
the constants httpolice.ERROR, httpolice.COMMENT, httpolice.DEBUG
have been replaced with a single httpolice.Severity enumeration,
and will be removed in the next release.
PK Nx x httpolice-0.9.0/objects.inv# Sphinx inventory version 2
# Project: HTTPolice
# Version: 0.9
# The remainder of this file is compressed using zlib.
xڥn <R{{-V*yhv'laD?H&R=pɜߩP[yWi[P1#iFz7Cbf8n!9s.?Pʁ[qBC>-`/#/yVј+uf $X9 DFW|[
əsy))}j;/%\̓WV_F4
([]y ۧ(>Ua,V%ŒhrMiJ#w.8ˏpa@OB+*6p)YX&i "B=)H5}
A
4;$
Sab#TMgzWݑF8Զ8Ma^b?ֻ]1",mLC&4"6qdtYZez(V&R:?|dypnzj s|KmOWG*:C<.bّ:[[~PK NW'u u httpolice-0.9.0/notices.html
HTTPolice notices
HTTPolice notices
This is the list of all notices produced by
HTTPolice version 0.9.0.
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.
Due to previous notices, the data beginning at byte offset on the request stream name will not be parsed.
E
1008Not 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
1009Malformed response heading
error
D
1010Stop parsing response stream
Due to previous notices, the data beginning at byte offset on the response stream name will not be parsed.
D
1011Switching 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
1012Switching 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
1013Multiple 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
1014RWS 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
1015Bad 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
1016Obsolete 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
1017Strange 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 \\.
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.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
1022Empty 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.
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
1025Response 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).
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).
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
1030header 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.
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
1033Request 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.
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 JSON, but HTTPolice tried to parse it as JSON and got the following error:
error
E
1039Bad 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
1040Bad 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.
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.
According to RFC 7230 § 5.7.1, a proxy must add a Via header to each response that it forwards.
C
1047Close-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.
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
1049Switching 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.
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
1051101 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
1052header 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
1053header 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.
E
1054Trailer 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.
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.
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.
C
1059DELETE 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.
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
1061CONNECT 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.
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
1063header header is for responses
This request has the header header, which is only defined for responses.
E
1064header 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
1067Max-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
1068Unsecured 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.
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.
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.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.7: The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI.
E
1085Redirection 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
1086status 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.
C
1087status 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.
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
1090406 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.
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.
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.
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)
E
1102426 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.
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.
C
1104status 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
1105505 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.
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
1107Obsolete date-time format in place
This message’s place uses an obsolete date-time format. See RFC 7231 § 7.1.1.1.
E
1108Wrong day of week in place
This message’s place claims that date is claimed, but in reality it’s actual.
According to RFC 7231 § 7.1.1.2, every status response must have a Date header, unless the server has no usable clock.
E
1111201 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
1112Location header is undefined for status responses
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).
C
1119Backslash 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
1120Weak 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.
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.
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.
E
1124304 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
1125status 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.
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.
E
1129Preconditions 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
1130header 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.
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
1132Range 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
1133Invalid 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.
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.
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.
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.
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
1147Content-Range is undefined for status responses
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
1149416 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.
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
1151Empty 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.
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.
E
1156entry: name needs an argument
According to the specification, ‘name’ in entry must have an argument. But in this message, it doesn’t.
E
1157entry: 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
1158Syntax error in place: name
“value” is not a correct value for ‘name’ in place.
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.
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 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 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.
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
1174Response 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
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
1177status 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
1178Heuristic 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.
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
1180Heuristic 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
1181Heuristic 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
1182Heuristic 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.
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 § 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
1188Possibly 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.
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]).
E
1193Cache-Control: directive1 contradicts directive2
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.
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
1197Deprecated 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
1200428 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.
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 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.
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:
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 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.
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.
RFC 6797 § 7.2: An HSTS Host MUST NOT include the STS header field in HTTP responses
conveyed over non-secure transport.
E
1222Impossible date in place
“date” is not a valid date.
E
1223Impossible time in place
“time” is not a valid time.
E
1224LF 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.
According to RFC 8288 § 3, the ‘name’ parameter must not occur more than once in a single link.
C
1226Deprecated ‘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.
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.
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.
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
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
1233Upgrade: 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.
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.
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
1237Response 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
1238Cache-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.
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.
C
1243451 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
1244header 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".
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.
C
1251Content-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.
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
1253Bad 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
1254Bad 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:
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 § 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.
“value” is not a correct value for a ‘param’ parameter in a Bearer challenge. See RFC 6750 § 3.
error
C
1267Declined 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
1268Response 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.
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
1270Access 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
1271Access 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
1272Access 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.
A Basic authentication challenge must have parameters as “key=value” pairs. See RFC 7617 § 2.
E
1274header 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”).
C
1275Entity 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
1276header: 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
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
1278Missing 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
1279Unprocessable 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.
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”.
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.
“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 § 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
1292Invalid method ‘method’
error
E
1293Invalid field name ‘header’
error
E
1294Syntax error in reason phrase
error
E
1295Method ‘method’ should probably be ‘uppercase’
RFC 7239 § 4: Each parameter MUST NOT occur more than once per field-value.
C
1297Possibly 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
1298Body 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
1299Quoted 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
1300Quoted 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.
“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 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
1304status 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
1305Expected 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.
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
1307Unquoted ‘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
1308Quoted ‘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.
Body after removing Content-Encoding and taking the first 1000 characters
<?xml version="1.0"?>
<article>
<title>The Rise & Fall of Lorem Ipsum</title>
<text align="left">
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas venenatis posuere leo, ac facilisis lectus interdum vitae. Vestibulum venenatis facilisis turpis vel sagittis. Aenean interdum eget metus sed tincidunt. Aliquam leo metus, viverra ut fringilla id, molestie sit amet ipsum. Mauris fringilla, odio nec pretium iaculis, orci nisi luctus sapien, at efficitur odio nisi condimentum mi. Suspendisse eleifend fermentum elit in dictum. Ut ac bibendum est. Proin pretium dignissim leo ut fermentum. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus dignissim dolor ut vestibulum ultrices. Phasellus et quam bibendum, tincidunt lorem eget, laoreet ligula. Vivamus semper, metus at fringilla malesuada, metus lacus mollis dolor, quis bibendum libero augue quis mi. Curabitur suscipit enim vel lorem ornare commodo. Vestibulum a nibh bibendum, commodo lacus sit amet, molest
C
1299Quoted comma in Forwarded might confuse a naive parser
This message’s Forwarded header contains a comma inside a quoted string. But experience shows that headers like Forwarded are often parsed without regard for quoted strings—such a naive parser might interpret this comma as a separator between Forwarded elements. If possible, avoiding this comma might help interoperability.
C
1277Obsolete ‘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.
E
1039Bad XML body
According to Content-Type, this message’s body is XML, but HTTPolice tried to parse it as XML and got the following error:
not well-formed (invalid token): line 3, column 19
This request’s User-Agent header contains only the name of the underlying library, which isn’t very useful for identifying the request. It may be a good idea to include the name of the actual product.
For example: “My-Product/1.0 python-requests/2.18.4”.
In the Basic authentication scheme, the user ID and password are combined with a colon ‘:’ and packed into Base64. In this request’s Authorization header, HTTPolice tried to decode them from Base64 and got the following error:
The PATCH method should only be used with media types that define how to apply the patch. text/xml is not such a media type. But this response’s Accept-Patch header invites the client to send patches of type text/xml.
This message’s Cache-Control header includes both the private and the no-store directives, which contradict each other.
E
1090406 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.
PK N( httpolice-0.9.0/.buildinfo# Sphinx build info version 1
# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
config: efcca6b6831397ba17e8b042bf34b9e6
tags: 0957a7f5604f7fa265ade309e7b795c2
PK
N,՚ / httpolice-0.9.0/_images/mitmproxy-httpolice.pngPNG
IHDR
ͱ sBIT|d IDATx{T[?n "mf0:nzv2is%sVi]sJ8iɴI3eė&61@B @$t찑@[B`pZYѣw6c!B!%B 8v;!BY3?^a7B!iB!B ǫ`Ћ/h/|hMfhllDYYrf6}H!B#`ns%+_H$B`` 233ĉX,.(պ !Bf'ODWWvD̈́B!8שj@.cxxW\+W ?p
ٽ/~_]wMM
ߏ2f[RRшR\vy~Ok.DFFbbbMMM8}49+___bÆ
dZ˗q]$B!Dz۶mgh4ȑ#E}}=߿(tTT߿Z-6lѣGAAA7^ _$Φvܹs耗
p!Lܲo}MMMo1HRbΝHB!Dzϕ;v?ƃ 8y$
Q__vDEE/~_crrhoo_Bw)bqAAΝ; @WWN><&woٌsg?ْHhh(>C F#!B{8lU`` :;;Y
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.