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