- From: Koen Holtman <koen@win.tue.nl>
- Date: Fri, 26 Apr 1996 02:00:54 +0200 (MET DST)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: Koen Holtman <koen@win.tue.nl>
Here is a list of problems in the 02 draft I have found so far. I
have not included problems which are already being discussed on the
list or in the editorial group.
I'll let Jim Gettys decide on the appropriate action for each of these
problems. Some may be solved by simple editing, others may require a
call for discussion by the wg or asking questions to the author of a
particular piece of draft text.
1.
The new header fields have not been added to the BNF for
general-header, request-header, etc. yet.
2.
The note at the end of 303 (see other) should be at the end of 302
(moved temporarily)
3.
10.7.1 SLUSHY: Restrictions on What is Cachable
[...]
successful validation. If there is neither a cache validator nor an
explicit expiration time associated with a response, we do not expect it
to be cached, but certain caches may violate this expectation (for
example, when little or no network connectivity is available) as long as
they explicit mark their responses using the Warning mechanism describe
^^^^^^^^^^^^^^^^^^^^^^^^^^^
in section 10.51.
It is unclear to me which Warning code should be used for this
marking. A new code will probably need to be introduced.
4.
10.7.2 Restrictions On What May be Stored by a Cache
[...]
recognize or obey this directive, malicious or compromised caches may
not recognize or obey this directive, and all communications networks
^^^
may be vulnerable to eavesdropping.
Remove `all'. There may be trouble with people bringing up quantum
cryptography.
5.
10.7.3 Modifications of the Basic Expiration Mechanism
(or later) cache than to an HTTP/1.0 cache. This may be useful if
certain HTTP/1.0 caches improperly calculate ages or expiration times,
perhaps due to badly unsynchronized clocks.
^^^^^^^^^^^^^^^^^^^^
Remove `badly' or `un'.
6.
10.7.4 SLUSHY: Controls over cache revalidation and reload
This section mixes informational text with text stating requirements.
The section mentions cookies without giving a reference or
explanation.
7.
10.7.6 Miscellaneous restrictions
In certain circumstances, an intermediate cache (proxy) may find it
useful to convert the encoding of an entity body. For example, a proxy
^^^^^^^^^^^^^^^^^
might use a compressed content-coding to transfer the body to a client
on a slow link.
This implicitly allows conversion of entity bodies by proxy caches. I
don't think this was ever allowed before, and in any case it breaks
range retrieval (afaik, range requests work on the entity data in the
response, not on the unencoded version of this data.)
Also, I cannot think of any case in which inclusion of "no-transform"
would be needed to ensure correct service.
8.
10.8 Connection
The BNF is incomplete. The rule
connection-token = token
must be added.
connection-token 0#( "," connection-token )
can be simplified to
1#connection-token
9.
10.8.1 Persist
The BNF is incomplete. Add rules for param-name and value.
The text
The Persist header itself is optional, and is used only if a parameter
is being sent. HTTP/1.1 does not define any parameters.
is either confusing, or implies that 1.1 clients can never include
this header.
10.
10.16 Content-Location
[...]
A server SHOULD provide a Content-Location if, when including
an entity in response to a GET request on a negotiated resource, the
entity corresponds to a specific, non-negotiated location which can be
accessed via the Content-Location URI.
If this is to use the terminology of the new Section 12 to reflect
draft-holtman-http-negotiation, this should be:
A server SHOULD provide a Content-Location if, when including an
entity in response to a GET request on a *transparently* negotiated
resource, the entity corresponds to a specific, *not transparently*
negotiated location which can be accessed via the Content-Location
URI.
However, I see no need to include the above sentence in the 1.1 spec.
It is just an over-specification which may confuse people.
11.
10.19 SLUSHY Expires
Last sentence:
HTTP/1.1 servers should not send Expires dates more than one
year in the future.
I have no idea why this should be required. In any case, this
requirement has had no review by the wg afaik.
12.
10.33 Range
Last sentence:
In some cases, it may be more appropriate to use the Range-If header
(see section 10.104) instead of the Range header.
^^^^^^^
According to the Range-If section, this should be `in addition to'.
13.
10.46 Age
Caches transmit age values using:
Age = "Age" ":" age-value
age-value = delta-seconds
Age values are non-negative decimal integers, representing time in
seconds.
If a cache receives a value larger than the largest positive integer it
can represent, or if any of its age calculations overflows, it MUST NOT
^^^^^^^^^^^
transmit an Age header. Otherwise, HTTP/1.1 caches MUST send an Age
^^^^^^^^^^^^^^^^^^^^^^^
header in every response. Caches SHOULD use a representation with at
least 31 bits of range.
This makes the Age header useless as an indicator that the response is
not authoritative (not generated or validated by the origin server),
which is *very* bad. It also goes against several principles for the
design of fault tolerant systems. I strongly suggest that the marked
text is replaced by
it MUST transmit an Age header with its largest positive integer.
14.
10.47 CVal
Examples:
CVal: "xyzzy"
CVal: "xyzzy"/W
CVal: "xyzzy";3
^
CVal: "xyzzy"/W;3
^
To reflect Section 3.14, this should be
CVal: "xyzzy";"3"
CVal: "xyzzy"/W;"3"
Same for the examples in 10.48 and 10.49.
15.
10.55 SLUSHY: Range-If
In my opinion, this mechanism adds to much complexity to the caching
model. It should be removed. In my opinion, this will not lead to
any significant loss in performance.
16.
13.2.1 Server-Specified Expiration
[...]
If an origin server wishes to force a semantically transparent cache to
^^^^^^^^^^^^^^^^^^^^^^^^
validate every request, it may assign an explicit expiration time in the
Delete the marked text above, it just makes the sentence more
confusing.
17.
13.2.4 Client-controlled Behavior
While the origin server (and to a lesser extent, intermediate caches)
are the primary source of expiration information,
I have no idea what the above text fragment means exactly.
18.
13.12.2 SLUSHY: Varying Resources
This section says `vary' where it should say `vary or
alternates' in many places.
19.
13.12.2 SLUSHY: Varying Resources
[...]
Section 10.52 on Vary defines the canonical form for selecting
headers.
The current 10.52 does not define such a canonical form. It could be
rewritten to state its matching rule in terms of equality of the
canonical forms defined in 13.12.2.
20.
13.12.2 SLUSHY: Varying Resources
[...]
When a response is received that includes a Content-Location header but
no variant-ID, then the update key is (content-location-URI, null), and
the entry key for the response is (content-location-URI, null, sel-hdr-
values).
I can interpret this as implying that the following response from
spoof.city.edu:
HTTP/1.1 200 OK
...
Content-Location: http://www.microsoft.com/
Cache-control: max-age=1000000
...
<h1>0S/2 RULEZ!</h1>
overwrites the cached homepage of a well-known company. Such
misinterpretations must be avoided. Note that 10.16 has the same
interpretation problem to a lesser extent.
21.
G.1 Support for Content Negotiation by Proxy Caches
The response received from the upstream server
may refresh a stale 200 response that was cached for the varying
resource a side effect. XXX previous sentence doesn't make sense
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
My advise is to delete this previous sentence above.
22.
G. Proxy Cache Implementation Guidelines
[...]
G.2 Propagation of Changes in Opaque Selection
Section G.2 is not meant for proxy cache implementers, but for
resource authors.
That is all I have for now. I still have to read most of the slushy
stuff.
Koen.
Received on Thursday, 25 April 1996 17:08:18 UTC