/
198.txt
2487 lines (2043 loc) · 142 KB
/
198.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
[REFS[
- [4] [CITE@en[RFC 3229 - Delta encoding in HTTP]] ([TIME[2014-10-26 21:15:25 +09:00]] 版) <http://tools.ietf.org/html/rfc3229>
]REFS]
;; [6] [[差分符号化]]も参照。
'''Delta encoding in HTTP [INS[HTTP における差分符号化]]'''
-Network Working Group
-Request for Comments: 3229
-Category: Standards Track
- J. Mogul
- Compaq WRL
- B. Krishnamurthy
- F. Douglis
- AT&T
- A. Feldmann
- Univ. of Saarbruecken
- Y. Goland
- A. van Hoff
- Marimba
- D. Hellerstein
- ERS/USDA
- January 2002
* Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
* Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
* Abstract
> This document describes how delta encoding can be supported as a
compatible extension to HTTP/1.1.
この文書は、 HTTP/1.1 に互換な拡張としてどう差分符号化に対応することができるかを記述します。
> Many HTTP (Hypertext Transport Protocol) requests cause the retrieval
of slightly modified instances of resources for which the client
already has a cache entry. Research has shown that such modifying
updates are frequent, and that the modifications are typically much
smaller than the actual entity. In such cases, HTTP would make more
efficient use of network bandwidth if it could transfer a minimal
description of the changes, rather than the entire new instance of
the resource. This is called "delta encoding."
多くの HTTP (ハイパーテキスト転送プロトコル) 要求は
クライアントが既にキャッシュ項目を持つ資源を微妙に修正した実現値を取り出すこととなります。
研究によればそのような修正による更新は頻繁にあり、
その修正は典型的なところでは実体の実体より小さいのです。
そのような場合、 HTTP は資源の新しい実現値全体を転送するのではなく、
変更の最小限の記述を転送することができればネットワーク帯域のより効率的な使用が行えるでしょう。
これを「差分符号化」と呼びます。
* Table of Contents
1 Introduction.................................................... 3
1.1 Related research and proposals........................... 4
2 Goals........................................................... 5
3 Terminology..................................................... 6
4 The HTTP message-generation sequence............................ 8
4.1 Relationship between deltas and ranges................... 11
5 Basic mechanisms................................................ 13
5.1 Background: an overview of HTTP cache validation......... 13
5.2 Requesting the transmission of deltas.................... 14
5.3 Choice of delta algorithm and format..................... 16
5.4 Identification of delta-encoded responses................ 16
5.5 Guaranteeing cache safety................................ 17
5.6 Transmission of delta-encoded responses.................. 18
5.7 Examples of requests combining Range and delta encoding.. 19
6 Encoding algorithms and formats................................. 22
7 Management of base instances.................................... 23
7.1 Multiple entity tags in the If-None-Match header......... 24
7.2 Hints for managing the client cache...................... 25
8 Deltas and intermediate caches.................................. 27
9 Digests for data integrity...................................... 28
10 Specification.................................................. 28
10.1 Protocol parameter specifications....................... 28
10.2 IANA Considerations..................................... 30
10.3 Basic requirements for delta-encoded responses.......... 30
10.4 Status code specifications.............................. 30
10.4.1 226 IM Used...................................... 31
10.5 Header specifications................................... 31
10.5.1 Delta-Base....................................... 31
10.5.2 IM............................................... 32
10.5.3 A-IM............................................. 33
10.6 Caching rules for 226 responses......................... 35
10.7 Rules for deltas in the presence of content-codings..... 36
10.7.1 Rules for generating deltas in the presence of
content-codings.................................. 37
10.7.2 Rules for applying deltas in the presence of
content-codings.................................. 37
10.7.3 Examples for using A-IM, IM, and content-codings. 38
10.8 New Cache-Control directives............................ 40
10.8.1 Retain directive................................. 40
10.8.2 IM directive..................................... 40
10.9 Use of compression with delta encoding.................. 41
10.10 Delta encoding and multipart/byteranges................ 42
11 Quantifying the protocol overhead.............................. 42
12 Security Considerations........................................ 44
13 Acknowledgements............................................... 44
14 Intellectual Property Rights................................... 44
15 References..................................................... 44
16 Authors' addresses............................................. 47
17 Full Copyright Statement....................................... 49
* 1 Introduction
> The World Wide Web is a distributed system, and so often benefits
from caching to reduce retrieval delays. Retrieval of a Web resource
(such as a document, image, icon, or applet) over the Internet or
other wide-area networks usually takes enough time that the delay is
over the human threshold of perception. Often, that delay is
measured in seconds. Caching can often eliminate or significantly
reduce retrieval delays.
World Wide Web は分散システムであり、したがってしばしば取出しの遅延を削減するために[[キャッシュ付け]]から利益を得ます。[[インターネット]]や他の広域網上の
Web [[資源]] ([[文書]], [[画像]], [[アイコン]]や [[applet]])
の取出しは通常遅延が人間の認識の閾値を超えるのに十分な時間がかかります。
しばしば、この遅延は秒単位となります。キャッシュ付けはしばしば取出し遅延を除去したり著しく削減したりすることができます。
> Many Web resources change over time, so a practical caching approach
must include a coherency mechanism, to avoid presenting stale
information to the user. Originally, the Hypertext Transfer Protocol
(HTTP) provided little support for caching, but under operational
pressures, it quickly evolved to support a simple mechanism for
maintaining cache coherency.
多くの [[Web]] 資源は刻々と変化するので、現実的なキャッシュ付け手法は[[腐敗]]した情報を[[利用者]]に提示することを避けるための密着機構を含まなければなりません。元々、ハイパーテキスト転送プロトコル
([[HTTP]]) はキャッシュ付けにほとんど対応していませんでしたが、運用の圧力の元、キャッシュの密着性を維持するための単純な仕組みを提供するようにすばやく改良されました。
> In HTTP/1.0 [2], the server may supply a "last-modified" timestamp
with a response. If a client stores this response in a cache entry,
and then later wishes to re-use the response, it may transmit a
request message with an "If-modified-since" field containing that
timestamp; this is known as a conditional retrieval. Upon receiving
a conditional request, the server may either reply with a full
response, or, if the resource has not changed, it may send an
abbreviated reply, indicating that the client's cache entry is still
valid. HTTP/1.0 also includes a means for the server to indicate,
via an "Expires" timestamp, that a response will be valid until that
time; if so, a client may use a cached copy of the response until
that time, without first validating it using a conditional retrieval.
[[HTTP/1.0]] では、[[鯖]]は[[応答]]に「最終修正」[[時刻印]]を供給することができます。[[クライアント]]がこの応答を[[キャッシュ項目]]に蓄積していて、後からその応答を再利用したいと思うなら、時刻印を含めた
[CODE(HTTP)[If-modified-since]] 欄を添えて[[要求メッセージ]]を転送することができます。
これは[[条件付取出し]]と言われています。鯖は、[[条件付要求]]を受信したら、
完全な応答で返答しても構いませんし、その資源が変更されていなければ、
クライアントのキャッシュ項目が依然[[妥当]]であることを示す、
省略した返答を送信しても構いません。 HTTP/1.0
はある応答がある時刻までは妥当であると鯖が示すための
[CODE(HTTP)[[[Expires]]]] 時刻印という手段をも含んでいます。
その場合は、クライアントは応答のキャッシュした複製をその時刻までは条件付取出しを使って最初に健勝しなくても使用して構いません。
> HTTP/1.1 [10] adds many new features to improve cache coherency and
performance. However, it preserves the all-or-none model for
responses to conditional retrievals: either the server indicates that
the resource value has not changed at all, or it must transmit the
entire current value.
[[HTTP/1.1]] はキャッシュの密着性と効率を向上させるための新しい機能を多く加えました。
しかし、条件付取出しに対する応答の「すべてまたは何もなし」模型はそのままにしています。
鯖は資源値が全く変更されていないことを示すか、または現在値全体を転送しなければなりません。
> Common sense suggests (and traces confirm), however, that even when a
Web resource does change, the new instance is often substantially
similar to the old one. If the difference, or "delta", between the
two instances could be sent to the client instead of the entire new
instance, a client holding a cached copy of the old instance could
apply the delta to construct the new version. In a world of finite
bandwidth, the reduction in response size and delay could be significant.
しかし常識的に (そして追跡が裏付けるように)、
Web 資源が変更される時といっても、しばしば大抵は新しい[[実現値]]は古い実現値と似ています。
その二つの実現値の差異、「差分」を新しい実現値全体の代わりにクライアントに送信することができれば、古い実現値のキャッシュした複製を保持しているクライアントは新しい版を構築するために差分を適用することができます。
有限の帯域の世界では、応答の寸法と遅延の削減は重大となり得ます。
> One can think of deltas as a way to squeeze as much benefit as
possible from client and proxy caches. Rather than treating an
entire response as the "cache line", with deltas we can treat
arbitrary pieces of a cached response as the replaceable unit, and
avoid transferring pieces that have not changed.
差分はクライアントと串のキャッシュから可能な限り利益を絞り取る方法であると考えることができます。応答全体を「キャッシュ線」として扱うよりもむしろ、
差分をもってキャッシュした資源の任意の欠片を置換可能な単位として扱い、
変更されていない欠片を転送することを避けることができます。
> This document proposes a set of compatible extensions to HTTP/1.1
that allow clients and servers to use delta encoding with minimal overhead.
この文書は、クライアントと鯖が最小の overhead で差分符号化を使用することを可能にする HTTP/1.1 への互換な拡張の集合を提案します。
> We assume that the reader is familiar with the HTTP/1.1 specification.
読者は HTTP/1.1 仕様書に精通しているものと想定します。
** 1.1 Related research and proposals
> The idea of delta encoding to reduce communication or storage costs
is not new. For example, the MPEG-1 video compression standard
transmits occasional still-image frames, but most of the frames sent
are encoded (to oversimplify) as changes from an adjacent frame. The
SCCS and RCS [27] systems for software version control represent
intermediate versions as deltas; SCCS starts with an original version
and encodes subsequent ones with forward deltas, whereas RCS encodes
previous versions as reverse deltas from their successors.
Jacobson's technique for compressing IP and TCP headers over slow
links [17] uses a clever, highly specialized form of delta encoding.
通信や蓄積の経費の削減のために差分符号化を行うという考えは新しい物ではありません。例えば、 [[MPEG-1]] ビデオ圧縮規格は刻々の静止画こまを転送しますが、送られるこまのほとんどは (簡単に言えば) 隣のこまからの変更として符号化します。
ソフトウェア版制御のための [[SCCS]] や [[RCS]] のシステムは、
中間版を差分で表現します。 SCCS は元の版から開始し、後の版を正の差分で符号化し、逆に RCS は前の版を次の版からの逆向きの差分として符号化します。
遅い連結で [[IP]] や [[TCP]] の頭を圧縮する Jacobson
の技法は巧妙で非常に特化した形の差分符号化を使用しています。
> In spite of this history, it appears to have taken several years
before anyone thought of applying delta encoding to HTTP, perhaps
because the development of HTTP caching has been somewhat haphazard.
The first published suggestion for delta encoding appears to have
been by Williams et al. in a paper about HTTP cache removal policies
[30], but these authors did not elaborate on their design until later [29].
このような歴史にもかかわらず、 [[HTTP]] に差分符号化を適用しようと考える人が出てくるまでには幾年も要しました。おそらくは、
HTTP [[キャッシュ付け]]の開発に行き当たりばったりなどころがあるからでしょう。
差分符号化についての最初の出版された提案は Williams 他の HTTP
キャッシュ削除方針についての論文のようですが、この著者は後になるまでその設計を詰めてはいませんでした。
> The WebExpress project [15] appears to be the first published
description of an implementation of delta encoding for HTTP (which
they call "differencing"). WebExpress is aimed specifically at
wireless environments, and includes a number of orthogonal
optimizations. Also, the WebExpress design does not propose changing
the HTTP protocol itself, but rather uses a pair of interposed
proxies to convert the HTTP message stream into an optimized form.
The results reported for WebExpress differencing are impressive, but
are limited to a few selected benchmarks.
[[WebExpress]] 計画は最初に HTTP の差分符号化の実装の記述を出版したようです
(そこでは「差異取り」と呼ばれています)。 WebExpress は特に無線環境を考慮しており、数々の直交する最適化を含んでいました。
また、 WebExpress の設計は HTTP プロトコル自体の変更を提案してはおらず、
HTTP メッセージ流を最適化形に変換する仲介串の組を使用していました。
WebExpress 差異取りの結果の報告は目覚しい物ではありますが、
少数の選択された評価基準に限られています。
> Banga et al. [1] describe the use of optimistic deltas, in which a
layer of interposed proxies on either end of a slow link collaborate
to reduce latency. If the client-side proxy has a cached copy of a
resource, the server-side proxy can simply send a delta (or a 304
[Not Modified] response). If only the server-side proxy has a cached
copy, it may optimistically send its (possibly stale) copy to the
client-side proxy, followed (if necessary) by a delta once the
server-side proxy has validated its own cache entry with the origin
server. The use of optimistic deltas, unlike delta encoding,
actually increases the number of bytes sent over the network, in an
attempt to improve latency by anticipating a "Not Modified" response
from the origin server. The optimistic delta paper, like the
WebExpress paper, did not propose a change to the HTTP protocol
itself, and reported results only for a small set of selected URLs.
Banga 他は、遅い連結の一端で仲介串の層が待ち時間の削減に協力するという楽天的差分の使用を記述しています。クライアント側串が[[資源]]のキャッシュした複製を有していれば、鯖側串は単に差分 (または [CODE(HTTP)[[[204]]]] (未修正) 応答) を送ることができます。鯖側串がキャッシュした複製を有していれば、楽観的に ([[腐敗]]しているかもしれない) 複製をクライアント側串に送り、 (必要なら) 鯖側串は自身のキャッシュ項目を[[起源鯖]]で[[検証]]して差分を続けて送ります。
楽天的差分を使用すると、差分符号化とは異なり、起源鯖からの「未修正」応答を先回りすることで待ち時間を改善しようとする中で、実際にはネットワーク上に送信するバイトの数は増加します。
楽天的差分の論文は、 WebExpress の論文と同様に、 HTTP
プロトコル自体の変更は提案せず、選択された [[URL]]
の小さな集合についてのみの結果を報告していました。
> Mogul et al. [23] collected lengthy traces, at two different sites,
of the full contents of HTTP messages, to quantify the potential
benefits of delta-encoded responses. They showed that delta encoding
can provide remarkable improvements in response-size and response-delay for an important subset of HTTP content types. They proposed a
set of HTTP extensions, but without the level of detail required for
a specification. Douglis et al. [8] used the same sets of full-content traces to quantify the rate at which resources change in the Web.
Mogul 他は、二つの異なるサイトにおいて、 HTTP メッセージの完全な内容の長さ的追跡を集成し、差分符号化応答の潜在的利益を数量化しました。
そこでは差分符号化が HTTP 内容型の重要な部分集合で応答の寸法と遅延において著しい改善を行えることを示しました。
彼らは HTTP 拡張の集合を提案しましたが、仕様書に必要な詳細度ではありませんでした。
Douglis 他は完全な内容の追跡の同じ集合を使用して Web の資源の変更率を数量化しました。
> The HTTP Distribution and Replication Protocol (DRP), proposed to W3C
by Marimba, Netscape, Sun, Novell, and At Home, aims to provide a
collection of new features for HTTP, to support "the efficient
replication of data over HTTP" [13]. One aspect of the DRP proposal
is the use of "differential downloading," which is essentially a form
of delta encoding. The original DRP proposal uses a different
approach than is described here, but a forthcoming revision of DRP
will be revised to conform to the proposal in this document.
HTTP 配布模造プロトコルは Marimba, Netscape, Sun, Novell, At Home
が W3C に提案した物でありますが、これは
「HTTP 上でデータの効率的な模造」を支援するために HTTP
に新しい機能の集成を提供することを目指しています。
DRP プロトコルの一つの側面は「差異取り寄せ」の使用であり、
これは本質的には差分符号化の一形態です。元の DRP
プロトコルはここで説明する物とは異なる手法を使っていますが、
いずれ改訂された時には DRP はこの文書での提案に適合するものとなります。
> Tridgell and Mackerras [28] describe the "rsync" algorithm, which
accomplishes something similar to delta encoding. In rsync, the
client breaks a cache entry into a series of fixed-sized blocks,
computes a digest value for each block, and sends the series of
digest values to the server as part of its request. The origin
server does the same block-based computation, and returns only those
blocks whose digest values differ. We believe that it might be
possible to support rsync using the "instance manipulation" framework
described later in this document, but this has not been worked out in
any detail.
Tridgell と Mackerras は、差分符号化と似た物を実現する「[[rsync]]」
算法を記述しています。 rsync では、クライアントはキャッシュ項目を固定長の塊の系列に分割し、各塊の要約値を計算し、要約値の系列を要求の一部として鯖に送信します。起源鯖は同じ塊をもとにした計算を行い、
要約値が異なる塊のみを返します。この文書で後から説明する
「[[実現値操作]]」の枠組みを使用して rsync に対応することは可能であろうと考えていますが、その詳細な作業は行われていません。
* 2 Goals
> The goals of this proposal are:
この提案の目標は、
>
-1. Reduce the mean size of HTTP responses, thereby improving
latency and network utilization.
-2. Avoid any extra network round trips.
-3. Minimize the amount of per-request and per-response overheads.
-4. Support a variety of encoding algorithms and formats.
-5. Interoperate with HTTP/1.0 and HTTP/1.1.
-6. Be fully optional for clients, proxies, and servers.
-7. Allow moderately simple implementations.
- HTTP 応答の平均的寸法を削減し、それによって待ち時間とネットワーク性能を改善すること
- 余計なネットワーク往復を避けること
- 要求毎や応答毎の overhead の量を最小化すること
- 種々の符号化算法・書式に対応すること
- [[HTTP/1.0]] および [[HTTP/1,1]] を相互運用できること
- クライアント, 串, 鯖にとって完全に任意選択機能であること
- 適度に簡単に実装できること
です。目標には次のことは含みません。
> The goals do not include:
- Reducing the number of HTTP requests sent to an origin server.
- Reducing the size of every HTTP message.
- Increasing the cache-hit ratio of HTTP caches.
- Allowing excessively simplistic implementations of delta encoding.
- Delta encoding of request messages, or of responses to methods other than GET.
- 起源鯖に送信する HTTP 要求の数の削減。
- 各 HTTP メッセージの寸法の削減。
- HTTP キャッシュのキャッシュ打率の増幅。
- 極端に簡単な差分符号化の実装の実現。
- 要求メッセージの差分符号化や、 [CODE(HTTP)[[[GET]]]] 以外の方式に対する応答の差分符号化。
>Nothing in this specification specifically precludes the use of
a delta encoding for the body of a PUT request. However, no
mechanism currently exists for the client to discover if the
server can interpret such messages, and so we do not attempt to
specify how they might be used.
この仕様書は特に [CODE(HTTP)[[[PUT]]]] 要求の[[本体]]で差分符号化を使用することを妨げはしません。
しかし、現在のところ鯖がそのようなメッセージを解釈できるかどうかをクライアントが発見する仕組みは存在していませんから、
これをどう使用するのかを述べようとはしません。
* 3 Terminology
> HTTP/1.1 [10] defines the following terms:
[[HTTP/1.1]] は次の用語を定義しています。
>
: resource :
A network data object or service that can be
identified by a URI, as defined in section 3.2.
Resources may be available in multiple
representations (e.g. multiple languages, data
formats, size, resolutions) or vary in other ways.
[[資源]]
>
: entity :
The information transferred as the payload of a
request or response. An entity consists of
metainformation in the form of entity-header fields
and content in the form of an entity-body, as
described in section 7.
[[実体]]
>
: variant :
A resource may have one, or more than one,
representation(s) associated with it at any given
instant. Each of these representations is termed a
`variant.' Use of the term `variant' does not
necessarily imply that the resource is subject to
content negotiation.
[[変体]]
> The dictionary definition for "entity" is "something that has
separate and distinct existence and objective or conceptual reality" [21]. Unfortunately, the definition for "entity" in HTTP/1.1 is
similar to that used in MIME [12], based on a false analogy between
MIME and HTTP.
「[[実体]]」の辞書的定義は「分離された異なる存在ならびに物体的または概念的現実性を有するもの」です。
不幸にも、 HTTP/1.1 の「実体」の定義は [[MIME]] で使われているものと同様で、
完全に間違った MIME と HTTP との類似性に基づいています。
> In MIME, electronic mail messages do have distinct and separate
existences. MIME defines "entity" as something that "refers
specifically to the MIME-defined header fields and contents of either
a message or one of the parts in the body of a multipart entity."
MIME では、電子メイル・メッセージは異なる分離された存在を有していました。
MIME は「実体」を「メッセージまたは[[多部分実体]]の本体中の[[部分]]の一つのいずれかの MIME 定義[[頭欄]]および[[内容]]を特に指す」ものとして定義しています。
> In HTTP, however, a response message to a GET does not have a
distinct and separate existence. Rather, it reflects the current
state of a resource (or a variant, subject to a set of constraints).
The HTTP/1.1 specification has no term to describe "the value that
would be returned in response to a GET request at the current time
for the selected variant of the specified resource." This leads to
awkward wordings in the HTTP/1.1 specification in places where this
concept is necessary.
しかし、 HTTP では、 [CODE(HTTP)[[[GET]]]] に対する[[応答メッセージ]]は異なる分離された存在を有していません。
むしろ、応答メッセージは資源の現在の状態 (制約の集合の対象となる、[[変体]])
を記述しています。 HTTP/1.1 仕様書は「指定された資源の選択された変体についての現時点で
[CODE(HTTP)[GET]] 要求に対する応答で返されることになる値」
を記述する用語を提供していません。このために、 HTTP/1.1
仕様書でこの概念が必要なところでぐちゃぐちゃした言い方をしています。
> To express this concept, we define a new term, for use in this document:
HTTP/1.1 仕様書での用語遣いの失敗を修正するのにはもう遅すぎますので、
代わりにこの文書で使用するために新しい用語を定義します。
>
: instance :
The entity that would be returned in a status-200
response to a GET request, at the current time, for
the selected variant of the specified resource, with
the application of zero or more content-codings, but
without the application of any instance manipulations
(see below) or transfer-codings.
:実現値:
特定の[[資源]]の選択された[[変体]]について、
[CODE(HTTP)[[[GET]]]] [[要求]]に対する[[状態]]
[CODE(HTTP)[[[200]]]] の[[応答]]で、現時点において返されるであろう、
零個以上の[[内容符号化]]を適用した、
[[実現値操作]]や[[転送符号化]]は適用していない[[実体]]。
> It is convenient to think of an entity tag, in HTTP/1.1, as being
associated with an instance, rather than an entity. That is, for a
given resource, two different response messages might include the
same entity tag, but two different instances of the resource should
never be associated with the same (strong) entity tag.
HTTP/1.1 の[[実体札]]は、実体と関連付けられていると考えるよりは、
実現値と関連付けられていると考えた方が便利です。
すなわち、ある資源について、二つの異なる[[応答メッセージ]]は同じ実体札を返すかもしれませんが、
その資源の二つの異なる実現値は決して同じ (強い) 実体札に関連付けられるべきではありません。
> We will informally use the term "delta," in this document, to mean an
HTTP response encoded as the difference between two instances.
この文書では用語「差分」を非公式に、二つの実現値間の差異を符号化した
HTTP [[応答]]を意味して使います。
> More formally, delta encodings are members of a potentially larger
class of transformations on instances, leading to this new term:
より公式に、差分符号化はこの新しい用語を導く、
潜在的により大きな実現値の変形の種別の一員です。
>
: instance manipulation :
An operation on one or more instances which may
result in an instance being conveyed from server to
client in parts, or in more than one response
message. For example, a range selection or a delta
encoding. Instance manipulations are end-to-end, and
often involve the use of a cache at the client.
:実現値操作:
一つ以上の[[実現値]]についての演算であり、
結果として一つの実現値が[[鯖]]から[[クライアント]]に部分的に、または複数の[[要求メッセージ]]によって運ばれてくることになるかもしれない。
例えば、範囲選択や[[差分符号化]]である。
実現値操作は[[末端対末端]]であり、しばしばクライアントでの[[キャッシュ]]の使用を伴う。
> For reasons that will become clear later on, it is convenient to
think about subrange selection as a form of instance manipulation.
In some contexts, compression might also be treated as an instance
manipulation, rather than as a content-coding or transfer-coding.
後々明らかになってくる理由から、部分範囲選択を実現値操作の一形式と考えると便利です。
文脈によっては、圧縮もまた[[内容符号化]]や[[転送符号化]]ではなく実現値操作として扱われるかもしれません。
* 4 The HTTP message-generation sequence
→ [[HTTP//変形]]
* 5 Basic mechanisms
> In this section, we explain the concepts behind delta encoding. This
is not meant as a formal specification of the proposed extensions;
see section 10 for that.
この章では、差分符号化の背後にある概念を説明します。
これは提案する拡張の正式な仕様を意味する物ではありません。
正式な仕様は10章を参照して下さい。
** 5.1 Background: an overview of HTTP cache validation
> When a client has a response in its cache, and wishes to ensure that
this cache entry is current, HTTP/1.1 allows the client to do a
"conditional GET", using one of two forms of "cache validators." In
the traditional form, available in both HTTP/1.0 and in HTTP/1.1, the
client may use the "If-Modified-Since" request-header to present to
the server the "Last-Modified" timestamp (if any) that the server
provided with the response. If the server's timestamp for the
resource has not changed, it may send a response with a status code
of 304 (Not Modified), which does not transmit the body of the
resource. If the timestamp has changed, the server would normally
send a response with a status code of 200 (OK), which carries a
complete copy of the resource, and a new Last-Modified timestamp.
クライアントがキャッシュに応答を有する時で、このキャッシュ項目が原稿の物であると確かめたい時には、 HTTP/1.1 ではクライアントは二つの
「[[キャッシュ検証子]]」の書式の一つを用いて、「[[条件付GET]]」
を行うことができます。 HTTP/1.0 と HTTP/1.1 の双方で利用可能な伝統的書式では、クライアントは、鯖が応答で示した [CODE(HTTP)[[[Last-Modified]]]] 時刻印を (あれば) 示すために [CODE(HTTP)[[[If-Modified-Since]]]] 要求頭を使用することができます。その資源についての鯖の時刻印が変更されていなければ、
資源の[[本体]]は転送しない、 [CODE(HTTP)[[[304]]]] (未修正) [[状態符号]]の応答を送ることができます。時刻印が変更されていれば、鯖は通常のように状態符号 [CODE(HTTP)[[[200]]]] (了解) の応答を送り、資源の完全な複製と新しい [CODE(HTTP)[Last-Modified]] 時刻印を運搬することになります。
> This timestamp-based approach is prone to error because of the lack
of timestamp resolution: if a resource changes twice during one
second, the change might not be detectable. Therefore, HTTP/1.1 also
allows the server to provide an entity tag with a response. An
entity tag is an opaque string, constructed by the server according
to its own needs; the protocol specification imposes a bare minimum
of requirements on entity tags. (In particular, a "strong" entity
tag must change if the value of the resource changes.) In this case,
the client may validate its cache entry by sending its conditional
request using the "If-None-Match" request-header, presenting the
entity tag associated with the cached response. (The protocol
defines several other ways to transmit entity tags, such as the "If-Range" header, used for short-circuiting an otherwise necessary round
trip.) If the presented entity tag matches the server's current tag
for the resource, the server should send a 304 (Not Modified)
response. Otherwise, the server should send a 200 (OK) response,
along with a complete copy of the resource.
この時刻印を基にした手法は、時刻印の解像度の欠如のために誤りを起こす傾向にあります。資源が一秒の間に二度変更されれば、その変更は検出できないかもしれません。このため、 HTTP/1.1 では鯖が応答と共に[[実体札]]を提供することもできます。実体札は不透明な文字列であり、鯖が自身の必要に応じて構築します。
プロトコル仕様は実体札に基本的な最低限の要件を課しています。
(特に、「強い」実体札は資源の値が変更されたら変更しなければなりません。)
この場合、クライアントはキャッシュ項目をキャッシュした資源に関連付けられた実体札を示した [CODE(HTTP)[[[If-None-Match]]]] 要求頭を用いた[[条件付要求]]を送信することによって検証できます。 (HTTP は他にも [CODE(HTTP)[[[If-Range]]]] 頭のような本来必要な往復を短絡するために使用する実体札を転送する方法を定義しています。)
示された実態札が鯖の資源の現在の札に一致すれば、鯖は [CODE(HTTP)[304]]
(未修正) 応答を送信するべきです。そうでなければ、鯖は資源の完全な複製と共に
[CODE(HTTP)[200]] (了解) 応答を送信するべきです。
> In the existing HTTP protocol (HTTP/1.0 or HTTP/1.1), a client
sending a conditional request can expect either of two responses:
既存の HTTP プロトコル (HTTP/1.0 または HTTP/1.1) では、
条件付要求を送信するクライアントは次の二つの応答のいずれかを期待できます。
>
- status = 200 (OK), with a full copy of the resource, because
the server's copy of the resource is presumably different from
the client's cached copy.
- status = 304 (Not Modified), with no body, because the server's
copy of the resource is presumably the same as the client's
cached copy.
- 状態が [CODE(HTTP)[200]] (了解) で、資源の完全な複製付き。
資源の鯖の複製がクライアントのキャッシュした複製とおそらく異なっている。
- 状態が [CODE(HTTP)[304]] (未修正) で、本体なし。
資源の鯖の複製がクライアントのキャッシュした複製とおそらく同じである。
> Informally, one could think of these as "deltas" of 100% and 0% of
the resource, respectively. Note that these deltas are relative to a
specific cached response. That is, a client cannot request a delta
without specifying, somehow, which two instances of a resource are
being differenced. The "new" instance is implicitly the current
instance that the server would return for an unconditional request,
and the "old" instance is the one that is currently in the client's
cache. The cache validator (last-modified time or entity tag) is
what is used to communicate to the server the identity of the old instance.
非公式に、この両者を資源のそれぞれ 100% と 0% の「差分」と考えることができます。これらの差分は特定のキャッシュした応答に対するものであることに注意して下さい。
つまり、クライアントはともかくも資源のどの二つの[[実現値]]が異なっているのかを指定しなければ差分を要求できないのです。
「新しい」実現値は陰に非条件付要求なら鯖が返すであろう現在の実現値であり、
「古い」実現値は現在クライアントのキャッシュにある実現値です。
キャッシュ検証子 (最終修正時刻または実体札)
が古い実現値の識別について鯖と通信するために使用する物です。
** 5.2 Requesting the transmission of deltas
> In order to support the transmission of actual deltas, an extension
to HTTP/1.1 needs to provide these features:
実際の差分の転送に対応するために、 HTTP/1.1 への拡張は次の機能を提供する必要があります。
>
-1. A way to mark a request as conditional.
-2. A way to specify the old instance, to which the delta will be
applied by the client.
-3. A way to indicate that the client is able to apply one or more
specific forms of delta encoding.
-4. A way to mark a response as being delta-encoded in a particular format.
- 要求は[[条件付]]であると印をつける方法
- クライアントが差分を適用する古い実現値を指定する方法
- クライアントが適用することのできる一つ以上の差分符号化の書式を示す方法
- 応答を特定の書式で差分符号化されていると印をつける方法
> The first two features are already provided by HTTP/1.1: the presence
of a conditional request-header (such as "If-Modified-Since" or "If-None-Match") marks a request as conditional, and the value of that
header uniquely specifies the old instance (ignoring the problem of
last-modified timestamp granularity).
最初の二つの機能は既に HTTP/1.1 にあります。
条件的要求頭 ([CODE(HTTP)[[[If-Modified-Since]]]] や
[CODE(HTTP)[[[If-None-Match]]]]) の存在が要求を条件付であると印付けし、
その頭の値が (差異修正時刻印の粒度の問題を無視すれば)
古い実現値を一意に指定します。
> We defer discussion of the fourth feature, until section 5.6.
四番目の機能の議論は5.5節まで先送りします。
> The third feature, a way for the client to indicate that it is able
to apply deltas (aside from the trivial 0% and 100% deltas), can be
accomplished by transmitting a list of acceptable delta-encoding
formats in a request-header field; specifically, the "A-IM" header.
The presence of this list in a conditional request indicates that the
client is able to apply delta-encoded cache updates.
三番目の機能、クライアントが (自明な 0% や 100% の差分以外の) 差分を適用することができると示す方法は、
受入れ可能差分符号化書式の一覧を要求頭欄 [CODE(HTTP)[[[A-IM]]]]
で転送することにより実現できます。
この一覧が条件付き要求に存在することは、クライアントが差分符号化キャッシュ更新を適用することができることを示します。
> For example, a client might send this request:
例えば、クライアントは次のような要求を送信するとします。
>
[PRE[
GET /foo.html HTTP/1.1
Host: bar.example.net
If-None-Match: "123xyz"
A-IM: vcdiff, diffe, gzip
]PRE]
> The meaning of this request is that:
この要求の意味はこうです。
>
- The client wants to obtain the current value of /foo.html.
- It already has a cached response (instance) for that resource,
whose entity tag is "123xyz".
- It is willing to accept delta-encoded updates using either of
two formats, "diffe" (i.e., output from the UNIX "diff -e"
command), and "vcdiff". (Encoding algorithms and formats, such
as "vcdiff", are described in section 6.)
- It is willing to accept responses that have been compressed
using "gzip," whether or not these are delta-encoded. (It
might be useful to compress the output of "diff -e".) However,
based on the mandatory ordering constraint specified in section
10.5.3, if both delta encoding and compression are applied,
then this "A-IM" request header specifies that compression
should be done last.
- クライアントは [CODE(URI)[/foo.html]] の現在値を得たい。
- クライアントは既にこの資源の実体札が [CODE(HTTP)["123xyz"]]
であるキャッシュ応答 (実現値) を有している。
- クライアントは [CODE(HTTP)[[[diffe]]]] (すなわち、 [[UNIX]] [KBD[[[diff]] -e]]
命令の出力) と [CODE(HTTP)[[[vcdiff]]]] ([CODE[vcdiff]] のような符号化算法・書式で、6章に記述されている) の二つの書式のいずれかを用いた差分符号化更新を受入れる意志がある。
- クライアントは差分符号化されていようがいなかろうが、 [CODE(HTTP)[[[gzip]]]] を用いて圧縮された応答を受入れる意志がある。
([CODE[gzip]] は [KBD[diff -e]] の出力を圧縮するのに有用かもしれない。)
しかし、10.5.3節で規定する強制順序付け制約に基づき、差分符号化と圧縮の両方が適用されるのであれば、この [CODE(HTTP)[[[A-IM]]]] 要求頭は圧縮が後から行われれるべきであると指定している。
> If, in this example, the server's current entity tag for the resource
is still "123xyz", then it should simply return a 304 (Not Modified)
response, as would a traditional server.
この例において、鯖のこの資源の現在の実体札が依然 [CODE(HTTP)["123xyz"]]
であれば、単に伝統的鯖のように [CODE(HTTP)[304]] (未修正)
を返すべきです。
> If the entity tag has changed, presumably but not necessarily because
of a modification of the resource, the server could instead compute
the delta between the instance whose entity tag was "123xyz" and the
current instance.
実体札が変更されていれば、資源の修正が絶対ではないにしろおそらくはなされているので、鯖は代わりに実体札が
[CODE["123xyz"]] の実現値と現在の実現値の差分を計算することができます。
> We defer discussion of what the server needs to store, in order to
compute deltas, until section 7.
差分を計算するために鯖が何を蓄積する必要があるのかの議論は7章に先送りします。
> We note that if a client indicates it is willing to accept deltas,
but the server does not support this form of instance-manipulation,
the server will simply ignore this aspect of the request. (HTTP
always allows an implementation to ignore a header that is not
required by a specification that the implementation complies with,
and the specification of "A-IM" allows the server to ignore an
instance-manipulation it does not understand.) So if a server either
does not implement the A-IM header at all, or does not implement any
of the instance manipulations listed in the A-IM header, it acts as
if the client had not requested a delta-encoded response: the server
generates a status-200 response.
クライアントが差分を受入れる意志を示しているものの鯖がその書式の[[実現値操作]]に対応していない時は、鯖は端に要求のその部分を無視することを注記しておきます。
(HTTP は実装が従うことを仕様で要求していない頭を無視することを実装に常に認めており、 [CODE(HTTP)[[[A-IM]]]] の仕様は鯖が理解しない実現値操作を無視することを認めています。)
ですから鯖が [CODE(HTTP)[A-IM]] 頭を全く実装していないか、
または [CODE(HTTP)[A-IM]] 頭に列せられた実現値操作のいずれをも実装していないなら、クライアントが差分符号化応答を要求していない場合のように働きます。
つまり、鯖は状態 [CODE(HTTP)[200]] 応答を生成します。
** 5.3 Choice of delta algorithm and format
> The server is not required to transmit a delta-encoded response. For
example, the result might be larger than the current size of the
resource. The server might not be able to compute a delta for this
type of resource (e.g., a compressed binary format); the server might
not have sufficient CPU cycles for the delta computation; the server
might not support any of the delta formats supported by the client;
or, the network bandwidth might be high enough that the delay
involved in computing the delta is not worth the delay avoided by
sending a smaller response.
鯖は必ずしも差分符号化応答を転送する必要はありません。
例えば、結果が資源の現在の寸法より大きくなるかもしれません。
鯖はこの型の資源 (例えば圧縮されたバイナリ書式) の差分を計算することができないかもしれません。
鯖は差分計算のための十分な CPU 周期を有しないかもしれません。
鯖はクライアントが対応する差分書式のいずれにも対応していないかもしれません。
ネットワーク帯域が十分広いので差分を計算することによる遅延に小さ目の応答を送信することによって回避される遅延分の価値がないかもしれません。
> However, if the server does want to compute a delta, and the set of
encodings it supports has more than one encoding in common with the
set offered by the client, which encoding should it use? This is
mostly at the option of the server, although the client can express
preferences using "Quality Values" (or "qvalues") in the "A-IM"
header. The HTTP/1.1 specification [10] describes qvalues in more
detail. (Clients may prefer one delta encoding format over another
that generates a smaller encoding, if the decoding costs for the
first format are lower and the client is resource-constrained.)
しかし、鯖が差分を計算したいと思っており、その対応している符号化の集合とクライアントの提案する集合と複数個共通した符号化があるなら、
どの符号化を使用するべきでしょうか。これはほとんど鯖の選択するところであります。ただしクライアントは希望を [CODE(HTTP)[[[A-IM]]]]
頭中の「[[品質値]]」 ([CODE(ABNF)[[[qvalue]]]]) を使って表現できます。
HTTP/1.1 仕様書は [CODE(ABNF)[qvalue]] をより詳しく記述しています。
(クライアントは、そちらの方が復号経費が小さくて、クライアントに資源の上で制約があるなら、小さな符号化を生成する符号化よりも差分符号化を希望するかもしれません。)
> Server implementations have a number of possible approaches. For
example, if CPU cycles are plentiful and network bandwidth is scarce,
the server might compute each of the possible encodings and then send
the smallest result. Or the server might use heuristics to choose an
encoding format, based on things such as the content-type of the
resource, the current size of the resource, and the expected amount
of change between instances of the resource.
鯖実装は数々の可能な手法を有します。例えば、 CPU 周期が豊富でネットワーク帯域が乏しいなら、鯖は可能な符号化をそれぞれ計算して最小の結果を送信するかもしれません。
あるいは鯖が符号化書式を選ぶに当たって資源の内容型や資源の現在の寸法や資源の実現値間の変更の想定量などの点を基にして発見的方法を使用するかもしれません。
> Note that it might pay to cache the deltas internally to the server,
if a resource is typically requested by several different delta-capable clients between modifications. In this case, the cost of
computing a delta may be amortized over many responses, and so the
server might use a more expensive computation.
資源が典型的に幾つもの異なる修正間の差分能力のあるクライアントから要求を受けるのであれば、
鯖に内部的に差分をキャッシュするために支払うかもしれないことに注意して下さい。
この場合、差分を計算する経費は多くの応答に分割されて、
鯖はより高価な計算を行なうことになるかもしれません。
** 5.4 Identification of delta-encoded responses
> A response using delta encoding must be identified as such. This is
done using the "IM" response-header, specified in section 10.5.2.
差分符号化を用いた応答はそのように識別されなければなりません。
これは10.5.2節で規定する、 [CODE(HTTP)[[[IM]]]]
応答頭を使用して行います。
> However, a simplistic application of this approach would cause
serious problems if a delta-encoded response flows through an
intermediate (proxy) cache that is not cognizant of the delta
mechanism. Because the Internet still includes a significant number
of HTTP/1.0 caches, which might never be entirely replaced, and
because the HTTP specifications insist that message recipients ignore
any header field that they do not understand, a non-delta-capable
proxy cache that receives a delta-encoded response might store that
response, and might later return it to a non-delta-capable client
that has made a request for the same resource. This naive client
would believe that it has received a valid copy of the entire
resource, with predictably unpleasant results.
しかし、この手法の安易な応用は、差分符号化応答が差分機構を認識しない中間
(串) キャッシュを流通する時に重大な問題を引き起こしかねません。
インターネットは依然として多大な数の HTTP/1.0
キャッシュを含んでいまして、それらはまったく置きかえられることがありませんし、 HTTP 仕様書はメッセージ受信者が理解しない頭欄は無視せよと主張していますから、差分能力の無い串キャッシュが差分符号化応答を受け取ったらこれを蓄積し、同じ資源に後から要求を行った差分能力の無いクライアントにこれを返すことになるやもしれません。この無邪気なクライアントは資源全体の妥当な複製を受信したと信じて、予想通り好ましくない結果となるでしょう。
> To solve this problem, we propose that delta-encoded responses
(actually, all instance-manipulated responses) be identified as such
using a new HTTP status code. For specificity in the discussion that
follows, we will use the (currently unassigned) code of 226, with a
reason phrase of "IM Used". (We see no benefit in spelling out the
words "Instance Manipulation Used," since this requires the
transmission of unnecessary bytes, and this Reason-phrase should not
normally be seen by human users.) There is some precedent for this
approach: the HTTP/1.1 specification introduces the 206 (Partial
Content) status code, for the transmission of sub-ranges of a
resource. Existing proxies apparently forward responses with unknown
status codes, and do not attempt to cache them.
この問題を解決するために、差分符号化応答
(実際には、すべての実現値操作応答) は新しい HTTP [[状態符号]]を使って識別することを提案します。後の議論にあるように、
(現在割り当てられていない) 符号 [CODE(HTTP)[[[236]]]]
を、理由語句 [CODE(HTTP)[IM Used]] ([ABBR[IM]] 使用中)
と共に使用します。 ([CODE[Instance Manipulation Used]] と綴っても、
不要なバイトの転送が必要で、この [CODE(ABNF)[Reason-phrase]]
は通常人間利用者が見るべきではないので、特に利益にはなりません。)
この方法には先例がありまして、 HTTP/1.1 仕様書は資源の部分範囲の転送のために [CODE(HTTP)[[[206]]]] (部分内容) 状態符号を導入しています。
既存の串は未知の状態符号を転送するようで、
これらをキャッシュしようとしません。
> An alternative to using a new status code would be to use the
"Expires" header to prevent HTTP/1.0 caches from storing the
response, then use "Cache-Control: max-age" (defined in HTTP/1.1) to
allow more modern caches to store delta-encoded responses. This adds
many bytes to the response headers, and so would reduce the
effectiveness of delta encoding. It is also not entirely clear that
this approach suppresses all caching by all HTTP/1.0 proxies.
新しい状態符号を使うのではない別の方法は、
HTTP/1.0 キャッシュが蓄積するのを防ぐために [CODE(HTTP)[[[Expires]]]]
頭を使用し、より現代的なキャッシュが差分符号化応答を蓄積することを認めるために (HTTP/1.1 で定義された) [CODE(HTTP)[[[Cache-Control: [[max-age]]]]
を使用する方法です。これは応答頭に多くのバイトを追加しますから、
差分符号化の効率性を削減してしまいます。
また、この方法がすべての HTTP/1.0 串によるすべてのキャッシュ付けを抑制するのかはまったく不明です。
> We were reluctant to define an additional status code as part of
the support for delta encoding. However, we see no other
efficient way to remain compatible with the deployed base of
HTTP/1.0 cache implementations.
差分符号化への対応の一部として追加の状態符号を定義することは気が進みませんでした。しかし、現在運用中の HTTP/1.0 キャッシュ実装と互換性を保つ効率のよい他の手段は見つかっていません。
** 5.5 Guaranteeing cache safety
> Although we are not aware of any HTTP/1.1 proxy implementations that
would attempt to cache a response with an unknown 2xx status code,
the HTTP/1.1 specification does allow this behavior if the response
carries an Expires or Cache-Control header field that explicitly
allows caching. This would present a problem when a 226 (IM Used)
response carries such headers.
未知の [CODE(HTTP)[[[2[VAR[xx]]]]]] 状態符号の応答をキャッシュ使用とする
HTTP/1.1 串実装は知られていませんが、 HTTP/1.1 仕様書は
[CODE(HTTP)[[[Expires]]]] 頭欄や [CODE(HTTP)[[[Cache-Control]]]]
頭欄が陽にキャッシュ付けを認めているのならこの動作を認めています。
これは [CODE(HTTP)[226]] ([ABBR[IM]] 使用中)
応答がこれらの頭を運ぶ時に問題を招きます。
> The solution in that case is to exploit the Cache Control Extensions
mechanism from the HTTP/1.1 specification. We define a new cache-directive, "im", which indicates that the "no-store" cache-directive
may be ignored by implementations that conform to the specification
for the IM and A-IM headers.
この場合の解決策として、 HTTP/1.1 仕様書のキャッシュ制御拡張機構を利用します。
[CODE(HTTP)[[[IM]]]] 頭と [CODE(HTTP)[[[A-IM]]]]
頭の仕様書に適合する実装が [CODE(HTTP)[[[no-store]]]] キャッシュ指令を無視してもよいことを示す新しい [CODE(HTTP)[[[im]]]] キャッシュ指令を定義します。
> For example, this response:
例えば、次の応答
>
[PRE[
HTTP/1.1 226 IM Used
ETag: "489uhw"
IM: vcdiff
Date: Tue, 25 Nov 1997 18:30:05 GMT
Cache-Control: no-store, im, max-age=30
...
]PRE]
> "MUST NOT" be stored by a cache that complies with the HTTP/1.1
specification (which states that the max-age cache-directive "implies
that the response is cacheable [...] unless some other, more
restrictive cache directive is also present."). However, a cache
that does comply with the specification for the im cache-directive
(i.e., a cache that complies with the specification for the A-IM and
IM header fields, and the 226 status code) ignores the no-store
directive, and therefore sees the max-age directive as allowing caching.
は HTTP/1.1 仕様書に従うキャッシュは蓄積「'''してはなりません'''」
(HTTP/1.1 仕様書では [CODE(HTTP)[[[max-age]]]] 指令が[Q[応答は、他のより制限的なキャッシュ指令も示されていない限り、[[キャッシュ可能]]であることを暗示し、[INS[(略)]]。]]と述べています)。
しかし、 [CODE(HTTP)[[[im]]]] キャッシュ指令の仕様に従うキャッシュ
(すなわち、 [CODE(HTTP)[[[A-IM]]]] 頭欄と [CODE(HTTP)[[[A-IM]]]] 頭欄と [CODE(HTTP)[[[226]]]] [[状態符号]]の仕様に適合するキャッシュ)
は [CODE(HTTP)[no-store]] 指令を無視しますから、従って
[CODE(HTTP)[max-age]] 指令をキャッシュ付けを認める物として見ます。
> We are not entirely sure that all HTTP/1.1 caches obey the rule
that the max-age directive is overridden by the no-store
directive. If operational testing reveals this to be a problem,
more elaborate solutions are possible.
すべての HTTP/1.1 キャッシュが [CODE(HTTP)[no-store]]
指令で [CODE(HTTP)[max-age]] 指令が上書きされるという規則に従っているのかは完全には確かめられていません。
運用上の検査でこれが問題であると分かれば、より緻密な解決が可能です。
> Warning to origin server implementors: it does not suffice to send
起源鯖実装者へ警告。状態 [CODE(HTTP)[226]] 応答で
>
[PRE[
Vary: If-None-Match, A-IM
]PRE]
in status-226 responses. We have discovered at least one scenario
where this does not prevent a proxy cache that does not implement IM
and A-IM from incorrectly "validating" a cached 226 response.
を送信するだけでは十分ではありません。最低一つの情景ではキャッシュした
[CODE(HTTP)[226]] 応答を不正に「検証」する
[CODE(HTTP)[IM]] と [CODE(HTTP)[A-IM]] を実装していない串キャッシュから防ぐことができないことを発見しています。
** 5.6 Transmission of delta-encoded responses
> A delta-encoded response differs from a standard response in four ways:
差分符号化応答は標準応答と4つの点で異なります。
>
-1. It carries a status code of 226 (IM Used).
-2. It carries an "IM" response-header field, indicating which
delta encoding is used in this response.
-3. Its message-body is a delta encoding of the current instance,
rather than a full copy of the instance.
-4. It might carry several other new headers, as described later in
this document.
- [[状態符号]] [CODE(HTTP)[[[226]]]] ([ABBR[IM]] 使用中) を運搬する。
- この応答に差分符号化が使用されていることを示す
[CODE(HTTP)[[[IM]]]] [[応答頭欄]]を運搬する。
- [CODE(ABNF)[[[message-body]]]] は[[現在実現値]]の完全な複製ではなく、
現在実現値の差分符号化である。
- この文書の後で記述するほかの幾つかの新しい頭を運搬するかもしれない。
> For example, a response to the request given in section 5.2 might
look like:
例えば、5.2節に与えた要求に対する応答は次のようになるかもしれません。
>
[PRE[
HTTP/1.1 226 IM Used
ETag: "489uhw"
IM: vcdiff
Date: Tue, 25 Nov 1997 18:30:05 GMT
...
]PRE]
> (We do not show the actual contents of the response body, since this
is a binary format.)
([[応答本体]]の実際の内容は、バイナリ書式になりますから、示しません。)
> Note: the Etag header in a 226 response with a delta encoding
provides the entity tag of the current instance of the resource
variant. It is not meaningful to associate an entity tag with the
delta value, which is not an instance.
注意: 差分符号化の [CODE(HTTP)[[[226]]]] 応答の [CODE(HTTP)[Etag]]
頭は資源[[変体]]の現在実現値の[[実体札]]を提供します。
差分値は実現値ではなく、これと実体札を関連付けることには意味がありません。
** 5.7 Examples of requests combining Range and delta encoding
> In the example used in section 5.2, the client sends:
5.2 節で使用した例で、クライアントは
>
[PRE[
GET /foo.html HTTP/1.1
Host: bar.example.net
If-None-Match: "123xyz"
A-IM: vcdiff, diffe, gzip
]PRE]
and the server either responds with a 304 (Not Modified) response, or
with the appropriate delta encoding.
と送信し、鯖は [CODE(HTTP)[[[304]]]] (未修正) 応答で応答するか、
または適切な差分符号化で応答します。
> Here are a few more examples, to clarify how the client request
should be interpreted.
ここに、クライアントの要求をどう解釈するべきかを説明する例をもう少し示します。
> If the client sends
クライアントが