-
Notifications
You must be signed in to change notification settings - Fork 4
/
25.txt
1266 lines (993 loc) · 63.5 KB
/
25.txt
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
[27] [DFN[[RUBYB[[[メッセージ]]]@en[message]]]]は、 [[HTTP]] における情報伝達の単位
([[アプリケーション層]]の[[パケット]]) です。
[28] [[メッセージ]]には、[[要求メッセージ]]と[[応答メッセージ]]があります。
* 仕様書
[REFS[
- [30] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-3>
-- [49] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-3.4>
-- [514] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-3.5>
- [13] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-2.5>
- [517] [CITE@en[RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing]] ([TIME[2014-06-07 01:59:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7230#section-8.3.1>
- [2052] [CITE@en[RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content]] ([TIME[2014-06-07 01:55:45 +09:00]] 版) <https://tools.ietf.org/html/rfc7231#section-4.3.8>
- [58] [CITE@en[RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0]] ([TIME[2014-09-07 13:12:32 +09:00]] 版) <http://tools.ietf.org/html/rfc1945#section-6.1>
- [61] [CITE[UPnP Device Architecture 2.0]] ([TIME[2014-09-05 02:24:48 +09:00]] 版) <http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v2.0.pdf#page=23>
- [66] [CITE@en[RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)]] ([TIME[2015-05-15 10:14:54 +09:00]] 版) <https://tools.ietf.org/html/rfc7540#section-8.1>
]REFS]
* テキスト形式メッセージ (HTTP/0.9, HTTP/1.0, HTTP/1.1)
[65] [[HTTP/1.0]] と [[HTTP/1.1]] は、 [[RFC 822]] に由来するテキスト形式の[[メッセージ]]構文を採用していました。
[[HTTP/0.9]] はそれよりも更に単純な形式でした。
** 構文
[29] [[メッセージ]]は、[[開始行]]、[[ヘッダー]]、[[メッセージ本体]]の3つの部分で構成されます
[SRC[>>30]]。
[46] [[HTTP/0.9]] [[応答]]以外のすべての[[HTTPメッセージ]]には、
[[開始行]]が存在します。
[31] [[ヘッダー]]は、任意の個数使用することができ、必ず直後に [[CRLF]]
が来ます。 [SRC[>>30]] ただし [[HTTP/0.9]] では[[ヘッダー]]を使うことができません。
[32] [[開始行]]および[[ヘッダー]]と[[メッセージ本体]]の間には、必ず1つ [[CRLF]]
が来ます。 [SRC[>>30]] 最後の[[ヘッダー]]の後の [[CRLF]] ([[ヘッダー]]が無い場合は[[開始行]]の最後の
[[CRLF]]) とあわせて、 [[CRLF]] [[CRLF]] と2回連続することになります。
なお [[HTTP/0.9]] ではこの [[CRLF]] は存在しません。
[34] [[メッセージ本体]]は省略することもできます [SRC[>>30]]。
[[HTTP/0.9]] [[要求]]では[[メッセージ本体]]を使えません。
;; [35] [[ヘッダー]]や[[メッセージ本体]]は省略できますが、
いつでも省略できるわけではなく、他の色々な条件で制約されています。
[36] [[HTTP/1.x]] では、[[メッセージ本体]]がなくても、区切りの [[CRLF]] は必要です。
;; [47] [[HTTP/0.9]] [[応答]]は、[[開始行]]と[[ヘッダー]]がなく、全体が[[メッセージ本体]]となります。
[FIG(railroad)[
= |
== =
=== [[開始行]]
=== *
==== [[ヘッダー]]
==== [[CRLF]]
=== [[CRLF]]
=== ?
==== [[メッセージ本体]]
== HTTP/0.9 要求
=== [[開始行]]
== HTTP/0.9 応答
=== [[メッセージ本体]]
]FIG]
;; [57] [[プロトコルの版]]も参照。
[62] [[SSDP]] は [[HTTP/1.1]] と同じ[[メッセージ]]の構文を採用しています [SRC[>>61]]。
** 構文解析
[42] [[HTTPメッセージ]]は[[ストリーム]]として[[構文解析]]して[[漸進的処理]]に供したり、
[[下流]]へ[[転送]]したりできます。しかし、[[実装]]によっては[[転送]]する[[メッセージ]]を[[バッファリング]]したり遅延させたりして調整したり何らかの処理を行ったりすることがありますから、
[[受信者]]は、[[メッセージ]]を[[漸進的]]に受信できることに依存できません。 [SRC[>>30]]
;; [43] と [[HTTP]] 仕様書は言っていますが、実際には[[鯖]]と[[クライアント]]の間の[[接続]]を維持し、
[[メッセージ本体]]中のデータを随時断続的に送信していくような使われ方がしばしばなされています。
[[メッセージ]]をすべて読み終わるまで[[転送]]できないような[[中間器]]は、
[[Web互換]]ではありません。
[41] [[受信者]]は、[[HTTPメッセージ]]を [[US-ASCII]] の[[超集合]]の[[オクテット列]]として[[構文解析]]しなければ[['''なりません''']]。
[SRC[>>30]]
[37] 通常は [[HTTPメッセージ]]を次のように[[構文解析]]します [SRC[>>30]]。
[FIG(steps)[
= [38] [[開始行]]を読んで構造を解釈します。
= [39] [[空行]]に達するまで各[[ヘッダー]]を読んで、
[[ヘッダー名]]の[[ハッシュ表]]に入れます。
= [40] [[メッセージ本体]]があれば、[[メッセージ本体長]]分に達するか[[接続]]が閉じられるまでの[[オクテット]]を[[ストリーム]]として読みます。
]FIG]
[513] [[鯖]]は、少なくても1つは[[要求行]]の前の [[CRLF]] を無視する[['''べきです''']]
[SRC[>>514]]。
;; [[HTTP接続]]も参照。
[44] [[送信者]]は[[開始行]]と最初の[[ヘッダー]]の間に[[空白]]を[[送信]]しては[['''なりません''']]
[SRC[>>30]]。[[受信者]]は、[[開始行]]と[[ヘッダー]]の間に[[空白]]があれば、
[[メッセージ]]を[[非妥当]]であるとして拒絶するか、
[[空白]]で始まる[[行]]を消費して無視するかのいずれかとしなければ[['''なりません''']] [SRC[>>30]]。
;; [45] [[生成]]ではなく[[送信]]が禁止されているので、[[転送]]するだけの場合であっても、
[[空白]]をそのままにすることは禁止されています。
[48] [[メッセージ本体]]の項も参照してください。
[516] [[HTTP]] [[要求メッセージ]]のみを受け付ける[[鯖]]は、
[[HTTPメッセージ]]の文法に沿わない[[オクテット列]]を受け取った場合、
(他に規定がなければ) [CODE(HTTP)[[[400]]]] [[応答]]を送る[['''べきです''']] [SRC[>>514]]。
[55] [[Apache]] は[[ヘッダー部]]に[[ヘッダー]]でないもの ([CODE(HTTP)[[[:]]]]
が含まれない[[行]]) が混じっていると [CODE(HTTP)[[[400]]]]
を返します。 [[nginx]] は無視するようです。 [TIME[2014-10-24T06:04:05.600Z]]
;; [56] [CODE(HTTP)[[[400]]]] を返す方が良さそうに思えます。
[53] [[メッセージ]]は、[RUBYB[[[不完全]]]@en[incomplete]]なことがあります。
詳しくは[[不完全メッセージ]]を参照してください。
[59] [[HTTP/1.0]] [[要求]]に対して [[HTTP/0.9]] [[応答]]が返された場合、
[[payload body]] の先頭が[[状態行]]のような文字列の時、
[[HTTP/1.0]] [[応答]]と誤認されることとなります。しかし [[HTTP/0.9]]
[[鯖]]のほとんどは [CODE(MIME)@en[[[text/html]]]] なので、
そのようなことはあまりないとされています [SRC[>>58]]。
;; [[HTTP/0.9]] も参照。
[93] [[ヘッダー部]]が不完全な場合 ([[状態行]]の途中で終わっていた場合、
[[ヘッダー]]の後に[[改行]]がない場合、
[[ヘッダー]]の後の[[空行]]がない場合) には、[[接続]]が閉じられたところまでについて通常通り処理が行われるようです。
ただし、 [[Firefox]] は[[状態行]]の[[改行]]がなく終わっている時は、[[ネットワークエラー]]とみなします
([[IE]] と [[Chrome]] はエラーにしません)。
[[ヘッダー]]が[[改行]]で終わっていないと、 [[Firefox]] は[[ネットワークエラー]]とみなし、
[[IE]] はその前の行までだけ処理します ([[Chrome]] はその[[ヘッダー]]まで含めて処理します)。
[TIME[2015-08-12T14:32:47.700Z]]
[95] [[HTTPS]] の場合、 [[Chrome]] は[[ヘッダー部]]の途中で接続が閉じられると[[ネットワークエラー]]にします。
[[Firefox]] と [[IE]] は [[HTTP]] と同じくエラーにはしません。 [TIME[2015-09-12T14:26:03.400Z]]
[105] [[Chrome]] も [[Firefox]] も、[[ヘッダー部]]の途中での [CODE[RST]]
は[[ネットワークエラー]]とします。 [TIME[2016-07-17T12:51:02.200Z]]
[106] [[Apache]] は[[要求本体]]が [CODE(HTTP)@en[Content-Length:]] に満たずに[[要求]]が閉じられると、
[CODE[400]] [[応答]]を返します。 [[nginx]] は通常通り処理を続けます。
[TIME[2016-09-09T09:14:41.400Z]]
[107] [[nginx]] は継続行の処理がおかしく、ネットワークからのデータの到着のタイミングによっても結果が変わったりするようです。
[TIME[2016-09-10T13:07:19.500Z]]
[108] (標準設定では) [[Apache]] も [[nginx]] も、[[ヘッダー部]]の各行は[[改行]]を含めて
[N[8192]] [[バイト]]以下でなければ [CODE[400]] [[応答]]を返します。
[[Apache]] は継続行を連結して、[[ヘッダー名]]、[CODE[:]]、[[ヘッダー値]]、[[改行]]で
[N[8192]] [[バイト]]以下でなければ [CODE[400]] [[応答]]を返します。
[[nginx]] は継続行を含めた検査を行わないように見えます。
[TIME[2016-09-11T06:41:34.000Z]]
[109] [[Apache]] は[[要求ヘッダー]]を [N[100]] 個まで受け付け、それを超えると
[CODE[400]] [[応答]]を返します。 [[nginx]] は [N[8438]] 個まで受け付け、それを超えると
[CODE[400]] [[応答]]を返します。 [TIME[2016-09-11T06:59:19.700Z]]
** 改行
[33] [[HTTPメッセージ]]のうち、[[メッセージ本体]]よりも前の部分で区切りに使われる[[改行]]は、
[[CRLF]] です。 [[CR]] 単体や [[LF]] 単体ではありません。
[515] [[開始行]]や[[ヘッダー]]の後の[[改行]]である [[CRLF]] について、
[[LF]] を[[改行]]とみなし、直前に [[CR]] があれば無視することとしても構いません [SRC[>>514]]。
[92] [[nginx]] も [[Apache]] も、[[LF]] を[[改行]]とみなし、直前の [[CR]]
を無視するようです。 [TIME[2015-06-14T10:26:26.300Z]]
- [1] [[HTTP]] メッセージの頭の改行は [[CRLF]] で'''なければなりません'''が、 [CODE[Server: Fujitsu-InfoProvider-Pro/V12L10 (UXP/DS)]] というサーバーは [CODE[LF]] で出力します。 Mozilla や WinIE を含めた多くの [[UA]] はこれでも扱えるようですが、問題が出ることもあるみたいです。
- [2] >>1 例えば: ''Libraries of Kanazawa City'' <http://www.lib.kanazawa.ishikawa.jp/>
- [3] >>1-2 互換モードを作って対応するとしたら、 [[HTTP]] [[RFC]]s によると応答の最初の行には単独の [[CR]], [[LF]] が含まれることはありませんから、もし出現したら buggy UA という方向で...
[4] [[W3C]] の古い記述 (''Note: Client tolerance of bad HTTP servers''
<http://www.w3.org/Protocols/HTTP/OldServers.html>)
は、クライアントは改行を [[LF]] と考えて、その前の [[CR]]
を無視しなさい、と言っています。
まあ [HTTP92] でも改行は [[CRLF]] と規定しているのですが...
[5]
>>4 もっと昔の TimBL が (たぶん) 最初に書いた仕様書には LF で、 CR を無視と書いてありましたです。
[6]
もっとも、 >>5 は今で言う [[HTTP/0.9]] の話なので、影響するのは要求の最初の行の末だけです。
[94] herokuapp.com のサーバー ([[Cowboy]]?) は [[LF]] のみの要求を正しく扱えず、
[CODE(HTTP)[[[505]]]] [[応答]]を返します。 [TIME[2015-09-06T15:41:22.900Z]]
* バイナリー形式メッセージ (HTTP/2)
[67] [[メッセージ]]は、同一[[ストリーム]]中の[[フレーム]]の列として表されます。
[68] [[HTTPメッセージ]]は、次のもので構成されます [SRC[>>66]]。
[FIG(list)[
= [69] [[応答]]の場合、0個[[以上]]の [CODE(HTTP)[[[1xx]]]] [[応答]]:
== [70] [CODE[[[HEADERS]]]] [[フレーム]]
== [71] 0個[[以上]]の [CODE[[[CONTINUATION]]]] [[フレーム]]
= [72] [[メッセージ]]の[[ヘッダー]]
== [73] [CODE[[[HEADERS]]]] [[フレーム]]
== [74] 0個[[以上]]の [CODE[[[CONTINUATION]]]] [[フレーム]]
= [75] [[payload body]]
== [76] 0個[[以上]]の [CODE[[[DATA]]]] [[フレーム]]
= [77] [[trailer]] (省略可能)
== [78] [CODE[[[HEADERS]]]] [[フレーム]]
== [79] 0個[[以上]]の [CODE[[[CONTINUATION]]]] [[フレーム]]
]FIG]
;; [80] [[HTTP/1.1]] [[以下]]とは違って、 [CODE(HTTP)[[[1xx]]]]
[[応答]]が[[メッセージ]]内に入れ子に含まれる定義になっています。
;; [89] [[サーバープッシュ]]の[[約束要求]]では、 [CODE(HTTP)@en[[[HEADERS]]]]
[[フレーム]]のかわりに [CODE(HTTP)@en[[[PUSH_PROMISE]]]] [[フレーム]]を使います。
[CODE(HTTP)@en[[[PUSH_PROMISE]]]] [[フレーム]]とそれに続く [CODE(HTTP)@en[[[CONTINUATION]]]]
[[フレーム]]は、[[親ストリーム]]で送信されます。
[83] [CODE[[[HEADERS]]]] [[フレーム]]と [CODE[[[CONTINUATION]]]]
[[フレーム]]の間や [CODE[[[CONTINUATION]]]] [[フレーム]]間に、
他の[[フレーム]]があっては[['''なりません''']] [SRC[>>66]]。
[81] 最後の [CODE[[[HEADERS]]]] か [CODE[[[DATA]]]] の[[フレーム]]は、
[CODE[[[END_STREAM]]]] フラグが設定されます [SRC[>>66]]。
;; [82] [CODE[[[CONTINUATION]]]] [[フレーム]]は [CODE[[[END_STREAM]]]]
[[フレーム]]が存在せず、その直前の [CODE[[[HEADERS]]]]
[[フレーム]]にかわりに設定されます。
[88] [CODE(HTTP)@en[[[DATA]]]] [[フレーム]]が存在しない場合、
[[ヘッダーリスト]]が2つ連続することになります。
[99] [CODE(HTTP)[[[1xx]]]] [[ヘッダー]]の後 [CODE[[[DATA]]]]
を受信したらどうするべきかは定かではありません。
[100] [[Chrome]] は [CODE[[[200]]]] として扱うようです。 (逆に仕様通り
[CODE[[[1xx]]]] [[ヘッダー]]の後に次の [CODE[[[HEADERS]]]]
が現れると[[ストリームエラー]] [CODE[[[PROTOCOL_ERROR]]]] とします。)
[[Firefox]] は [CODE[[[DATA]]]] [[フレーム]]を受信したら接続を閉じます。
[TIME[2015-10-11T10:01:10.700Z]]
[90] [[payload body]] を持たない種別の[[メッセージ]]で [CODE(HTTP)@en[[[DATA]]]]
[[フレーム]]が存在する場合や、 [[payload body]] を持つ種別の[[メッセージ]]で
[CODE(HTTP)@en[[[DATA]]]] [[フレーム]]が存在しない場合にどうなるのかは謎です。
;; [CODE(HTTP)@en[[[Content-Length]]]] の項も参照。
[101] [[Chrome]] も [[Firefox]] も、長さ0の [CODE[[[DATA]]]] はエラーとはしません。
[[Chrome]] は長さが非0でもエラーにせず、 [[XHR]] からアクセスできます。
[[Firefox]] は長さが非0だと[[ストリームエラー]] [CODE[[[CANCEL]]]]
とします。[TIME[2015-10-11T10:08:32.400Z]]
[103] [[Chrome]] は [[trailer]] に対応していないようで、
[[ストリームエラー]] [CODE[[[PROTOCOL_ERROR]]]] とします。
[TIME[2015-10-11T10:15:49.200Z]]
[84] [[trailer]] の [[header block]] に [CODE[[[END_STREAM]]]]
が設定されて[[ストリーム]]が閉じられなかったとしても、
その後の [[header block]] は本[[メッセージ]]の一部ではありません [SRC[>>66]]。
[85] 最終的な[[状態符号]]を受信した後に [CODE[[[END_STREAM]]]]
が設定されていない [CODE[[[HEADERS]]]] [[フレーム]]を受信したら、
そのメッセージは[[奇形]]として扱わなければ[['''なりません''']] [SRC[>>66]]。
[102] [[Firefox]] はその場合[[接続エラー]] [CODE[[[PROTOCOL_ERROR]]]]
とするようです。 [TIME[2015-10-11T10:14:49.200Z]]
[104] [[Chrome]] も [[Firefox]] も、 [CODE[[[END_STREAM]]]] より前に
[CODE[[[GOAWAY]]]] を受信しても、エラーとはしないで接続を閉じる
([[Firefox]] は [CODE[[[NO_ERROR]]]] の [CODE[[[GOAWAY]]]] を送信して閉じる)
ようです。[[要求]]に対する[[応答]]は[[ネットワークエラー]]とします。 [TIME[2015-10-12T03:57:40.200Z]]
[98] [[クライアント]]が[[要求]]を送信していない[[ストリーム]]で[[サーバー]]から
[CODE[[[HEADERS]]]] を受信した時どうしたらいいのかは定かではありません。
[96] [[要求]]を送信していない[[ストリーム]]で [CODE[[[HEADERS]]]]
を受信した時、 [[Chrome]] も [[Firefox]] も[[接続エラー]] [CODE[[[PROTOCOL_ERROR]]]]
とし、送信中の[[要求]]については[[ネットワークエラー]]とするようです。
[TIME[2015-10-03T12:00:02.900Z]]
[86] [[ストリーム]]の状態遷移の項も参照。
[87] [[奇形]]の項も参照。
* 文脈
[2053] [[メッセージ]]には[[要求メッセージ]]と[[応答メッセージ]]があり、
それぞれ定義されている文脈で用いられます。 (それぞれの項と[[HTTP接続]]の項を参照してください。)
[2054] [[メッセージ]]の一部又は全部のデータが送信されるタイミングについては、
[[HTTP接続]]の項を参照してください。
* 適合性
[16] [[送信者]]は、 [[ABNF]] [[生成規則]]により定義される[[文法]]に[[一致]]しない[[プロトコル要素]]を[[生成]]しては[['''なりません''']]
[SRC[>>13]]。
;; [50] [[ABNF]] [[生成規則]]の中には [CODE(ABNF)@en[[[obs-]]]] から始まるものがありますが、
[[RFC 5322]] とは違って [CODE(ABNF)@en[[[obs-]]]] から始まるとしてもただちに[[不適合]]になるわけではないようです。
個別に不適合と規定されているものもあれば、何も言及がないものもあります。
[17] [[送信者]]は、[[送信者]]の役割に応じて、その[[役割]]の[[送信者]]が用いることを認められていない[[プロトコル要素]]や構文上の選択肢を用いては[['''なりません''']]
[SRC[>>13]]。
[15] [[送信者]]は、[[偽]]であるとわかっていることを表している[[プロトコル要素]]を[[生成]]しては[['''なりません''']]
[SRC[>>13]]。
[18] [[受信者]]は、その役割に適用され、 [[ABNF]] [[生成規則]]により定義される[[文法]]に[[一致]]するような値を[[構文解析]]することができなければ[['''なりません''']]
[SRC[>>13]]。
[EG[
[19] すべての[[受信者]]がすべての[[プロトコル要素]]の[[構文解析]]を義務付けられているわけではありません。
[[串]]など[[メッセージ]]を[[転送]]する[[中間器]]は、[[ヘッダー]]一般の[[構文解析]]を行って名前と値の組として認識はするでしょうが、
個々の値まで更に[[構文解析]]はしないで[[転送]]してしまいます。
]EG]
[23] [[受信者]]は、受信した[[プロトコル要素]]を適当な[[仕様書]]に従い解釈しなければ[['''なりません''']]。
[SRC[>>13]]
[24] ただし[[受信者]]が (経験や設定により) [[送信者]]が誤って実装していると判定できるときは、
この限りではありません。 [SRC[>>13]]
[EG[
[25] 例えば、ある実装が特定の[[内容符号化]]の実装を誤っているとわかっており、
[CODE(HTTP)@en[[[User-Agent:]]]] から[[受信者]]がその実装であると推測できるときは、
[CODE(HTTP)@en[[[Accept-Encoding:]]]] を無視することができます。 [SRC[>>13]]
]EG]
[26] [[HTTPのエラー処理]]も参照してください。
* 長さの制限
[20] ほとんどの[[プロトコル要素]]には特定の長さの制限は設けられていません。
これは、利用される文脈や実装の目的により適切な長さが様々であるためとされています。 [SRC[>>13]]
[21] [[受信者]]は少なくても自身が同じ[[プロトコル要素]]で生成し得る値と同じ長さは[[構文解析]]して処理できなければ[['''なりません''']] [SRC[>>13]]。
[EG[
[22] 例えばとても長い [[URL]] を出版する[[起源鯖]]は、それを[[要求URL]]
として受け取って処理できる必要があります [SRC[>>13]]。
]EG]
* MIME 型
[519] テキスト形式の[[HTTPメッセージ]]に完全に対応する[[MIME型]]はありませんが、
近い型は2つあります。
[520] [CODE(MIME)@en[[[application/http]]]] は、[[要求メッセージ]]の列、
または[[応答メッセージ]]の列を表します。
;; 詳しくは [CODE(MIME)@en[[[application/http]]]] を参照してください。
[521] [DFN[[CODE(MIME)@en[[[message/http]]]]]] は、
[[HTTPメッセージ]]1つを表す[[MIME型]]ですが、 [[MIME]]
の [CODE(MIME)@en[[[message/*]]]] の制限が課される他、
いくつかの要件が本来の[[HTTPメッセージ]]と異なっています。
[91] [[HTTP/2]] を扱えるのかは不明です。
** 文脈
[528] [CODE(MIME)@en[[[message/http]]]] は [CODE(HTTP)@en[[[TRACE]]]]
[[要求]]への[[応答]]として使われます [SRC[>>2052]]。
;; [54] [[S-HTTP]] でも [CODE(MIME)@en[[[message/http]]]] を使うと規定されていました [SRC[>>60]] が、
[[S-HTTP]] 自体が普及しませんでした。
[REFS[
- [60] [CITE@en[RFC 2660 - The Secure HyperText Transfer Protocol]] ([TIME[2014-11-09 14:12:37 +09:00]] 版) <http://tools.ietf.org/html/rfc2660#section-2.4.2>
]REFS]
** 引数
[529] [CODE(MIME)@en[[[message/http]]]] には省略可能な[[引数]]が2つ定義されています [SRC[>>517]]。
[FIG(list)[
- [CODE(MIME)@en[[[version]]]]
- [CODE(MIME)@en[[[msgtype]]]]
]FIG]
** CTE
[526] [CODE(MIME)@en[[[message/http]]]] の [[CTE]] としては、 [CODE(MIME)@en[[[7bit]]]], [CODE(MIME)@en[[[8bit]]]],
[CODE(MIME)@en[[[binary]]]] だけが認められます [SRC[>>517]]。
;; [527] [[RFC 5335]] によりこの制限は [CODE(MIME)@en[[[message/*]]]] 一般には撤廃されていますが、
[[RFC 7230]] でも [CODE(MIME)@en[[[message/http]]]] に対しては引き続き課されているようです。
** 処理モデル
[51] [CODE(MIME)@en[[[message/http]]]] をどのように処理するべきかは規定されていません。
唯一使われる場面が [CODE(HTTP)@en[[[TRACE]]]] [[要求]]に対する[[応答]]ですが、
この[[メソッド]]も[[デバッグ]]用だからか特に処理は規定されていません。
** 本体
[52] [[本体]]は、 [[HTTPメッセージ]]です。
[524] [CODE(MIME)@en[[[message/http]]]] の[[HTTPメッセージ]]は、
[[行長]]に関する [[MIME]] の制限に従う必要があります [SRC[>>517]]。
;; [525] どの制限が不明です。 [[電子メール]]など[[MIME]]を使うプロトコルではなく、
[[MIME]]の側に [CODE(MIME)@en[[[message/*]]]] や[[本体部分]]の[[行長]]宣言ってあるのでしょうか?
[530] [CODE(MIME)@en[[[message/http]]]] の[[HTTPメッセージ]]に関しては、
[[折り畳み]]の禁止に関する制約が緩和されます。詳しくは[[行折り畳み]]を参照してください。
;; [531] なぜ敢えて例外規定を設けてまで、どれだけ実態があるかわからない
[CODE(MIME)@en[[[message/http]]]] による利用を定義しているのか謎です。。。
[[電子メール]]での転送を想定しているのかもしれませんが、唯一の用法である
[CODE(HTTP)@en[[[TRACE]]]] は[[電子メール]]ではありません。
** 関連
[522] [[HTTPメッセージ]]と [[RFC 822]] [[メッセージ]]の類似性から、必然的に
[CODE(MIME)@en[[[message/http]]]] と [CODE(MIME)@en[[[message/rfc822]]]]
はよく似ています。
[523] 一般に [[HTTP]] [[メッセージ]]の [[CTE]]
は [CODE(MIME)@en[[[binary]]]] です。[CODE(MIME)@en[[[7bit]]]] や
[CODE(MIME)@en[[[8bit]]]] の旧来の [[SMTP]] や [[NNTP]]
の如き[[転送路]]では転送することができません。他の[[MIME型]]であれば
[[Base64]] や [[Quoted-Printable]] のような [[CTE]] で[[符号化]]するべきところですが、
[[MIME]] の規定により、 [CODE(MIME)@en[[[message/[VAR[*]]]]]]
の[[符号化]]は一切禁止されているので、仕様に従いつつ転送する術はありません。
[CODE(MIME)@en[[[message/http]]]] の代わりに [CODE(MIME)@en[[[application/http]]]]
として[[札付け]]することでこの制約を回避できます。
* API
[FIG(short list)[ [110] [[HTTPメッセージ]] [[API]]
- [[CGI]]
- [[PSR-7]]
- [CODE[Request]] / [CODE[Response]]
]FIG]
* 歴史
[FIG(quote)[
[FIGCAPTION[
[14] [[HTTP]] ([[RFC 1945]] 1.2, [[RFC 2068]] 1.3, [[RFC 2616]] 1.3)
]FIGCAPTION]
>
:message: The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in [DEL[[INS[{1945]]] Section]] [INS[section]]
4 and transmitted via the connection.
:メッセージ: HTTP 通信の基本単位で、第4章で定義する構文に一致する構造化オクテット列から成り、
[[接続]]を介して転送される。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[10] RFC 1945 4.1 Message Types
]FIGCAPTION]
HTTP messages consist of requests from client to server and responses
from server to client.
HTTP メッセージは顧客からサーバーへの要求とサーバーから顧客への応答
から構成されます。
[PRE[
HTTP-message = Simple-Request ; HTTP/0.9 messages
| Simple-Response
| Full-Request ; HTTP/1.0 messages
| Full-Response
]PRE]
[PRE[
Full-Request and Full-Response use the generic message format of RFC
822 [7] for transferring entities. Both messages may include optional
header fields (also known as "headers") and an entity body. The
entity body is separated from the headers by a null line (i.e., a
line with nothing preceding the CRLF).
]PRE]
Full-Request と Full-Response は実体の転送に RFC 822
の一般メッセージ形式を使います。両メッセージは省略可能な頭欄
(「頭達」とも呼ばれる) と実体本文を含んでも構いません。
実体本文は頭達と空行 (つまり CRLF の前に何も無い行)
で区切ります。
[PRE[
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
]PRE]
[PRE[
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
]PRE]
Simple-Request and Simple-Response do not allow the use of any header
information and are limited to a single request method (GET).
Simple-Request と Simple-Response はいかなる頭情報の使用も
認められませんし、単一要求方式 (GET) に制限されます。
[PRE[
Simple-Request = "GET" SP Request-URI CRLF
]PRE]
[PRE[
Simple-Response = [ Entity-Body ]
]PRE]
Use of the Simple-Request format is discouraged because it prevents
the server from identifying the media type of the returned entity.
Simple-Request 形式の使用は非推奨です。
この形式では返される実体の媒体型を識別できないからです。
]FIG]
[FIG[
[FIGCAPTION[
[11] RFC 2616 4.1 Message Types
]FIGCAPTION]
HTTP messages consist of requests from client to server and responses
from server to client.
HTTP メッセージは顧客からサーバーへの要求とサーバーから顧客への
応答で構成されます。
[PRE[
HTTP-message = Request | Response ; HTTP/1.1 messages
]PRE]
[PRE[
Request (section 5) and Response (section 6) messages use the generic
message format of RFC 822 [9] for transferring entities (the payload
of the message). Both types of message consist of a start-line, zero
or more header fields (also known as "headers"), an empty line (i.e.,
a line with nothing preceding the CRLF) indicating the end of the
header fields, and possibly a message-body.
]PRE]
Request, Response 両メッセージは実体 (メッセージの弾頭)
の転送に RFC 822 の一般メッセージ形式を使います。両メッセージ型は
star-line, 0個以上の頭欄 (「頭達」とも呼ばれる), 頭欄の終わりを示す空行
(つまり CRLF の前に何も無い行), それとあれば message-body から構成されます。
[PRE[
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-Line
]PRE]
[PRE[
In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words, if
the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF.
]PRE]
頑強性の点から、サーバーは Request-Line が来るはずのところで
受け取った空行を無視するべきです。他の言葉でいえば、サーバーが
メッセージの始めのプロトコル列を読んで最初に CRLF を受け取ったなら、
その CRLF は無視するべきです。
[PRE[
Certain buggy HTTP/1.0 client implementations generate extra CRLF's
after a POST request. To restate what is explicitly forbidden by the
BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
extra CRLF.
]PRE]
イかれた HTTP/1.0 の顧客実装は余計な CRLF 達を POST
要求の後に生成します。 BNF で明示的に禁止されていることを
繰り返しますが、 HTTP/1.1 顧客は要求の前や後に余計な
CRLF をつけては'''いけません'''。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[518] RFC 1945 (HTTP/1.0) A.; RFC 2068 (HTTP/1.1) 19.1 Internet Media Type message/http, RFC 2616 (HTTP/1.1) 19.1 Internet Media Type message/http and application/http
]FIGCAPTION]
> In addition to defining the [DEL[[INS[{1945}]] HTTP/1.0]] [INS[HTTP/1.1]] protocol, this document serves
as the specification for the Internet media type "message/http" [INS[[INS[{2616}]] and "application/http"]]. [INS[[INS[{2616}]] The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed).]] The
following is to be registered with IANA [DEL[[INS[{1945}]] [13] ]] [INS[[INS[{2616}]] [17] ]].
この文書は、 HTTP プロトコルを定義するのに加えて、インターネット[[媒体型]]
[CODE(MIME)[message/http]] [INS[および [CODE(MIME)[[[application/http]]]]]]
の仕様を給仕します。[INS[[CODE(MIME)[message/http]] 型は、単一の HTTP 要求メッセージまたは応答メッセージを、すべての [CODE(MIME)[message]] 型についての行長と符号化に関する MIME の制限に従うものとして囲むために使うことができます。 [CODE(HTTP)[application/http]] 型は、一つ以上の HTTP 要求メッセージ群または応答メッセージ群 (非混合。) のパイプ線を囲むために使うことができます。]]
次は、 IANA に登録されます。
>
:Media Type name:message
:Media subtype name:http
:Required parameters:none
:Optional parameters:version, msgtype
>
:version:The HTTP-Version number of the enclosed message
(e.g., [DEL[[INS[{1945}]] "1.0"]] [INS["1.1"]]). If not present, the version can be
determined from the first line of the body.
囲まれたメッセージの [CODE(ABNF)[[[HTTP-Version]]]] 番号
(例えば [CODE(HTTP)[1.0]] や [CODE(HTTP)[1.1]]。)
存在しなければ、版は[[本体]]の最初の行から決定できます。
>
:msgtype:The message type -- "request" or "response". If not
present, the type can be determined from the first
line of the body.
メッセージ型 — [CODE(MIME)[request]] 又は [CODE(MIME)[response]]。
存在しなければ、型は本体の最初の行から決定できます。
>
:Encoding considerations:only "7bit", "8bit", or "binary" are permitted
:Security considerations:none
[INS[
> [INS[{2616}]]
:Media Type name:application
:Media subtype name:http
:Required parameters:none
:Optional parameters:version, msgtype
>
:version:The HTTP-Version number of the enclosed messages
(e.g., "1.1"). If not present, the version can be
determined from the first line of the body.
囲まれたメッセージの [CODE(ABNF)[HTTP-Version]] 番号
(例えば [CODE(HTTP)[1.1]]。)
存在しなければ、版は本体の最初の行から決定できます。
>
:msgtype:The message type -- "request" or "response". If not
present, the type can be determined from the first line of the body.
メッセージ型 — [CODE(MIME)[request]] 又は [CODE(MIME)[response]]。
存在しなければ、型は本体の最初の行から決定できます。
>
:Encoding considerations:HTTP messages enclosed by this type
are in "binary" format; use of an appropriate
Content-Transfer-Encoding is required when
transmitted via E-mail.
この型で囲まれた HTTP メッセージは [CODE(MIME)[[[binary]]]] 書式です。
[[電子メイル]]を介して転送するときには適切な [CODE(MIME)[[[Content-Transfer-Encoding]]]]
が必要です。
>
:Security considerations:none
]INS]
]FIG]
[FIG(quote)[
[FIGCAPTION[
[2048] RFC 1945 (HTTP/1.0) 4.; RFC 2068・2616 (HTTP/1.1) 4 HTTP Message
]FIGCAPTION]
*4.1 Message Types
> HTTP messages consist of requests from client to server and responses
from server to client.
[DFN[HTTP メッセージ]]は、[[クライアント]]から[[サーバー]]への[[要求]]と[[サーバー]]から[[クライアント]]への[[応答]]から成ります。
>
[DEL[
-
[PRE[
HTTP-message = Simple-Request ; HTTP/0.9 messages
| Simple-Response
| Full-Request ; HTTP/1.0 messages
| Full-Response
]PRE]
]DEL]
[INS[
- HTTP-message = Request | Response ; HTTP/1.1 messages
]INS]
> [DEL[Full-Request]] [INS[Request (section 5)]] and [DEL[Full-Response]] [INS[Response (section 6) messages]] use the generic message format of RFC 822 [DEL[ [7] ]] [INS[ [9] ]]
for transferring entities [INS[(the payload of the message)]]. [DEL[Both messages may include optional header fields (also known as "headers") and an entity body. The entity body is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF).]] [INS[Both types of message consist of a start-line, [DEL[one]] [INS[zero]] or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and [DEL[an optional]] [INS[possibly a]] message-body.]]
(完全)要求メッセージと(完全)応答メッセージは、[[実体]] [INS[(メッセージの積荷)]]
を転送するために [[RFC822]] の一般メッセージ書式を使います。
メッセージのどちらの型も、 [CODE(ABNF)[start-line]] (開始行)、[DEL[一つ]][INS[零個]]以上の[[頭欄]]
([CODE[[[頭]]]]とも)、頭欄並びの終わりを示す空行 (つまり [[CRLF]] の前に何も無い行)、
それにもしかすると [CODE(ABNF)[[[message-body]]]] (メッセージ本体)
から成ります。
>
[DEL[
-
[PRE[
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
]PRE]
-
[PRE[
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
]PRE]
]DEL]
>
[INS[
-
[PRE[
generic-message = start-line
[DEL[*message-header]]
[INS[*(message-header CRLF)]]
CRLF
[ message-body ]
]PRE]
- start-line = Request-Line | Status-Line
]INS]
[DEL[
> Simple-Request and Simple-Response do not allow the use of any header
information and are limited to a single request method (GET).
[CODE(ABNF)[Simple-Request]] (単純要求) と [CODE(ABNF)[Simple-Response]]
は頭情報の使用を認めず、要求方式も1つ ([CODE(HTTP)[[[GET]]]])
に限定します。
>
- Simple-Request = "GET" SP Request-URI CRLF
>
- Simple-Response = [ Entity-Body ]
> Use of the Simple-Request format is discouraged because it prevents
the server from identifying the media type of the returned entity.
[CODE(HTTP)[Simple-Request]] 書式は、サーバーから返される実体の[[媒体型]]を識別することができませんから、
その使用は非推奨とします。
]DEL]
[INS[
> In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words, if
the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF.
頑強性の観点から、サーバーは [CODE(ABNF)[[[Request-Line]]]]
が期待されるところで受取った空行(並び)を無視する'''べきです'''。
言い換えると、サーバーがメッセージのはじめでプロトコル流を読んでいて最初に
CRLF を受取ったら、この CRLF は無視するべきです。
> [DEL[Note: certain]] [INS[Certain]] buggy HTTP/1.0 client implementations generate [DEL[an]]
extra CRLF's after a POST request. To restate what is explicitly
forbidden by the BNF, an HTTP/1.1 client [DEL[must not]] [INS[MUST NOT]] preface or follow
a request with an extra CRLF.
ある蝕まれた HTTP/1.0 クライアント実装は [CODE(HTTP)[[[POST]]]]
要求の後に余分な CRLF を生成します。 BNF で陽に禁止されていることを繰り返しますが、
HTTP/1.1 クライアントは要求の前や後に余分な CRLF を入れては'''いけません'''。
]INS]
[INS[
注: 追加・削除は 1945→2068 のもの。追加中の追加・削除は
2068→2616 のもの。
]INS]
* 4.2 Message Headers
→[CODE(WikiPage)[[[HTTP//頭欄]]]]
*RFC 2068・2616 4.3 Message Body
→[CODE(WikiPage)[[[message-body]]]]
*RFC 2068・2616 4.4 Message Length
→[CODE(WikiPage)[[[Content-Length]]]]
*RFC 1945 4.3; RFC 2068・2616 4.5 General Header Fields
→[CODE(WikiPage)[[[一般頭欄]]]]
]FIG]
[FIG(quote)[
[FIGCAPTION[
[2049] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 2.2 Basic Rules
]FIGCAPTION]
> The following rules are used throughout this specification to
describe basic parsing constructs. The US-ASCII coded character set
is defined by [DEL[[INS[{1945}]] [17] ]] [INS[[INS[{2068,2616}]] ANSI X3.4-1986 [21] ]].
次の規則はこの仕様書を通じて基本解析構造体を記述するために使用します。
US-ASCII 符号化文字集合は ANSI X 3.4‐1986 で定義されています。
>
-OCTET = <any 8-bit sequence of data>
-CHAR = <any US-ASCII character (octets 0 - 127)>
-UPALPHA = <any US-ASCII uppercase letter "A".."Z">
-LOALPHA = <any US-ASCII lowercase letter "a".."z">
-ALPHA = UPALPHA | LOALPHA
-DIGIT = <any US-ASCII digit "0".."9">
-CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
-CR = <US-ASCII CR, carriage return (13)>
-LF = <US-ASCII LF, linefeed (10)>
-SP = <US-ASCII SP, space (32)>
-HT = <US-ASCII HT, horizontal-tab (9)>
-<"> = <US-ASCII double-quote mark (34)>
> [DEL[HTTP/1.0]] [INS[HTTP/1.1]] defines the [DEL[[INS[{1945}]] octet]]
sequence CR LF as the end-of-line marker for all protocol elements except
the [DEL[[INS[{1945}]] Entity-Body]] [INS[entity-body]] (see [DEL[[INS[{1945}]] Appendix B]] [INS[appendix 19.3]] for tolerant applications). The end-of-line marker within an [DEL[[INS[{1945}]] Entity-Body]] [INS[entity-body]]
is defined by its associated media type, as described in [DEL[[INS[{1945}]] Section 3.6]] [INS[section 3.7]].
HTTP は実体本体を除くすべてのプロトコル要素で列
CR LF を行末の[RUBY[印] [しるし]]と定義します。
実体本体中の行末の印はその関連付けられた[[媒体型]]により定義されます。
>
-CRLF = CR LF
> [DEL[HTTP/1.0]] [INS[HTTP/1.1]] [DEL[[INS[{1945,2068}]] headers]] [INS[[INS[{2616}]] header field values]] [DEL[[INS[{1945}]] may]] [INS[can]] be folded onto multiple lines if [DEL[[INS[{1945}]] each]] [INS[the]]
continuation line begins with a space or horizontal tab. All
linear [DEL[[INS[{1945}]] whitespace]] [INS[white space]], including folding, has the same semantics as SP. [INS[[INS[{2616}]] A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.]]
HTTP 頭[INS[欄値]]は、続く行が間隔又は水平タブで始まるのであれば複数行に折畳むことができます。
すべての線形空白は、折畳みも含み、 [CODE(ABNF)[SP]]
と同じ意味を持ちます。[INS[受信者は、欄値を解釈したり[[下流]]にメッセージを転送する前に任意の線形空白を単一の [CODE(ABNF)[SP]] に置換しても'''構いません'''。]]
>
-LWS = [CRLF] 1*( SP | HT )
[DEL[
>[INS[{1945}]] However, folding of header lines is not expected by some
applications, and should not be generated by HTTP/1.0 applications.
しかし、頭行の折畳みを予期していない応用もありますので、
HTTP/1.0 応用は生成するべきではありません。
]DEL]
> The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT [DEL[[INS[{1945,2068}]] may]] [INS[[INS[{2616}]] MAY]] contain [DEL[[INS[{1945}]] octets]] [INS[characters]] from character sets other than [DEL[[INS[{1945}]] US-ASCII]] [INS[[INS[{2068,2616}]] [DEL[ISO 8859-1]] [INS[ISO-8859-1]] [22] only when encoded according to the rules of RFC [DEL[1522]] [INS[2047]] [14] ]].
[CODE(ABNF)[TEXT]] 規則は記述的欄内容とメッセージ解析器に解釈されることを意図しない値にのみ使います。
[CODE(ABNF)[*TEXT]] の語は [DEL[US-ASCII]] [INS[RFC 2047 の規則に従って符号化するときのみ ISO-8859-1]]
以外の文字集合の[DEL[オクテット]][INS[文字]]を含んでも'''構いません'''。
>
-TEXT = <any OCTET except CTLs, but including LWS>
[DEL[
>[INS[{1945}]] Recipients of header field TEXT containing octets outside the US-ASCII
character set may assume that they represent ISO-8859-1 characters.
US-ASCII 文字集合の外のオクテットを含んだ頭欄 [CODE(ABNF)[TEXT]] の受信者は、
それが ISO-8859-1 文字を表現するものと仮定しても構いません。
]DEL]
[INS[
>[INS[{2616}]] A CRLF is allowed in the definition of TEXT only as part of a header
field continuation. It is expected that the folding LWS will be
replaced with a single SP before interpretation of the TEXT value.
[CODE(ABNF)[CRLF]] は、 [CODE(ABNF)[TEXT]] の定義の中では、
頭欄継続の一部としてのみ認められています。
折畳み [CODE(ABNF)[LWS]] は [CODE(ABNF)[TEXT]] 値の解釈の前に単一の
[CODE(ABNF)[SP]] に置換されることを意図定しています。
]INS]
> Hexadecimal numeric characters are used in several protocol elements.
十六進数文字は幾つかのプロトコル要素で使います。
>
-HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
> Many [DEL[HTTP/1.0]] [INS[HTTP/1.1]] header field values consist of words separated by LWS
or special characters. These special characters [DEL[[INS[{1945}]] must]] [INS[MUST]] be in a quoted
string to be used within a parameter value [INS[[INS[{2616}]] (as defined in section 3.6)]].
多くの HTTP 頭欄値は、 [CODE(ABNF)[LWS]] または特殊文字で分離される語で構成されます。
特殊文字は引数値中で使うためには引用文字列中にいれなければ'''なりません'''。
[DEL[
>[INS[{1945}]]
- word = token | quoted-string
]DEL]
[DEL[
>[INS[{1945,2068}]]
-token = 1*<any CHAR except CTLs or tspecials>
-tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
]DEL]
[INS[
>[INS[{2616}]]
-token = 1*<any CHAR except CTLs or separators>
-separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
]INS]
> Comments [DEL[[INS[{1945}]] may]] [INS[can]] be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.
In all other fields, parentheses are considered part of the field value.
注釈は、注釈文を括弧で囲むことで幾つかの HTTP 頭欄中に含めることができます。
注釈は、欄値定義の一部に [CODE(ABNF)[comment]] を含んでいる欄でのみ認められます。
他のすべての欄では、括弧は欄値の一部とみなされます。
>
-[DEL[[INS[{1945,2068}]] comment = "(" *( ctext | comment ) ")"]]
-[INS[[INS[{2616}]] comment = "(" *( ctext | quoted-pair | comment ) ")"]]
-ctext = <any TEXT excluding "(" and ")">
> A string of text is parsed as a single word if it is quoted using
double-quote marks.
二重引用符を使って引用されている文字列は単一の語として解析します。
>
-[DEL[[INS[{1945,2068}]] quoted-string = ( <"> *(qdtext) <"> )]]
-[INS[[INS[{2616}]] quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )]]
-[DEL[[INS[{1945}]] qdtext = <any CHAR except <"> and CTLs, but including LWS>]]
-[INS[[INS[{2068,2616}]] qdtext = <any TEXT except <">>]]
[DEL[
>[INS[{1945}]] Single-character quoting using the backslash ("\") character is not
permitted in HTTP/1.0.
HTTP/1.0 では逆斜線 ([CODE(char)[\]]) 文字を使った単一文字引用は認められていません。
]DEL]
[INS[
>[INS[{2068,2616}]] The backslash character ("\") [DEL[may]] [INS[MAY]] be used as a single-character quoting
mechanism only within quoted-string and comment constructs.
逆斜線文字 ([CODE(HTTP)[\]]) は、 [CODE(ABNF)[quoted-string]] 構造体および
[CODE(ABNF)[comment]] 構造体の中でのみ、
単一文字引用機構として使って'''構いません'''。
>
- quoted-pair = "\" CHAR
]INS]
]FIG]
[FIG(quote)[
[FIGCAPTION[
[2050] RFC 2326 (RTSP/1.0) 15 Syntax
]FIGCAPTION]
> The RTSP syntax is described in an augmented Backus-Naur form (BNF)
as used in RFC 2068 [2].
*15.1 Base Syntax
>
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
>
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
CRLF = CR LF
LWS = [CRLF] 1*( SP | HT )
TEXT = <any OCTET except CTLs>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
>
token = 1*<any CHAR except CTLs or tspecials>
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <any TEXT except <">>
quoted-pair = "\" CHAR
>
message-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value and
consisting of either *TEXT or
combinations of token, tspecials, and
quoted-string>
>
safe = "\$" | "-" | "_" | "." | "+"
extra = "!" | "*" | "$'$" | "(" | ")" | ","
>
hex = DIGIT | "A" | "B" | "C" | "D" | "E" | "F" |