-
Notifications
You must be signed in to change notification settings - Fork 88
/
Copy pathhttpolice-notices-list.html
3176 lines (3117 loc) · 237 KB
/
httpolice-notices-list.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="en">
<head>
<title>HTTPolice notices</title>
<meta charset="utf-8">
<meta content="HTTPolice 0.7.0" name="generator">
<style type="text/css">/****************************************************************
* Common styles
****************************************************************/
body {
color: black;
font-family: sans-serif;
quotes: '“' '”';
}
body.report {
/* I hate this line with a passion, but so far I can't figure out
* how else to make both sans-serif and monospace fonts look reasonable
* on a wide range of browsers and platforms. */
font-size: 14px;
}
@media screen { /* Print margins are OK already. */
body {
margin: 2em;
}
}
h1 {
font-size: x-large;
margin-bottom: 0;
}
h2, h3 {
font-size: inherit;
font-weight: inherit;
}
pre, code {
font-family: 'Consolas', monospace;
}
a[href] {
color: inherit;
text-decoration: inherit;
border-bottom: thin dotted;
}
cite {
font-style: inherit;
}
q {
font-style: italic;
}
abbr {
text-decoration: inherit;
border: inherit;
}
hr {
visibility: hidden;
clear: both;
}
button {
/* Make it look more like a pseudo-link. */
background: transparent;
border-top: none;
border-right: none;
border-bottom: thin dotted;
border-left: none;
padding: 0;
color: gray;
cursor: pointer;
}
@media print {
button {
display: none;
}
}
/****************************************************************
* Request and response data
****************************************************************/
body.report {
background: whitesmoke;
}
div.exchange {
background: white;
margin-top: 3em;
}
@media screen {
div.exchange {
/* Bottom padding is smaller
* because there is an invisible ``hr`` there. */
padding: 2em 2em 1.5em 2em;
border: solid thin darkgray;
}
}
div.message-display {
max-width: 55em;
}
.exchange > section:not(:first-child) div.message-display {
/* Spacing between messages within one exchange. */
margin-top: 2em;
}
p.message-remark {
margin: 0 1em 0.5em 0;
color: gray;
overflow: auto;
}
.message-display h2 {
font-weight: bolder;
margin: 0;
overflow: auto;
padding: 0 0 0.3em 0;
white-space: nowrap;
}
pre.header-entry {
margin: 0;
white-space: pre-wrap;
overflow: auto;
padding: 0.2em 0;
line-height: 140%;
/* Indent all lines after the first one, a la ``obs-fold``. */
padding-left: 2em;
text-indent: -2em;
}
div.body-display, div.trailer {
margin-top: 2em;
}
.body-display h3, .trailer h3 {
display: inline-block;
border-bottom: thin dashed;
padding: 0.3em 0;
margin: 0;
color: darkgray;
}
.body-display pre {
margin-top: 0.7em;
margin-bottom: 0;
white-space: pre-wrap;
max-height: 20em;
overflow: auto;
}
/****************************************************************
* Notices
****************************************************************/
div.complaints {
padding-left: 1em;
border-left: thin solid lightgray;
}
.exchange > section:not(:first-child) div.complaints {
margin-top: 2em;
}
div.notice {
max-width: 55em;
page-break-inside: avoid;
line-height: 135%;
}
.notice:not(.collapsed) + div.notice {
/* More spacing between expanded notices. */
margin-top: 2em;
}
.debug .severity {
color: darkgray;
}
.error .severity {
color: red;
}
.notice .ident {
color: darkgray;
}
/****************************************************************
* Float notices to the right on wider displays
****************************************************************/
@media (min-width: 55em) {
div.message-display {
float: left;
width: 55%;
}
div.complaints {
float: right;
width: 40%;
}
}
/****************************************************************
* Interactive notices
****************************************************************/
.notice button {
float: right;
margin-left: 1em;
font-size: smaller;
}
@media screen { /* Don't collapse notices in print. */
.notice.collapsed p {
display: none;
}
.notice.debug.collapsed h3 {
color: darkgray;
}
}
.highlight {
background: navajowhite;
}
/****************************************************************
* Options
****************************************************************/
div.options {
float: right;
}
@media print {
.options {
display: none;
}
}
@media screen {
.options.collapsed form {
display: none;
}
}
.options form {
margin-top: 0.3em;
padding: 0.1em 1em;
background: lavender;
border: solid thin darkgray;
white-space: nowrap;
}
form input + label, form label + input {
margin-left: 0.5em;
}
/****************************************************************
* List of all notices
****************************************************************/
@media screen {
body.notices-list {
max-width: 55em;
margin-left: auto;
margin-right: auto;
}
}
.notices-list div.notice {
margin-top: 4em !important;
}
.notices-list h3 {
font-size: larger;
font-weight: bolder;
}
.notices-list var {
font-style: inherit;
display: inline-block;
background: lavender;
border: solid thin gray;
padding: 0 0.1em;
}
</style>
<base target="_blank">
</head>
<body class="notices-list">
<h1>HTTPolice notices</h1>
<p>This is the list of all notices produced by
<a href="https://github.com/vfaronov/httpolice" target="_self">HTTPolice</a> version 0.7.0.
</p>
<p>See also the
<a href="index.html" target="_self">HTTPolice manual</a>.
</p>
<div class="notice error" id="1000">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1000</span>
<span>Syntax error in <span data-ref-to="0"><var>place</var></span> header</span>
</h3>
<p><var>error</var></p>
</div>
<div class="notice error" id="1001">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1001</span>
<span>Final <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1" title="RFC 7230 § 3.3.1">Transfer-Encoding</a></span> must be ‘<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.1" title="RFC 7230 § 4.1">chunked</a></span>’</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1">RFC 7230 § 3.3.1</a></cite>: <q>If any transfer coding
other than <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.1" title="RFC 7230 § 4.1">chunked</a></span> is applied to a request payload body, the sender
MUST apply <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.1" title="RFC 7230 § 4.1">chunked</a></span> as the final transfer coding to ensure that the
message is properly framed.</q></p>
</div>
<div class="notice error" id="1002">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1002</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1" title="RFC 7230 § 3.3.1">Transfer-Encoding</a></span> can’t have ‘<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.1" title="RFC 7230 § 4.1">chunked</a></span>’ twice</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1">RFC 7230 § 3.3.1</a></cite>: <q>A sender MUST
NOT apply <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.1" title="RFC 7230 § 4.1">chunked</a></span> more than once to a message body (i.e., chunking an
already chunked message is not allowed).</q></p>
</div>
<div class="notice debug" id="1003">
<h3>
<abbr class="severity" title="debug">D</abbr>
<span class="ident">1003</span>
<span>Not decoding <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1" title="RFC 7230 § 3.3.1">Transfer-Encoding</a></span>: <span data-ref-to="1"><var>coding</var></span></span>
</h3>
<p>HTTPolice does not know how to decode the <span data-ref-to="2"><var>coding</var></span> transfer coding. (This doesn’t mean that it’s wrong.)</p>
</div>
<div class="notice error" id="1004">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1004</span>
<span>Message is incomplete according to <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2" title="RFC 7230 § 3.3.2">Content-Length</a></span></span>
</h3>
<p>This message’s <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2" title="RFC 7230 § 3.3.2">Content-Length</a></span> header indicates that the body is <span data-ref-to="3"><var>value</var></span> bytes long, but there are fewer bytes remaining on the stream <span data-ref-to="4"><var>name</var></span>.</p>
</div>
<div class="notice error" id="1005">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1005</span>
<span>Malformed <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1" title="RFC 7230 § 3.3.1">Transfer-Encoding</a></span>: <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.1" title="RFC 7230 § 4.1">chunked</a></span></span>
</h3>
<p><var>error</var></p>
</div>
<div class="notice error" id="1006">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1006</span>
<span>Malformed request heading</span>
</h3>
<p><var>error</var></p>
</div>
<div class="notice debug" id="1007">
<h3>
<abbr class="severity" title="debug">D</abbr>
<span class="ident">1007</span>
<span>Stop parsing request stream</span>
</h3>
<p>Due to previous notices, the data beginning at byte <span data-ref-to="5"><var>offset</var></span> on the request stream <span data-ref-to="6"><var>name</var></span> will not be parsed.</p>
</div>
<div class="notice error" id="1008">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1008</span>
<span>Not enough requests</span>
</h3>
<p>There are unparsed bytes remaining on the response stream <span data-ref-to="7"><var>name</var></span>, but no requests that would correspond to them. HTTPolice will try to parse and analyze the remaining responses on their own.</p>
</div>
<div class="notice error" id="1009">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1009</span>
<span>Malformed response heading</span>
</h3>
<p><var>error</var></p>
</div>
<div class="notice debug" id="1010">
<h3>
<abbr class="severity" title="debug">D</abbr>
<span class="ident">1010</span>
<span>Stop parsing response stream</span>
</h3>
<p>Due to previous notices, the data beginning at byte <span data-ref-to="8"><var>offset</var></span> on the response stream <span data-ref-to="9"><var>name</var></span> will not be parsed.</p>
</div>
<div class="notice debug" id="1011">
<h3>
<abbr class="severity" title="debug">D</abbr>
<span class="ident">1011</span>
<span>Switching protocols</span>
</h3>
<p>The <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-6.2.2" title="Switching Protocols (RFC 7231 § 6.2.2)">101</a></span> status code means that the connection is switching to a different protocol. HTTPolice will not parse the rest of the streams.</p>
</div>
<div class="notice debug" id="1012">
<h3>
<abbr class="severity" title="debug">D</abbr>
<span class="ident">1012</span>
<span>Switching to a tunnel</span>
</h3>
<p>A <span data-ref-to="10"><var>status</var></span> response to a <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.6" title="RFC 7231 § 4.3.6">CONNECT</a></span> request means that the connection is becoming a tunnel. HTTPolice will not parse the remainder of the streams.</p>
</div>
<div class="notice error" id="1013">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1013</span>
<span>Multiple <span data-ref-to="11"><var>header</var></span> headers are forbidden</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-3.2.2">RFC 7230 § 3.2.2</a></cite>: <q>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).</q></p>
<span data-ref-to="12"></span>
</div>
<div class="notice comment" id="1014">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1014</span>
<span>RWS in <span data-ref-to="13"><var>place</var></span> should be a single space</span>
</h3>
<p>The syntax of <span data-ref-to="14"><var>place</var></span> includes the rule named RWS. It should be produced as just a single space, but here it was <span data-ref-to="15"><var>num</var></span> characters. See <cite><a href="https://tools.ietf.org/html/rfc7230#section-3.2.3">RFC 7230 § 3.2.3</a></cite>.</p>
</div>
<div class="notice error" id="1015">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1015</span>
<span>Bad whitespace (BWS) in <span data-ref-to="16"><var>place</var></span></span>
</h3>
<p>The syntax of <span data-ref-to="17"><var>place</var></span> includes the rule named BWS, which is whitespace allowed for historical reasons; it must not be produced by current implementations. See <cite><a href="https://tools.ietf.org/html/rfc7230#section-3.2.3">RFC 7230 § 3.2.3</a></cite>.</p>
</div>
<div class="notice error" id="1016">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1016</span>
<span>Obsolete line folding in headers</span>
</h3>
<p>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 <cite><a href="https://tools.ietf.org/html/rfc7230#section-3.2.4">RFC 7230 § 3.2.4</a></cite>.</p>
</div>
<div class="notice comment" id="1017">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1017</span>
<span>Strange escaping in <span data-ref-to="18"><var>place</var></span></span>
</h3>
<p>This message uses the “quoted-pair” rule to escape the character <span data-ref-to="19"><var>char</var></span> in a context where this escaping is unnecessary and should not be used. See <cite><a href="https://tools.ietf.org/html/rfc7230#section-3.2.6">RFC 7230 § 3.2.6</a></cite>.</p>
<p>If a literal backslash \ was intended here, it must itself be escaped as \\.</p>
</div>
<div class="notice error" id="1018">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1018</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1" title="RFC 7230 § 3.3.1">Transfer-Encoding</a></span> is forbidden in a <span data-ref-to="20"><var>status</var></span> response</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1">RFC 7230 § 3.3.1</a></cite>: <q>A server MUST NOT send a Transfer-Encoding header field in any
response with a status code of 1xx (Informational) or 204 (No
Content).</q></p>
</div>
<div class="notice error" id="1019">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1019</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1" title="RFC 7230 § 3.3.1">Transfer-Encoding</a></span> is forbidden in a <span data-ref-to="21"><var>status</var></span> response to <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.6" title="RFC 7231 § 4.3.6">CONNECT</a></span></span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1">RFC 7230 § 3.3.1</a></cite>: <q>A server MUST NOT send a Transfer-Encoding header field in
any 2xx (Successful) response to a CONNECT request</q></p>
</div>
<div class="notice error" id="1020">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1020</span>
<span>Can’t have both <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1" title="RFC 7230 § 3.3.1">Transfer-Encoding</a></span> and <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2" title="RFC 7230 § 3.3.2">Content-Length</a></span></span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2">RFC 7230 § 3.3.2</a></cite>: <q>A sender MUST NOT send a Content-Length header field in any message
that contains a Transfer-Encoding header field.</q></p>
</div>
<div class="notice comment" id="1021">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1021</span>
<span><span data-ref-to="22"><var>method</var></span> request should have <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2" title="RFC 7230 § 3.3.2">Content-Length</a></span></span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2">RFC 7230 § 3.3.2</a></cite>: <q>A user agent SHOULD send a Content-Length in a request message when
no <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1" title="RFC 7230 § 3.3.1">Transfer-Encoding</a></span> 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 <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.3" title="RFC 7231 § 4.3.3">POST</a></span> request even when the value is 0
(indicating an empty payload body).</q></p>
</div>
<div class="notice comment" id="1022">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1022</span>
<span>Empty <span data-ref-to="23"><var>method</var></span> request shouldn’t have <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2" title="RFC 7230 § 3.3.2">Content-Length</a></span></span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2">RFC 7230 § 3.3.2</a></cite>: <q>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.</q></p>
</div>
<div class="notice error" id="1023">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1023</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2" title="RFC 7230 § 3.3.2">Content-Length</a></span> is forbidden in a <span data-ref-to="24"><var>status</var></span> response</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2">RFC 7230 § 3.3.2</a></cite>: <q>A server MUST NOT send a Content-Length header field in any response
with a status code of 1xx (Informational) or 204 (No Content).</q></p>
</div>
<div class="notice error" id="1024">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1024</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2" title="RFC 7230 § 3.3.2">Content-Length</a></span> is forbidden in a <span data-ref-to="25"><var>status</var></span> response to <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.6" title="RFC 7231 § 4.3.6">CONNECT</a></span></span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2">RFC 7230 § 3.3.2</a></cite>: <q>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]).</q></p>
</div>
<div class="notice comment" id="1025">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1025</span>
<span>Response delimited only by closing the connection</span>
</h3>
<p>This response has no <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2" title="RFC 7230 § 3.3.2">Content-Length</a></span> header and no “<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1" title="RFC 7230 § 3.3.1">Transfer-Encoding</a></span>: <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.1" title="RFC 7230 § 4.1">chunked</a></span>” 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).</p>
<p>See <cite><a href="https://tools.ietf.org/html/rfc7230#section-3.3.3">RFC 7230 § 3.3.3</a></cite>.</p>
</div>
<div class="notice error" id="1026">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1026</span>
<span><span data-ref-to="26"><var>entry</var></span> is forbidden in a trailer</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-4.1.2">RFC 7230 § 4.1.2</a></cite>: <q>A sender MUST NOT generate a trailer that contains a field necessary
for message framing (e.g., <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1" title="RFC 7230 § 3.3.1">Transfer-Encoding</a></span> and <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.2" title="RFC 7230 § 3.3.2">Content-Length</a></span>),
routing (e.g., <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-5.4" title="RFC 7230 § 5.4">Host</a></span>), 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.,
<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.2.2" title="RFC 7231 § 3.1.2.2">Content-Encoding</a></span>, <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.1.5" title="RFC 7231 § 3.1.1.5">Content-Type</a></span>, <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7233#section-4.2" title="RFC 7233 § 4.2">Content-Range</a></span>, and <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.4" title="RFC 7230 § 4.4">Trailer</a></span>).</q></p>
</div>
<div class="notice error" id="1027">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1027</span>
<span>Could not decode <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-3.3.1" title="RFC 7230 § 3.3.1">Transfer-Encoding</a></span>: <span data-ref-to="27"><var>coding</var></span></span>
</h3>
<p><var>error</var></p>
</div>
<div class="notice error" id="1028">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1028</span>
<span>“<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.3" title="RFC 7230 § 4.3">TE</a></span>: <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.1" title="RFC 7230 § 4.1">chunked</a></span>” is forbidden</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-4.3">RFC 7230 § 4.3</a></cite>: <q>A client MUST NOT send
the chunked transfer coding name in TE; chunked is always acceptable
for HTTP/1.1 recipients.</q></p>
</div>
<div class="notice error" id="1029">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1029</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.3" title="RFC 7230 § 4.3">TE</a></span> header requires “<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.1" title="RFC 7230 § 6.1">Connection</a></span>: TE”</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-4.3">RFC 7230 § 4.3</a></cite>: <q>Since the TE header field only applies to the immediate connection, a
sender of TE MUST also send a "TE" connection option within the
<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.1" title="RFC 7230 § 6.1">Connection</a></span> header field (Section 6.1) in order to prevent the TE
field from being forwarded by intermediaries that do not support its
semantics.</q></p>
</div>
<div class="notice comment" id="1030">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1030</span>
<span><span data-ref-to="28"><var>header</var></span> was not announced in the <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.4" title="RFC 7230 § 4.4">Trailer</a></span> header</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-4.4">RFC 7230 § 4.4</a></cite>: <q>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 <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.4" title="RFC 7230 § 4.4">Trailer</a></span> header field before the message body to indicate
which fields will be present in the trailers.</q></p>
</div>
<div class="notice error" id="1031">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1031</span>
<span>Missing <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-5.4" title="RFC 7230 § 5.4">Host</a></span> header</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-5.4">RFC 7230 § 5.4</a></cite>: <q>A client MUST send a Host header field in all HTTP/1.1 request
messages.</q></p>
</div>
<div class="notice comment" id="1032">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1032</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-5.4" title="RFC 7230 § 5.4">Host</a></span> should be the first header</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-5.4">RFC 7230 § 5.4</a></cite>: <q>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.</q></p>
</div>
<div class="notice error" id="1033">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1033</span>
<span>Request with a bad <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-5.4" title="RFC 7230 § 5.4">Host</a></span> header must be rejected</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-5.4">RFC 7230 § 5.4</a></cite>: <q>A server MUST respond with a <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-6.5.1" title="Bad Request (RFC 7231 § 6.5.1)">400</a></span> (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.</q></p>
<span data-ref-to="29"></span>
<span data-ref-to="29"></span>
<span data-ref-to="30"></span>
</div>
<div class="notice error" id="1034">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1034</span>
<span>“<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.1" title="RFC 7230 § 6.1">Connection</a></span>: <span data-ref-to="31"><var>header</var></span>” is forbidden</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-5.4">RFC 7230 § 5.4</a></cite>: <q>A sender MUST NOT send a connection option corresponding to a header
field that is intended for all recipients of the payload. For
example, <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7234#section-5.2" title="RFC 7234 § 5.2">Cache-Control</a></span> is never appropriate as a connection option
(Section 5.2 of [RFC7234]).</q></p>
</div>
<div class="notice comment" id="1035">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1035</span>
<span>Deprecated media type <span data-ref-to="32"><var>value</var></span></span>
</h3>
<p>According to <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.1.5" title="RFC 7231 § 3.1.1.5">Content-Type</a></span>, this message’s body is of type <span data-ref-to="33"><var>value</var></span>, which is listed as “deprecated” or “obsoleted” in the <cite><a href="https://www.iana.org/assignments/media-types/media-types.xml">IANA media types registry</a></cite>.</p>
</div>
<div class="notice debug" id="1036">
<h3>
<abbr class="severity" title="debug">D</abbr>
<span class="ident">1036</span>
<span>Not decoding <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.2.2" title="RFC 7231 § 3.1.2.2">Content-Encoding</a></span>: <span data-ref-to="34"><var>coding</var></span></span>
</h3>
<p>HTTPolice does not know how to decode the <span data-ref-to="35"><var>coding</var></span> content coding. (This doesn’t mean that it’s wrong.)</p>
</div>
<div class="notice error" id="1037">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1037</span>
<span>Could not decode <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.2.2" title="RFC 7231 § 3.1.2.2">Content-Encoding</a></span>: <span data-ref-to="36"><var>coding</var></span></span>
</h3>
<p><var>error</var></p>
</div>
<div class="notice error" id="1038">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1038</span>
<span>Bad JSON body</span>
</h3>
<p>According to <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.1.5" title="RFC 7231 § 3.1.1.5">Content-Type</a></span>, this message’s body is JSON, but HTTPolice tried to parse it as JSON and got the following error:</p>
<p><var>error</var></p>
<span data-ref-to="37"></span>
</div>
<div class="notice error" id="1039">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1039</span>
<span>Bad XML body</span>
</h3>
<p>According to <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.1.5" title="RFC 7231 § 3.1.1.5">Content-Type</a></span>, this message’s body is XML, but HTTPolice tried to parse it as XML and got the following error:</p>
<p><var>error</var></p>
<span data-ref-to="38"></span>
</div>
<div class="notice error" id="1040">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1040</span>
<span>Bad URL-encoded body</span>
</h3>
<p>According to <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.1.5" title="RFC 7231 § 3.1.1.5">Content-Type</a></span>, this message’s body is URL-encoded. But it doesn’t look like a proper URL-encoded string, as defined by <cite><a href="https://www.w3.org/TR/html5/forms.html#url-encoded-form-data">HTML5</a></cite>, because it contains the character: <span data-ref-to="39"><var>char</var></span>.</p>
<p>This often means that the <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.1.5" title="RFC 7231 § 3.1.1.5">Content-Type</a></span> header is wrong.</p>
<span data-ref-to="40"></span>
</div>
<div class="notice comment" id="1041">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1041</span>
<span>Body should have a <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.1.5" title="RFC 7231 § 3.1.1.5">Content-Type</a></span></span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7231#section-3.1.1.5">RFC 7231 § 3.1.1.5</a></cite>: <q>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.</q></p>
<span data-ref-to="41"></span>
</div>
<div class="notice comment" id="1042">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1042</span>
<span>Duplicate ‘<span data-ref-to="42"><var>param</var></span>’ parameter in <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.1.5" title="RFC 7231 § 3.1.1.5">Content-Type</a></span></span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc6838#section-4.3">RFC 6838 § 4.3</a></cite>: <q>It is an error for a specific
parameter to be specified more than once.</q></p>
</div>
<div class="notice error" id="1045">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1045</span>
<span>Syntax error in request target</span>
</h3>
<p><var>error</var></p>
<p>See also <cite><a href="https://tools.ietf.org/html/rfc7230#section-5.3">RFC 7230 § 5.3</a></cite>.</p>
<span data-ref-to="43"></span>
</div>
<div class="notice error" id="1046">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1046</span>
<span>Proxied response needs a <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-5.7.1" title="RFC 7230 § 5.7.1">Via</a></span> header</span>
</h3>
<p>According to <cite><a href="https://tools.ietf.org/html/rfc7230#section-5.7.1">RFC 7230 § 5.7.1</a></cite>, a proxy must add a <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-5.7.1" title="RFC 7230 § 5.7.1">Via</a></span> header to each response that it forwards.</p>
</div>
<div class="notice comment" id="1047">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1047</span>
<span>Close-delimited response should have “<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.1" title="RFC 7230 § 6.1">Connection</a></span>: close”</span>
</h3>
<p>When a response is delimited only by closing the connection, it should have a <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.1" title="RFC 7230 § 6.1">Connection</a></span> header with a ‘close’ option. See <cite><a href="https://tools.ietf.org/html/rfc7230#section-6.3">RFC 7230 § 6.3</a></cite> and <cite><a href="https://tools.ietf.org/html/rfc7230#section-6.6">RFC 7230 § 6.6</a></cite>.</p>
</div>
<div class="notice error" id="1048">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1048</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-6.2.2" title="Switching Protocols (RFC 7231 § 6.2.2)">101</a></span> response needs an <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.7" title="RFC 7230 § 6.7">Upgrade</a></span> header</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-6.7">RFC 7230 § 6.7</a></cite>: <q>A server that sends a 101 (Switching Protocols) response MUST send an
<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.7" title="RFC 7230 § 6.7">Upgrade</a></span> header field to indicate the new protocol(s) to which the
connection is being switched</q></p>
</div>
<div class="notice error" id="1049">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1049</span>
<span>Switching to a protocol that was not requested</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-6.7">RFC 7230 § 6.7</a></cite>: <q>A server MUST NOT switch to a protocol that was not indicated
by the client in the corresponding request's <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.7" title="RFC 7230 § 6.7">Upgrade</a></span> header field.</q></p>
<span data-ref-to="44"></span>
<span data-ref-to="44"></span>
<span data-ref-to="45"></span>
</div>
<div class="notice error" id="1050">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1050</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.7" title="RFC 7230 § 6.7">Upgrade</a></span> header requires “<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.1" title="RFC 7230 § 6.1">Connection</a></span>: upgrade”</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-6.7">RFC 7230 § 6.7</a></cite>: <q>When <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.7" title="RFC 7230 § 6.7">Upgrade</a></span> is sent, the sender MUST also send a <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.1" title="RFC 7230 § 6.1">Connection</a></span> 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.</q></p>
</div>
<div class="notice error" id="1051">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1051</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-6.2.2" title="Switching Protocols (RFC 7231 § 6.2.2)">101</a></span> response to an HTTP/1.0 request is forbidden</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7230#section-6.7">RFC 7230 § 6.7</a></cite>: <q>A
server MUST ignore an <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-6.7" title="RFC 7230 § 6.7">Upgrade</a></span> header field that is received in an
HTTP/1.0 request.</q></p>
<span data-ref-to="46"></span>
</div>
<div class="notice error" id="1052">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1052</span>
<span><span data-ref-to="47"><var>header</var></span> makes no sense in a <span data-ref-to="48"><var>status</var></span> response</span>
</h3>
<p>The <span data-ref-to="49"><var>header</var></span> header provides representation metadata, but there can be no representation associated with a <span data-ref-to="50"><var>status</var></span> response. The header should probably be removed.</p>
</div>
<div class="notice comment" id="1053">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1053</span>
<span><span data-ref-to="51"><var>header</var></span> makes no sense in an empty request</span>
</h3>
<p>The <span data-ref-to="52"><var>header</var></span> header provides representation metadata. It would make sense in a request with a body, but this one has no body.</p>
<p>See also <cite><a href="https://tools.ietf.org/html/rfc7231#section-3.1">RFC 7231 § 3.1</a></cite>.</p>
</div>
<div class="notice error" id="1054">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1054</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.4" title="RFC 7230 § 4.4">Trailer</a></span> header makes no sense without a chunked body</span>
</h3>
<p>The <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.4" title="RFC 7230 § 4.4">Trailer</a></span> header announces what other headers will be sent in the trailer part of a <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7230#section-4.1" title="RFC 7230 § 4.1">chunked</a></span> message. It doesn’t make sense here because this message does not use the chunked transfer coding.</p>
<p>See also <cite><a href="https://tools.ietf.org/html/rfc7230#section-4.1.2">RFC 7230 § 4.1.2</a></cite>.</p>
<span data-ref-to="53"></span>
</div>
<div class="notice comment" id="1055">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1055</span>
<span>Unnecessary <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.4.2" title="RFC 7231 § 3.1.4.2">Content-Location</a></span></span>
</h3>
<p>This is a <span data-ref-to="54"><var>status</var></span> response to a <span data-ref-to="55"><var>method</var></span> request. By definition, its body is a representation of the requested resource. But it also has a <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.4.2" title="RFC 7231 § 3.1.4.2">Content-Location</a></span> header that points to the same URI as the request URI. In this case, the header provides no additional information.</p>
<p>See also <cite><a href="https://tools.ietf.org/html/rfc7231#section-3.1.4.1">RFC 7231 § 3.1.4.1</a></cite>.</p>
</div>
<div class="notice comment" id="1056">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1056</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.1" title="RFC 7231 § 4.3.1">GET</a></span> request with a body may cause problems</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7231#section-4.3.1">RFC 7231 § 4.3.1</a></cite>: <q>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.</q></p>
<span data-ref-to="56"></span>
</div>
<div class="notice comment" id="1057">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1057</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.2" title="RFC 7231 § 4.3.2">HEAD</a></span> request with a body may cause problems</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7231#section-4.3.2">RFC 7231 § 4.3.2</a></cite>: <q>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.</q></p>
</div>
<div class="notice error" id="1058">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1058</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.4" title="RFC 7231 § 4.3.4">PUT</a></span> request with <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7233#section-4.2" title="RFC 7233 § 4.2">Content-Range</a></span> must be rejected</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7231#section-4.3.4">RFC 7231 § 4.3.4</a></cite>: <q>An origin server that allows PUT on a given target resource MUST send
a <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-6.5.1" title="Bad Request (RFC 7231 § 6.5.1)">400</a></span> (Bad Request) response to a PUT request that contains a
<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7233#section-4.2" title="RFC 7233 § 4.2">Content-Range</a></span> 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.</q></p>
<span data-ref-to="57"></span>
<span data-ref-to="58"></span>
</div>
<div class="notice comment" id="1059">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1059</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.5" title="RFC 7231 § 4.3.5">DELETE</a></span> request with a body may cause problems</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7231#section-4.3.5">RFC 7231 § 4.3.5</a></cite>: <q>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.</q></p>
<span data-ref-to="59"></span>
</div>
<div class="notice error" id="1060">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1060</span>
<span>Strange <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.4.2" title="RFC 7231 § 3.1.4.2">Content-Location</a></span> in response to <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.5" title="RFC 7231 § 4.3.5">DELETE</a></span></span>
</h3>
<p>This is an ostensibly successful (<span data-ref-to="60"><var>status</var></span>) response to a <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.5" title="RFC 7231 § 4.3.5">DELETE</a></span> request. However, according to its <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.4.2" title="RFC 7231 § 3.1.4.2">Content-Location</a></span> 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.</p>
</div>
<div class="notice comment" id="1061">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1061</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.6" title="RFC 7231 § 4.3.6">CONNECT</a></span> request with a body may cause problems</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7231#section-4.3.6">RFC 7231 § 4.3.6</a></cite>: <q>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.</q></p>
<span data-ref-to="61"></span>
</div>
<div class="notice error" id="1062">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1062</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.7" title="RFC 7231 § 4.3.7">OPTIONS</a></span> request with a body needs <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.1.5" title="RFC 7231 § 3.1.1.5">Content-Type</a></span></span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7231#section-4.3.7">RFC 7231 § 4.3.7</a></cite>: <q>A client that generates an OPTIONS request containing a payload body
MUST send a valid <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-3.1.1.5" title="RFC 7231 § 3.1.1.5">Content-Type</a></span> header field describing the
representation media type.</q></p>
</div>
<div class="notice error" id="1063">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1063</span>
<span><span data-ref-to="62"><var>header</var></span> header is for responses</span>
</h3>
<p>This request has the <span data-ref-to="63"><var>header</var></span> header, which is only defined for responses.</p>
</div>
<div class="notice error" id="1064">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1064</span>
<span><span data-ref-to="64"><var>header</var></span> header is for requests</span>
</h3>
<p>This response has the <span data-ref-to="65"><var>header</var></span> header, which is only defined for requests.</p>
</div>
<div class="notice error" id="1066">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1066</span>
<span>“<span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-5.1.1" title="RFC 7231 § 5.1.1">Expect</a></span>: 100-continue” is forbidden on empty requests</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7231#section-5.1.1">RFC 7231 § 5.1.1</a></cite>: <q>A client MUST NOT generate a 100-continue expectation in a request
that does not include a message body.</q></p>
</div>
<div class="notice comment" id="1067">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1067</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-5.1.2" title="RFC 7231 § 5.1.2">Max-Forwards</a></span> header is undefined for <span data-ref-to="66"><var>method</var></span> requests</span>
</h3>
<p>The <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-5.1.2" title="RFC 7231 § 5.1.2">Max-Forwards</a></span> header is only defined for <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.7" title="RFC 7231 § 4.3.7">OPTIONS</a></span> and <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.8" title="RFC 7231 § 4.3.8">TRACE</a></span> requests. <cite><a href="https://tools.ietf.org/html/rfc7231#section-5.1.2">RFC 7231 § 5.1.2</a></cite>: <q>A recipient MAY ignore a Max-Forwards header field received with any other request methods.</q></p>
</div>
<div class="notice error" id="1068">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1068</span>
<span>Unsecured request must not have a <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-5.5.2" title="RFC 7231 § 5.5.2">Referer</a></span> with ‘https:’</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7231#section-5.5.2">RFC 7231 § 5.5.2</a></cite>: <q>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.</q></p>
</div>
<div class="notice comment" id="1070">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1070</span>
<span>Missing <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-5.5.3" title="RFC 7231 § 5.5.3">User-Agent</a></span> header</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7231#section-5.5.3">RFC 7231 § 5.5.3</a></cite>: <q>A user agent SHOULD send a User-Agent field in each request
unless specifically configured not to do so.</q></p>
</div>
<div class="notice error" id="1071">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1071</span>
<span><span data-ref-to="67"><var>status</var></span> response to an HTTP/1.0 request is forbidden</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7231#section-6.2">RFC 7231 § 6.2</a></cite>: <q>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.</q></p>
<span data-ref-to="68"></span>
</div>
<div class="notice error" id="1072">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1072</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-6.3.2" title="Created (RFC 7231 § 6.3.2)">201</a></span> response to <span data-ref-to="69"><var>method</var></span> makes no sense</span>
</h3>
<p>The <span data-ref-to="70"><var>method</var></span> method is defined as safe (read-only). But the <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-6.3.2" title="Created (RFC 7231 § 6.3.2)">201</a></span> status code means that a new resource was created.</p>
</div>
<div class="notice comment" id="1073">
<h3>
<abbr class="severity" title="comment">C</abbr>
<span class="ident">1073</span>
<span>Possibly missing <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-7.1.2" title="RFC 7231 § 7.1.2">Location</a></span> header</span>
</h3>
<p>This <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-6.3.2" title="Created (RFC 7231 § 6.3.2)">201</a></span> response indicates that a new resource was created. Because there is no <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-7.1.2" title="RFC 7231 § 7.1.2">Location</a></span> header in the response, it is assumed that the created resource is the same as the request target (<cite><a href="https://tools.ietf.org/html/rfc7231#section-6.3.2">RFC 7231 § 6.3.2</a></cite>). But <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-4.3.3" title="RFC 7231 § 4.3.3">POST</a></span> requests are usually intended to create a sub-resource of the target. It’s likely that this response needs an explicit <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-7.1.2" title="RFC 7231 § 7.1.2">Location</a></span>.</p>
</div>
<div class="notice error" id="1074">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1074</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-6.3.3" title="Accepted (RFC 7231 § 6.3.3)">202</a></span> response to <span data-ref-to="71"><var>method</var></span> makes no sense</span>
</h3>
<p>The <span data-ref-to="72"><var>method</var></span> method is defined as safe (read-only). But the <span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-6.3.3" title="Accepted (RFC 7231 § 6.3.3)">202</a></span> status code means that the server started some kind of processing operation.</p>
</div>
<div class="notice error" id="1076">
<h3>
<abbr class="severity" title="error">E</abbr>
<span class="ident">1076</span>
<span><span data-ref-to=""><a href="https://tools.ietf.org/html/rfc7231#section-6.3.6" title="Reset Content (RFC 7231 § 6.3.6)">205</a></span> response must not have a body</span>
</h3>
<p><cite><a href="https://tools.ietf.org/html/rfc7231#section-6.3.6">RFC 7231 § 6.3.6</a></cite>: <q>Since the 205 status code implies that no additional content will be
provided, a server MUST NOT generate a payload in a 205 response.</q></p>
<span data-ref-to="73"></span>