2004/id/draft-ietf-http-req-sum-00.txt



HTTP Working Group                                      J. Mogul, DECWRL
Internet-Draft                                         12 September 1997
Expires: 28 March 1998


          Format and Example of HTTP/1.1 Requirements Summary

                     draft-ietf-http-req-sum-00.txt


STATUS OF THIS MEMO

        This document is an Internet-Draft. Internet-Drafts are
        working documents of the Internet Engineering Task Force
        (IETF), its areas, and its working groups. Note that other
        groups may also distribute working documents as
        Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of
        six months and may be updated, replaced, or obsoleted by
        other documents at any time. It is inappropriate to use
        Internet-Drafts as reference material or to cite them other
        than as "work in progress."

        To learn the current status of any Internet-Draft, please
        check the "1id-abstracts.txt" listing contained in the
        Internet-Drafts Shadow Directories on ftp.is.co.za
        (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
        Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
        West Coast).

        Distribution of this document is unlimited.  Please send
        comments to the HTTP working group at
        <http-wg@cuckoo.hpl.hp.com>.  Discussions of the working
        group are archived at
        <URL:http://www.ics.uci.edu/pub/ietf/http/>.  General
        discussions about HTTP and the applications which use HTTP
        should take place on the <www-talk@w3.org> mailing list.


ABSTRACT

        RFC1122 [1] introduced a ``Requirements Summary'' format,
        to help implementors understand what aspects of a lengthy
        specification were mandatory, recommended, or optional.
        The HTTP/1.1 specification is similarly lengthy and
        complicated; many implementors have asked for guidance in
        understanding what they need to do.  The latest draft
        revision of the HTTP/1.1 specification [2] has a
        placeholder section for a ``Requirements Summary'', but
        there has been relatively little discussion of the format
        and content of this summary in the HTTP working group.
        This document proposes a specific format for the summary,
        and gives an example summary for one section of the
        document.
Mogul                                                           [Page 1]

Internet-Draft         HTTP requirements summary 12 September 1997 17:27


                           TABLE OF CONTENTS

1 Introduction                                                         2
2 Categorizing implementations                                         2
     2.1 Introductory material for Requirements Summary                3
3 DRAFT Requirements summary for Section 13: Caching                   4
4 Security Considerations                                              7
5 Acknowledgments                                                      7
6 References                                                           7
7 Author's address                                                     7


1 Introduction

   RFC1122 [1] introduced a ``Requirements Summary'' format, to help
   implementors understand what aspects of a lengthy specification were
   mandatory, recommended, or optional.  The HTTP/1.1 specification is
   similarly lengthy and complicated; many implementors have asked for
   guidance in understanding what they need to do.  This is especially
   important because there are several kinds of HTTP/1.1 implementations
   (including server, proxy, and client, with or without caches).  Many
   aspects of the specification apply only to a subset of these
   implementation categories, which means that someone implementing,
   say, an HTTP client must disentangle the client-specific requirements
   from the (client-irrrelevant) requirements for servers and proxies.

   The latest draft revision of the HTTP/1.1 specification [2] has a
   placeholder section for a ``Requirements Summary'' (section 19.9).
   but there has been relatively little discussion of the format and
   content of this summary in the HTTP working group.  What little
   discussion has taken place has been mostly positive, but there are
   some concerns about how the implementations are categorized.

   This document proposes a specific format for the summary, and gives
   an example summary for one section of the document.


2 Categorizing implementations

   We would like to design the format of the Requirements Summary so
   that it is readable even in the plain-ASCII version of the HTTP/1.1
   specification, since this is the ``official'' version of an IETF
   specification.  This places some constraints on the number of columns
   in the format, which in turn constrains the number of categories that
   can be comfortably included.

   Although at first glance, there might appear to be at least six
   different implementation categories (server, proxy, client, each with
   or without a cache).  However, in many sections of the HTTP
   specification, caching is irrelevant.  For many other features, it is
   fairly obvious whether the feature applies to a cache or not.

Mogul                                                           [Page 2]

