W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Various problems in the 02 draft

From: Koen Holtman <koen@win.tue.nl>
Date: Fri, 26 Apr 1996 02:00:54 +0200 (MET DST)
Message-Id: <199604260000.CAA00914@wsooti04.win.tue.nl>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: Koen Holtman <koen@win.tue.nl>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/347

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.


The new header fields have not been added to the BNF for
general-header, request-header, etc. yet.


The note at the end of 303 (see other) should be at the end of 302
(moved temporarily)


 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.


  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


  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'.

  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


 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.


    10.8 Connection

The BNF is incomplete.  The rule

   connection-token = token

must be added.

    connection-token 0#( "," connection-token )

can be simplified to



  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.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

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.


   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.


  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'.


 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

 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.


   10.47 CVal


            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.


   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.


  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


  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.


 13.12.2 SLUSHY: Varying Resources

This section says `vary' where it should say `vary or
alternates' in many places.


 13.12.2 SLUSHY: Varying Resources

 Section 10.52 on Vary defines the canonical form for selecting

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.


 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-

I can interpret this as implying that the following response from

  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.


    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.


  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

Received on Thursday, 25 April 1996 17:08:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC