Original text:
14.3. <del> The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource. </del>  <del> An origin server that supports byte-range requests for a given target resource MAY send </del>  <del> to indicate what range units are supported.  A client MAY generate range requests without having received this header field for the resource involved.  Range units are defined in range.units. </del>  A server that does not support any kind of range request for the target resource MAY send <del> to advise the client not to attempt a range request. </del>  14.4.

Reviewer comments:
Clarify that Accept-Ranges can be sent by any server, remove "none" from the ABNF because it is now a reserved range unit, and allow the field to be sent in a trailer section while noting why that is much less useful than as a header field For this is an alternative to
IMHO... allowing non-origins to service range requests, but disallowing them to advertise that is really really weird. At the end of the day, any "Accept-*" field value received is always a statement about the present, and not a promise for future requests. This is not different from other fields. Do you believe it would actually be harmful if a client was mislead to believe it can do a range request, and then it receives the full content with a 200?
A header field is defined by the intent of the people who minted and deployed it. That was Lou Montulli. Its original meaning was confused in the pre-RFC2068 draft because of an editorial mistake, not because the header field ever changed its meaning as deployed. The main use case was restarting a big download, and that is not specific to origin servers. Today, this field is largely ignored because of the poor specification. We can improve such things without harm.
I don't think this is worth too much more time, I'll just say I disagree -- it's not very useful in this form, and it differs from every other bit of similar metadata we put into headers (e.g., , , ). I'll make a suggestion to try to make the ambiguity here a bit more clear.
You are starting with an assumption that this is an origin characteristic and saying that this doesn't fit that assumption. I agree that the assumption does not fit the header field's definition, nor is it a fit for purpose. The field's purpose is to tell the client that range requests may help if there is a problem receiving the whole content. That's not limited to origin servers and has nothing in common with Allow or Vary. If a proxy cache can process range requests on large cached items (e.g., a company training video) and its clients can benefit from that, why would we not want to advertise that fact to the client? The theory that this may cause a problem with multiple paths just doesn't hold for proxies (they are client chosen) and wouldn't matter anyway for range requests because the worst case is a 200 response. This was explained in 1996 and the definition was fixed in the next draft. It just wasn't fixed enough. This doesn't change the fact that the header field isn't very useful, simply because it is advisory only and most clients will ignore that advice when it doesn't matter to them if 200 is the response. That's okay.

Revised text:
14.3.  <ins> The "Accept-Ranges" field in a response indicates whether an upstream server supports range requests for the target resource. </ins>  <ins> For example, a server that supports byte.ranges can send the field </ins>  <ins> to indicate that it supports byte range requests for that target resource, thereby encouraging its use by the client for future partial requests on the same request path.  Range units are defined in range.units. A client MAY generate range requests regardless of having received an Accept-Ranges field.  The information only provides advice for the sake of improving performance and reducing unnecessary network transfers. Conversely, a client MUST NOT assume that receiving an Accept-Ranges field means that future range requests will return partial responses. The content might change, the server might only support range requests at certain times or under certain conditions, or a different intermediary might process the next request. </ins> A server that does not support any kind of range request for the target resource MAY send  <ins> to advise the client not to attempt a range request on the same request path.  The range unit "none" is reserved for this purpose. The Accept-Ranges field MAY be sent in a trailer section, but is preferred to be sent as a header field because the information is particularly useful for restarting large information transfers that have failed in mid-content (before the trailer section is received). </ins> 14.4.