Internet-Draft         HTTP requirements summary 12 September 1997 17:27


   Therefore, we propose a format where the applicability of a
   requirement to an caching implementation is signalled by a footnote,
   rather than expanding the number of columns to six.

   One possible implementation of this format would be as a spreadsheet,
   using a portable representation (such as ``comma separated values'').
   The use of a spreadsheet would allow separate editing of the
   requirements summary, followed by semi-automatic insertion into the
   master copy of the HTTP/1.1 specification.  It might also allow
   semi-automatic extraction of subset requirements application to
   specific kinds of implementations.

2.1 Introductory material for Requirements Summary
   [This is repeated more or less verbatim from section 19.9 of [2], for
   the benefit of the reader.]

   This section summarizes the requirements of the HTTP/1.1
   specification.  (Requirements are those aspects of the protocol
   defined with the words "MUST", "SHOULD", or "MAY.")

   This list is not a normative part of the HTTP/1.1 specification, and
   if there is any conflict between this listing and another part of the
   specification, the statements elsewhere in the specification take
   absolute priority.

   Requirements are listed in the order that they appear in the the
   specification.  For each requirement, the list includes

      - a very brief summary of the feature; this is meant for
        identification purposes only, and must not be used as a
        specification of the feature.

      - the section of the document in which the feature is
        specified.

      - A column for each of three categories of implementation
        (Server, Proxy, and Client), showing whether the listed
        feature is a MUST, SHOULD, or MAY requirement.

      - A column for additional footnotes Note that some aspects of
        the protocol may be specified in multiple sections in
        separated part of the document.

   In order to fit into the standard IETF format for ASCII text
   documents, some of the column headings, and the requirement keywords,
   are abbreviated.

   [End of extract from [2].]

   Key for column headings:
     Srvr =  Server

Mogul                                                           [Page 3]

Internet-Draft         HTTP requirements summary 12 September 1997 17:27


     Prox =  Proxy
     Clnt =  Client

   Key for requirements keywords:
      M =    MUST
      MN =   MUST NOT
      S =    SHOULD
      SN =   SHOULD NOT
      ok =   MAY
      na =   Not applicable

   Some entries are listed as ``MUST NOT'' or ``SHOULD NOT'' even if the
   feature summary seems to indicate a ``MUST'' or ``SHOULD''.  The
   entries reflect the words from the actual spec, rather than the
   feature summary.  I.e., the feature summary wording is only to help
   the reader find the appropriate passage; it is in no way a definitive
   description of the requirement!


3 DRAFT Requirements summary for Section 13: Caching

      The following table has NOT been carefully proofread; it
      probably contains errors.  Please do not base an implementation
      on this version of the summary!

      There is at least one bogus entry that has been inserted into
      the following table, to encourage careful proofreading.

   For section 13 (Caching), almost all of the requirements that apply
   to proxies apply only to caching proxies.  A few requirements do also
   apply to non-caching proxies; this is noted where applicable.

   Notes:
     1   Cache rule applies to client-local caches as well as proxy
         caches.

     2   Rule applies to non-caching proxies.

     98  No explicit upper-case conformance requirement stated in [2],
         perhaps not actually a conformance requirement.

     99  No explicit upper-case conformance requirement stated in [2]

   Feature summary                         Section Srvr Prox Clnt Note
   ===============                         ======= ==== ==== ==== ====

   Meets cache correctness rules 1-3       13.1.1   na   M    M   1
   If server unreachable, follow rules 1-3 13.1.1   na   S    S   1
    ditto, or return error/warning         13.1.1   na   M    M   1
   Forward initially-stale response        13.1.1   na   S    S   1, 2
   Don't revalidate initially-stale resp   13.1.1   na   SN   SN  1

Mogul                                                           [Page 4]

