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>

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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:51 EDT