Re: http-v11-spec-rev-03; proxy 100 (Continue) issue

Richard L. Gray writes:

    In section 8.2.4, Requirements for HTTP/1.1 proxies, it says:
    
    "- If the proxy knows that the version of the next-hop server is
    HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST respond
    with a 417 (Expectation Failed) status."
    
    The problem is with the normative MUSTs, which we think ought to be
    at most normative SHOULDs (and perhaps this bullet should just be
    removed).  The reasons are:
    - There is no interoperability issue here, since if the version of the
      next-hop server is unknown, the request, including the Expect header
      field, MUST be forwarded, and the client needs to be able to (for
      compatibility reasons) time out waiting for the 100 (Continue) and
      send the body anyway.
    - The likely behaviour of a client, in the case of recieving a 417 with
      out some reason (like a challenge for credentials), is to just retry
      without the Expect header, so the only effect is to increase latency.
    
    Our proxy implementation currently will just generate a 100 (continue)
    in this case.
    
    I apologize for not catching this earlier (I checked and it goes at
    least back to rev-01).

I suppose you're right that it's inappropriate to base a MUST NOT
with a fact that the proxy is not required to know or verify.  So
since we probably don't want add a mandatory round-trip here (i.e.,
proxy sends OPTIONS method to next-hop server to see what its version
is), this "MUST NOT" ought to be a "SHOULD NOT".    
    
    Also, in the same section, it says:
    
    "Proxies SHOULD maintain a cache recording the HTTP version numbers
    from recently-referenced next-hop servers."
    
    This is not an interoperability issue either, and so we do not think
    the "SHOULD" ought to be normative.  Perhaps it ought to be phrased as
    an "encouragement", as advice to implementers is elsewhere.
    
Here I think the rules of RFC2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

and

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

support this as a SHOULD, under the "limiting retransmissions" rule.

The notion that SHOULD/MUST are allowed "only if required for
interoperability" is a misreading of this "For example" in RFC2119.
It's specifically allowed to use SHOULD/MUST for "limiting
retransmisssions" and that isn't really an "interoperability issue."

-Jeff

Received on Thursday, 26 March 1998 16:39:52 UTC