Internet-Draft         HTTP requirements summary 12 September 1997 17:27


   Display warning on received-stale resp  13.1.1   na   na   ok

   Delete MUST-delete warning after reval  13.1.2   na   M    M   1
   Keep MUST-keep warning after reval      13.1.2   na   M    M   1

   Attach Warning to stale response        13.1.5   na   M    na
   Obey client request for freshness       13.1.5   na   S    na

   Revalidate init-stale cached response   13.2.1   na   S    S   1

   Comply with Age calculation algorithm   13.2.3   na   M    M   1,2,99
   Interpret Age rel. to initiation time   13.2.3   na   M    M   1

   max-age overrules Expires               13.2.4   na   M    M   1, 99
   Use heuristic if no Expires or max-age  13.2.4   na   ok   ok  1
   Warn if heuristic & Age > 24 hours      13.2.4   na   M    M   1, 99
   Base heuristic on Last-Mod time         13.2.4   na   S    S   1
   Freshness test based on age             13.2.4   na   M    M   1, 99

   Ignore new response with older Date     13.2.5   na   ok   ok  1
   Use response with most recent Date      13.2.5   na   M    M   1
   Re-revalidate when new resp seems old   13.2.6   na   S    S   1
   Don't expect disambiguation for = Dates 13.2.6   MN   na   na

   Weak comparison for non-subrange reqs   13.3.3   ok   ok   na
   Strong comparison for subrange/non-GET  13.3.3   M    M    na
   Last-modified implicitly weak           13.3.3   M    M    M   99

   Strong etag changes always              13.3.4   M    na   na
   Weak etag changes when 'significant'    13.3.4   S    na   na
   Use etag in conditionals, if available  13.3.4   na   M    M
   Use Last-Modified, if avail & no etag   13.3.4   na   S    S
    ditto, with subrange reqs              13.3.4   na   ok   ok
   Disable use of Last-Mod w/subranges     13.3.4   na   na   S   99
   Use both Last-Mod & etag, if avail      13.3.4   na   S    S
   Use most restrictive validator          13.3.4   na   M    M   1

   Validate only w/etag or Last-Modified   13.3.5   M    M    M   98

   Responses normally cachable             13.4     na   ok   ok  99
   HTTP/1.0 responses not cachable         13.4     na   MN   MN  1
   No validator/expires/max-age ->no cache 13.4     na   S    S   99
    ditto unless unusual situation         13.4     na   ok   ok  99
   Cachable status codes are
    200, 203, 206, 300, 301, 410           13.4     na   ok   ok  99
   Cache 206 only if ranges supported      13.4     na   MN   MN  1
   Other status codes w/out explict perm   13.4     na   MN   MN  1

   Don't add or modify Content-Location,
     Content-MD5, or Etag                  13.5.2   na   MN   na  2
   Don't modify Expires, Content-Length    13.5.2   na   MN   na  2

Mogul                                                           [Page 5]

Internet-Draft         HTTP requirements summary 12 September 1997 17:27


   Added Expires = Date                    13.5.2   na   M    M   2
   Added Content-Length is accurate        13.5.2   na   M    na  2
   If no-transform, don't add
    Content-Encoding, Content-Length,
    Content-Range, Content-Type            13.5.2   na   MN   na  2
   Add Warning if adding
    Content-Encoding, Content-Length,
    Content-Range, Content-Type            13.5.2   na   M    na  2

   Combine partial resps                   13.5.3   na   ok   ok  1
   Delete 1XX Warnings on revalidate       13.5.3   na   M    M   1
   Keep 2XX Warnings on revalidate         13.5.3   na   M    M   1
   304/206 hdrs update cache entry         13.5.3   na   M    M   1
   End-to-end hdrs update cache entry      13.5.3   na   M    M   1

   Combined subranges: validators match    13.5.4   na   M    M   1
   Combined subranges: strong validators   13.5.4   na   M    M   1
   Otherwise: use most recent partial resp 13.5.4   na   M    M   1, 99

   Use Vary to list selecting req hdrs     13.6     M    na   na
   New req hdrs match Vary on cache use    13.6     na   M    M   1
   Forward non-matching requests           13.6     na   M    M   1
   Forwarded req conditional if have Etag  13.6     na   S    S   1
   Resp updates entry if tags match        13.6     na   S    S   1
   Forward new response                    13.6     na   M    na
   Vary * means forward new reqs           13.6     na   MN   MN  1
   Omit Etag on conditional req and
    partial cache entry                    13.6     na   SN   SN  1
   Delete entry if URI matches
    Content-Location on newer resp and
    Etags don't match                      13.6     na   SN   SN  1

   Provide security for non-shared caches  13.7     S    S    S   1

   Store incomplete response               13.8     na   ok   ok  1, 99
   Incomplete resp. is partial             13.8     na   M    M   1
   Mark all partial resps. as such         13.8     na   M    M   1
   Don't use 200 with partial resp.        13.8     na   MN   MN  1
   Forward 5xx response                    13.8     na   ok   na  2
   Treat 5xx like dead server              13.8     na   ok   na

   GET/HEAD: no side effects               13.9     SN   na   na

   PUT,DELETE,POST invalidate entries      13.10    na   S    S   98
   Match host if invalidating by URI       13.10    na   M    M   1

   Write-through all updates               13.11    na   M    M   1

   Use latest response                     13.12    na   S    S   1

   History not transparent                 13.13    na   na   SN

