W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

"Warning" in draft -08

From: Klaus Weide <kweide@tezcat.com>
Date: Thu, 7 Aug 1997 15:10:57 -0500 (CDT)
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.95.970807132351.10626F-100000@xochi.tezcat.com>
Some comments on the text added to resolve the WARNINGS issue:

1) Without the motivation which is given in 
   draft-ietf-http-warning-00.txt, it is hard to understand how
   the warn-date is supposed to work.

2) It is specified _when_ a server MUST send warn-date, but all
   the following questions are left open:

   - What to put in there if warn-date has to be generated (!)

   - What to to when a Warning with a warn-date is received, and
     the warn-date does not force deletion of the warning-value:

     Should a caching proxy store Warnings without the warn-date, or 
     with it?  Possibly update it?

     Assuming that messages are stored with warn-dates, is the stored
     warn-date updated on successful verification?

     Should a proxy remove warn-date before forwarding to a 1.1 client
     (which may be another proxy)?

   I can try to guess which answers are the right ones to make it work.
   But when I try to apply the usual rules for end-to-end headers -
           "A cache or non-caching proxy SHOULD NOT modify an
            end-to-end header unless the definition of that header
            requires or specifically allows that." from 13.5.2 -
   I come to different results.  So I think it needs to be spelled out
   explicitly what is required and allowed (unless I am the only reader
   confused..).

3) There seems to be no rule which allows to get rid of 2XX Warnings,
   at least not those without a warn-date.  So if a cache entry is 
   sucessfully validated sevaral times, and each of the 304 responses has
   a 2XX Warning, the cache would have to keep all of them even if they
   are just duplicates.

4) What should a client do when it receives an NXX warn-code, where N
   is not 1 or 2?

5) Whatever the answers to the above are, several places mentioning
   end-to-end headers need some reformulation (adding "except for Warning
   headers" or similar).  Also the rules added to 13.5.3 Combining Headers
   for "Warning headers" don't look right, they should be rewritten
   to operate on 'warning-value's.  The following is one header [or
   header field], not three:
 
  Warning: 110 P1 "It's old", 214 P2 "It's mangled", 299 P3 "I warn you too"

   So what works for all other end-to-end headers in 13.5.3, replace
   all-or-nothing without need to split the headers, doesn't work for
   Warning.  It may make more sense to not call Warning an end-to-end
   header at all, since it is so different.  There could be three
   categories, 'Hop-by-hop headers', 'End-to-end headers', and 'Warning
   headers'.  I think that could eliminate some formulation headaches.

   ---
There, that should be enough complaining for today.


      Klaus
Received on Thursday, 7 August 1997 13:12:01 EDT

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