WGLC: Strengthening SHOULDs

Reviewing the current specs, I think there are a few cases where we use SHOULD that are important enough for interop and/or security to justify a MUST (in some cases, with a bit more explanation). 

P1
--

* 3.3.2 "A server SHOULD NOT send a Content-Length header field in any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of [Part2])."

* B "For compatibility with legacy list rules, recipients SHOULD accept empty list elements." (note that this requirement is in an appendix; it might be good to move it up)


P2
--

* 4.3.4 "An origin server SHOULD reject any PUT request that contains a Content-Range header field"

* 4.3.6 "A server SHOULD NOT send any Transfer-Encoding or Content-Length header fields in a successful response."  (CONNECT)

* 4.3.6 "Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets."

* 5.5.2 "A user agent SHOULD NOT send a Referer header field in an unsecured HTTP request if the referring page was received with a secure protocol."

* 7.1.1.1 "Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, SHOULD interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past that had the same last two digits."

* 7.1.2 "When Location is provided in a 3xx (Redirection) response and the URI reference that the user agent used to generate the request target contains a fragment identifier, the user agent SHOULD process the redirection as if the Location field value inherits the original fragment. In other words, if the Location does not have a fragment component, the user agent SHOULD interpret the Location reference as if it had the original reference's fragment." 

(note repeated requirement; second instance change to "can")


P6
--

* 4.1.3 "Cache recipients SHOULD consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration."

* 5 "If the Content-Length, ETag and Last-Modified values of a HEAD response (when present) are the same as that in a selected GET response (as per Section 4.3), the cache SHOULD update the remaining header fields in the stored response using the following rules..."  

(add "and the cache updates the stored response")




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

Received on Tuesday, 30 April 2013 02:18:19 UTC