Mogul                                                           [Page 6]

Internet-Draft         HTTP requirements summary 12 September 1997 17:27


   Expires no effect on history            13.13    na   na   ok  98
   History can indicate staleness          13.13    na   na   ok  98


4 Security Considerations

   This document only summarizes the specification in [2], it does not
   introduce any new features to HTTP.  Therefore, there are no security
   considerations particular to the requirements summary itself.


5 Acknowledgments

   T.B.S.


6 References

   1.  R. Braden.  Requirements for Internet Hosts -- Communication
   Layers.  RFC 1122, Internet Engineering Task Force, October, 1989.

   2.  Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee.
   Hypertext Transfer Protocol -- HTTP/1.1.  Internet-Draft
   draft-ietf-http-v11-spec-08.txt, HTTP Working Group, September?,
   1997. [As of this writing, this document has not been assigned an
   actual Internet-Draft name/number; however, it is available on the
   Web at
   www.ics.uci.edu/pub/ietf/http/draft-ietf-http-v11-spec-08.txt.gz and
   is widely known as ``draft-08''].


7 Author's address

   Jeffrey C. Mogul
   Western Research Laboratory
   Digital Equipment Corporation
   250 University Avenue
   Palo Alto, California, 94305, USA
   Email: mogul@wrl.dec.com


