Re: #271: use of "may" and "should"

Hi Amos,

On 03/07/2012, at 11:01 AM, Amos Jeffries wrote:

> On 30.06.2012 04:23, James French wrote:
>> "shouldn't" is dangerously close, lexically speaking, to "SHOULD NOT",
>> and perhaps other phrases would leave a better impression in the
>> reader's mind for what is explained by these paragraphs. (e.g. for
>> 2.3.3 "Why shouldn't I? Only because I don't NEED to." so we write
>> "need not" where we have written "shouldn't." Or, for 2.4 "Why
>> shouldn't I? Because I would potentially receive an unusable response
>> if the ETag is matched." so we write "would not" where we have written
>> "shouldn't")
>> 
>> ----
>> jfrench
>> 
>> On Thu, Jun 28, 2012 at 6:34 PM, Mark Nottingham wrote:
>>> 
>>> On 24/06/2012, at 8:18 PM, Julian Reschke wrote:
>>> 
>>>> P6, 2.4:
>>>> 
>>>>   Additionally, a cache can add an If-None-Match header field whose
>>>>   value is that of the ETag header field(s) from all responses stored
>>>>   for the requested URI, if present.  However, if any of the stored
>>>>   responses contains only partial content, the cache shouldn't include
>>>>   its entity-tag in the If-None-Match header field unless the request
>>>>   is for a range that would be fully satisfied by that stored response..
>>>> 
>>>> "shouldn't" -> "SHOULD NOT"
>>> 
>>> Again, this isn't really interop, it's just trying to explain how it works.
> 
> I think this could lead to interop problems though.
> 
> If a cache added such an ETag (because for some reason it wanted too and is allowed), there is no way it can supply the range needed when all the server sends back is 304.
> 
> Imagine a client needing bytes 20+ of an object which has bytes 0-15 cached in a proxy. Server returns 304, and the proxy returns what exactly?
> 
> For this use-case I'm inclined to think MUST NOT is a good idea. SHOULD NOT being acceptible if we have to be loose (I see no reason why we need to be loose though).



The original 2616 text was:

>    If any of the existing cache entries contains only partial content
>    for the associated entity, its entity-tag SHOULD NOT be included in
>    the If-None-Match header field unless the request is for a range that
>    would be fully satisfied by that entry.

I agree with your point that this needs to be a requirement. The form "SHOULD NOT ... unless ..." generally means "don't do this unless you meet one of these conditions"; here, it means "don't put an etag on a request when you've cached partial content, unless it covers the whole thing."

So, technically it's correct, but we could make this more clear by rewriting. E.g.,

"""
... However, a cache MUST NOT include an entity tag from a stored partial response if that response does not fully satisfy the requested range.
"""




--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 3 July 2012 01:26:30 UTC