Mogul                                                           [Page 7]
1
2
3	HTTP Working Group J. Mogul, DECWRL
4	Internet-Draft 12 September 1997
5	Expires: 28 March 1998
6
7
8	Format and Example of HTTP/1.1 Requirements Summary
9
10	draft-ietf-http-req-sum-00.txt
11
12
13	STATUS OF THIS MEMO
14
15	This document is an Internet-Draft. Internet-Drafts are
16	working documents of the Internet Engineering Task Force
17	(IETF), its areas, and its working groups. Note that other
18	groups may also distribute working documents as
19	Internet-Drafts.
20
21	Internet-Drafts are draft documents valid for a maximum of
22	six months and may be updated, replaced, or obsoleted by
23	other documents at any time. It is inappropriate to use
24	Internet-Drafts as reference material or to cite them other
25	than as "work in progress."
26
27	To learn the current status of any Internet-Draft, please
28	check the "1id-abstracts.txt" listing contained in the
29	Internet-Drafts Shadow Directories on ftp.is.co.za
30	(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
31	Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
32	West Coast).
33
34	Distribution of this document is unlimited. Please send
35	comments to the HTTP working group at
36	<http-wg@cuckoo.hpl.hp.com>. Discussions of the working
37	group are archived at
38	<URL:http://www.ics.uci.edu/pub/ietf/http/>. General
39	discussions about HTTP and the applications which use HTTP
40	should take place on the <www-talk@w3.org> mailing list.
41
42
43	ABSTRACT
44
45	RFC1122 [1] introduced a ``Requirements Summary'' format,
46	to help implementors understand what aspects of a lengthy
47	specification were mandatory, recommended, or optional.
48	The HTTP/1.1 specification is similarly lengthy and
49	complicated; many implementors have asked for guidance in
50	understanding what they need to do. The latest draft
51	revision of the HTTP/1.1 specification [2] has a
52	placeholder section for a ``Requirements Summary'', but
53	there has been relatively little discussion of the format
54	and content of this summary in the HTTP working group.
55	This document proposes a specific format for the summary,
56	and gives an example summary for one section of the
57	document.
58	Mogul [Page 1]
59
60	Internet-Draft HTTP requirements summary 12 September 1997 17:27
61
62
63	TABLE OF CONTENTS
64
65	1 Introduction 2
66	2 Categorizing implementations 2
67	2.1 Introductory material for Requirements Summary 3
68	3 DRAFT Requirements summary for Section 13: Caching 4
69	4 Security Considerations 7
70	5 Acknowledgments 7
71	6 References 7
72	7 Author's address 7
73
74
75	1 Introduction
76
77	RFC1122 [1] introduced a ``Requirements Summary'' format, to help
78	implementors understand what aspects of a lengthy specification were
79	mandatory, recommended, or optional. The HTTP/1.1 specification is
80	similarly lengthy and complicated; many implementors have asked for
81	guidance in understanding what they need to do. This is especially
82	important because there are several kinds of HTTP/1.1 implementations
83	(including server, proxy, and client, with or without caches). Many
84	aspects of the specification apply only to a subset of these
85	implementation categories, which means that someone implementing,
86	say, an HTTP client must disentangle the client-specific requirements
87	from the (client-irrrelevant) requirements for servers and proxies.
88
89	The latest draft revision of the HTTP/1.1 specification [2] has a
90	placeholder section for a ``Requirements Summary'' (section 19.9).
91	but there has been relatively little discussion of the format and
92	content of this summary in the HTTP working group. What little
93	discussion has taken place has been mostly positive, but there are
94	some concerns about how the implementations are categorized.
95
96	This document proposes a specific format for the summary, and gives
97	an example summary for one section of the document.
98
99
100	2 Categorizing implementations
101
102	We would like to design the format of the Requirements Summary so
103	that it is readable even in the plain-ASCII version of the HTTP/1.1
104	specification, since this is the ``official'' version of an IETF
105	specification. This places some constraints on the number of columns
106	in the format, which in turn constrains the number of categories that
107	can be comfortably included.
108
109	Although at first glance, there might appear to be at least six
110	different implementation categories (server, proxy, client, each with
111	or without a cache). However, in many sections of the HTTP
112	specification, caching is irrelevant. For many other features, it is
113	fairly obvious whether the feature applies to a cache or not.
114
115	Mogul [Page 2]
116
117	Internet-Draft HTTP requirements summary 12 September 1997 17:27
118
119
120	Therefore, we propose a format where the applicability of a
121	requirement to an caching implementation is signalled by a footnote,
122	rather than expanding the number of columns to six.
123
124	One possible implementation of this format would be as a spreadsheet,
125	using a portable representation (such as ``comma separated values'').
126	The use of a spreadsheet would allow separate editing of the
127	requirements summary, followed by semi-automatic insertion into the
128	master copy of the HTTP/1.1 specification. It might also allow
129	semi-automatic extraction of subset requirements application to
130	specific kinds of implementations.
131
132	2.1 Introductory material for Requirements Summary
133	[This is repeated more or less verbatim from section 19.9 of [2], for
134	the benefit of the reader.]
135
136	This section summarizes the requirements of the HTTP/1.1
137	specification. (Requirements are those aspects of the protocol
138	defined with the words "MUST", "SHOULD", or "MAY.")
139
140	This list is not a normative part of the HTTP/1.1 specification, and
141	if there is any conflict between this listing and another part of the
142	specification, the statements elsewhere in the specification take
143	absolute priority.
144
145	Requirements are listed in the order that they appear in the the
146	specification. For each requirement, the list includes
147
148	- a very brief summary of the feature; this is meant for
149	identification purposes only, and must not be used as a
150	specification of the feature.
151
152	- the section of the document in which the feature is
153	specified.
154
155	- A column for each of three categories of implementation
156	(Server, Proxy, and Client), showing whether the listed
157	feature is a MUST, SHOULD, or MAY requirement.
158
159	- A column for additional footnotes Note that some aspects of
160	the protocol may be specified in multiple sections in
161	separated part of the document.
162
163	In order to fit into the standard IETF format for ASCII text
164	documents, some of the column headings, and the requirement keywords,
165	are abbreviated.
166
167	[End of extract from [2].]
168
169	Key for column headings:
170	Srvr = Server
171
172	Mogul [Page 3]
173
174	Internet-Draft HTTP requirements summary 12 September 1997 17:27
175
176
177	Prox = Proxy
178	Clnt = Client
179
180	Key for requirements keywords:
181	M = MUST
182	MN = MUST NOT
183	S = SHOULD
184	SN = SHOULD NOT
185	ok = MAY
186	na = Not applicable
187
188	Some entries are listed as ``MUST NOT'' or ``SHOULD NOT'' even if the
189	feature summary seems to indicate a ``MUST'' or ``SHOULD''. The
190	entries reflect the words from the actual spec, rather than the
191	feature summary. I.e., the feature summary wording is only to help
192	the reader find the appropriate passage; it is in no way a definitive
193	description of the requirement!
194
195
196	3 DRAFT Requirements summary for Section 13: Caching
197
198	The following table has NOT been carefully proofread; it
199	probably contains errors. Please do not base an implementation
200	on this version of the summary!
201
202	There is at least one bogus entry that has been inserted into
203	the following table, to encourage careful proofreading.
204
205	For section 13 (Caching), almost all of the requirements that apply
206	to proxies apply only to caching proxies. A few requirements do also
207	apply to non-caching proxies; this is noted where applicable.
208
209	Notes:
210	1 Cache rule applies to client-local caches as well as proxy
211	caches.
212
213	2 Rule applies to non-caching proxies.
214
215	98 No explicit upper-case conformance requirement stated in [2],
216	perhaps not actually a conformance requirement.
217
218	99 No explicit upper-case conformance requirement stated in [2]
219
220	Feature summary Section Srvr Prox Clnt Note
221	=============== ======= ==== ==== ==== ====
222
223	Meets cache correctness rules 1-3 13.1.1 na M M 1
224	If server unreachable, follow rules 1-3 13.1.1 na S S 1
225	ditto, or return error/warning 13.1.1 na M M 1
226	Forward initially-stale response 13.1.1 na S S 1, 2
227	Don't revalidate initially-stale resp 13.1.1 na SN SN 1
228
229	Mogul [Page 4]
230
231	Internet-Draft HTTP requirements summary 12 September 1997 17:27
232
233
234	Display warning on received-stale resp 13.1.1 na na ok
235
236	Delete MUST-delete warning after reval 13.1.2 na M M 1
237	Keep MUST-keep warning after reval 13.1.2 na M M 1
238
239	Attach Warning to stale response 13.1.5 na M na
240	Obey client request for freshness 13.1.5 na S na
241
242	Revalidate init-stale cached response 13.2.1 na S S 1
243
244	Comply with Age calculation algorithm 13.2.3 na M M 1,2,99
245	Interpret Age rel. to initiation time 13.2.3 na M M 1
246
247	max-age overrules Expires 13.2.4 na M M 1, 99
248	Use heuristic if no Expires or max-age 13.2.4 na ok ok 1
249	Warn if heuristic & Age > 24 hours 13.2.4 na M M 1, 99
250	Base heuristic on Last-Mod time 13.2.4 na S S 1
251	Freshness test based on age 13.2.4 na M M 1, 99
252
253	Ignore new response with older Date 13.2.5 na ok ok 1
254	Use response with most recent Date 13.2.5 na M M 1
255	Re-revalidate when new resp seems old 13.2.6 na S S 1
256	Don't expect disambiguation for = Dates 13.2.6 MN na na
257
258	Weak comparison for non-subrange reqs 13.3.3 ok ok na
259	Strong comparison for subrange/non-GET 13.3.3 M M na
260	Last-modified implicitly weak 13.3.3 M M M 99
261
262	Strong etag changes always 13.3.4 M na na
263	Weak etag changes when 'significant' 13.3.4 S na na
264	Use etag in conditionals, if available 13.3.4 na M M
265	Use Last-Modified, if avail & no etag 13.3.4 na S S
266	ditto, with subrange reqs 13.3.4 na ok ok
267	Disable use of Last-Mod w/subranges 13.3.4 na na S 99
268	Use both Last-Mod & etag, if avail 13.3.4 na S S
269	Use most restrictive validator 13.3.4 na M M 1
270
271	Validate only w/etag or Last-Modified 13.3.5 M M M 98
272
273	Responses normally cachable 13.4 na ok ok 99
274	HTTP/1.0 responses not cachable 13.4 na MN MN 1
275	No validator/expires/max-age ->no cache 13.4 na S S 99
276	ditto unless unusual situation 13.4 na ok ok 99
277	Cachable status codes are
278	200, 203, 206, 300, 301, 410 13.4 na ok ok 99
279	Cache 206 only if ranges supported 13.4 na MN MN 1
280	Other status codes w/out explict perm 13.4 na MN MN 1
281
282	Don't add or modify Content-Location,
283	Content-MD5, or Etag 13.5.2 na MN na 2
284	Don't modify Expires, Content-Length 13.5.2 na MN na 2
285
286	Mogul [Page 5]
287
288	Internet-Draft HTTP requirements summary 12 September 1997 17:27
289
290
291	Added Expires = Date 13.5.2 na M M 2
292	Added Content-Length is accurate 13.5.2 na M na 2
293	If no-transform, don't add
294	Content-Encoding, Content-Length,
295	Content-Range, Content-Type 13.5.2 na MN na 2
296	Add Warning if adding
297	Content-Encoding, Content-Length,
298	Content-Range, Content-Type 13.5.2 na M na 2
299
300	Combine partial resps 13.5.3 na ok ok 1
301	Delete 1XX Warnings on revalidate 13.5.3 na M M 1
302	Keep 2XX Warnings on revalidate 13.5.3 na M M 1
303	304/206 hdrs update cache entry 13.5.3 na M M 1
304	End-to-end hdrs update cache entry 13.5.3 na M M 1
305
306	Combined subranges: validators match 13.5.4 na M M 1
307	Combined subranges: strong validators 13.5.4 na M M 1
308	Otherwise: use most recent partial resp 13.5.4 na M M 1, 99
309
310	Use Vary to list selecting req hdrs 13.6 M na na
311	New req hdrs match Vary on cache use 13.6 na M M 1
312	Forward non-matching requests 13.6 na M M 1
313	Forwarded req conditional if have Etag 13.6 na S S 1
314	Resp updates entry if tags match 13.6 na S S 1
315	Forward new response 13.6 na M na
316	Vary * means forward new reqs 13.6 na MN MN 1
317	Omit Etag on conditional req and
318	partial cache entry 13.6 na SN SN 1
319	Delete entry if URI matches
320	Content-Location on newer resp and
321	Etags don't match 13.6 na SN SN 1
322
323	Provide security for non-shared caches 13.7 S S S 1
324
325	Store incomplete response 13.8 na ok ok 1, 99
326	Incomplete resp. is partial 13.8 na M M 1
327	Mark all partial resps. as such 13.8 na M M 1
328	Don't use 200 with partial resp. 13.8 na MN MN 1
329	Forward 5xx response 13.8 na ok na 2
330	Treat 5xx like dead server 13.8 na ok na
331
332	GET/HEAD: no side effects 13.9 SN na na
333
334	PUT,DELETE,POST invalidate entries 13.10 na S S 98
335	Match host if invalidating by URI 13.10 na M M 1
336
337	Write-through all updates 13.11 na M M 1
338
339	Use latest response 13.12 na S S 1
340
341	History not transparent 13.13 na na SN
342
343	Mogul [Page 6]
344
345	Internet-Draft HTTP requirements summary 12 September 1997 17:27
346
347
348	Expires no effect on history 13.13 na na ok 98
349	History can indicate staleness 13.13 na na ok 98
350
351
352
353
354
355
356	4 Security Considerations
357
358	This document only summarizes the specification in [2], it does not
359	introduce any new features to HTTP. Therefore, there are no security
360	considerations particular to the requirements summary itself.
361
362
363	5 Acknowledgments
364
365	T.B.S.
366
367
368	6 References
369
370	1. R. Braden. Requirements for Internet Hosts -- Communication
371	Layers. RFC 1122, Internet Engineering Task Force, October, 1989.
372
373	2. Roy T. Fielding, Henrik Frystyk Nielsen, and Tim Berners-Lee.
374	Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft
375	draft-ietf-http-v11-spec-08.txt, HTTP Working Group, September?,
376	1997. [As of this writing, this document has not been assigned an
377	actual Internet-Draft name/number; however, it is available on the
378	Web at
379	www.ics.uci.edu/pub/ietf/http/draft-ietf-http-v11-spec-08.txt.gz and
380	is widely known as ``draft-08''].
381
382
383	7 Author's address
384
385	Jeffrey C. Mogul
386	Western Research Laboratory
387	Digital Equipment Corporation
388	250 University Avenue
389	Palo Alto, California, 94305, USA
390	Email: mogul@wrl.dec.com
391
392
393
394
395
396
397
398
399
400	Mogul [Page 7]