validate http examples

draft-ietf-httpbis-bcp56bis.md

@@ -261,14 +261,14 @@ evolve.
 When specifying examples of protocol interactions, applications should document both the request
 and response messages, with full headers, preferably in HTTP/1.1 format. For example:
 
-~~~ example
+~~~ http-message
 GET /thing HTTP/1.1
 Host: example.com
 Accept: application/things+json
 User-Agent: Foo/1.0
 
 ~~~
-~~~ example
+~~~ http-message
 HTTP/1.1 200 OK
 Content-Type: application/things+json
 Content-Length: 500
@@ -664,7 +664,7 @@ name).
 
 For example, this response cannot be stored or reused by a cache:
 
-~~~
+~~~ http-message
 HTTP/1.1 200 OK
 Content-Type: application/example+xml
 Cache-Control: no-store
@@ -712,7 +712,7 @@ the "default" response).
 
 For example, this response:
 
-~~~
+~~~ http-message
 HTTP/1.1 200 OK
 Content-Type: application/example+xml
 Cache-Control: max-age=60
@@ -793,7 +793,7 @@ Considerations.
 
 An example of a HTTP response from an application that does not intend for its content to be treated as active by browsers might look like this:
 
-~~~
+~~~ http-message
 HTTP/1.1 200 OK
 Content-Type: application/example+json
 X-Content-Type-Options: nosniff
@@ -903,20 +903,4 @@ do not benefit from patches and other security improvements incorporated upstrea
 
 HTTP clients can expose a variety of information to servers. Besides information that's explicitly sent as part of an application's operation (for example, names and other user-entered data), and "on the wire" (which is one of the reasons https is recommended in {{scheme}}), other information can be gathered through less obvious means -- often by connecting activities of a user over time.
 
-This includes session information, tracking the client through fingerprinting, and mobile code.
-
-Session information includes things like the IP address of the client, TLS session tickets, Cookies, ETags stored in the client's cache, and other stateful mechanisms. Applications are advised to avoid using session mechanisms unless they are unavoidable or necessary for operation, in which case these risks needs to be documented. When they are used, implementations should be encouraged to allow clearing such state.
-
-Fingerprinting uses unique aspects of a client's messages and behaviours to connect disparate requests and connections. For example, the User-Agent request header conveys specific information about the implementation; the Accept-Language request header conveys the users' preferred language. In combination, a number of these markers can be used to uniquely identify a client, impacting its control over its data. As a result, applications are advised to specify that clients should only emit the information they need to function in requests.
-
-Finally, if an application exposes the ability to run mobile code, great care needs to be taken, since any ability to observe its environment can be used as an opportunity to both fingerprint the client and to obtain and manipulate private data (including session information). For example, access to high-resolution timers (even indirectly) can be used to profile the underlying hardware, creating a unique identifier for the system. Applications are advised to avoid allowing the use of mobile code where possible; when it cannot be avoided, the resulting system's security properties need be carefully scrutinised.
-
-
---- back
-
-# Changes from RFC 3205
-
-{{?RFC3205}} captured the Best Current Practice in the early 2000's, based on the concerns facing
-protocol designers at the time. Use of HTTP has changed considerably since then, and as a result
-this document is substantially different. As a result, the changes are too numerous to list
-individually.
+This includes session informati\x6F\x6E\x2C\x20\x74\x72\x61\x63\x6B\x69\x6E\x67\x20\x74\x68\x65\x20\x63\x6C\x69\x65\x6E\x74\x20\x74\x68\x72\x6F\x75\x67\x68\x20\x66\x69\x6E\x67\x65\x72\x70\x72\x69\x6E\x74\x69\x6E\x67\x2C\x20\x61\x6E\x64\x20\x6D\x6F\x62\x69\x6C\x65\x20\x63\x6F\x64\x65\x2E\x0A\x0A\x53\x65\x73\x73\x69\x6F\x6E\x20\x69\x6E\x66\x6F\x72\x6D\x61\x74\x69\x6F\x6E\x20\x69\x6E\x63\x6C\x75\x64\x65\x73\x20\x74\x68\x69\x6E\x67\x73\x20\x6C\x69\x6B\x65\x20\x74\x68\x65\x20\x49\x50\x20\x61\x64\x64\x72\x65\x73\x73\x20\x6F\x66\x20\x74\x68\x65\x20\x63\x6C\x69\x65\x6E\x74\x2C\x20\x54\x4C\x53\x20\x73\x65\x73\x73\x69\x6F\x6E\x20\x74\x69\x63\x6B\x65\x74\x73\x2C\x20\x43\x6F\x6F\x6B\x69\x65\x73\x2C\x20\x45\x54\x61\x67\x73\x20\x73\x74\x6F\x72\x65\x64\x20\x69\x6E\x20\x74\x68\x65\x20\x63\x6C\x69\x65\x6E\x74\x27\x73\x20\x63\x61\x63\x68\x65\x2C\x20\x61\x6E\x64\x20\x6F\x74\x68\x65\x72\x20\x73\x74\x61\x74\x65\x66\x75\x6C\x20\x6D\x65\x63\x68\x61\x6E\x69\x73\x6D\x73\x2E\x20\x41\x70\x70\x6C\x69\x63\x61\x74\x69\x6F\x6E\x73\x20\x61\x72\x65\x20\x61\x64\x76\x69\x73\x65\x64\x20\x74\x6F\x20\x61\x76\x6F\x69\x64\x20\x75\x73\x69\x6E\x67\x20\x73\x65\x73\x73\x69\x6F\x6E\x20\x6D\x65\x63\x68\x61\x6E\x69\x73\x6D\x73\x20\x75\x6E\x6C\x65\x73\x73\x20\x74\x68\x65\x79\x20\x61\x72\x65\x20\x75\x6E\x61\x76\x6F\x69\x64\x61\x62\x6C\x65\x20\x6F\x72\x20\x6E\x65\x63\x65\x73\x73\x61\x72\x79\x20\x66\x6F\x72\x20\x6F\x70\x65\x72\x61\x74\x69\x6F\x6E\x2C\x20\x69\x6E\x20\x77\x68\x69\x63\x68\x20\x63\x61\x73\x65\x20\x74\x68\x65\x73\x65\x20\x72\x69\x73\x6B\x73\x20\x6E\x65\x65\x64\x73\x20\x74\x6F\x20\x62\x65\x20\x64\x6F\x63\x75\x6D\x65\x6E\x74\x65\x64\x2E\x20\x57\x68\x65\x6E\x20\x74\x68\x65\x79\x20\x61\x72\x65\x20\x75\x73\x65\x64\x2C\x20\x69\x6D\x70\x6C\x65\x6D\x65\x6E\x74\x61\x74\x69\x6F\x6E\x73\x20\x73\x68\x6F\x75\x6C\x64\x20\x62\x65\x20\x65\x6E\x63\x6F\x75\x72\x61\x67\x65\x64\x20\x74\x6F\x20\x61\x6C\x6C\x6F\x77\x20\x63\x6C\x65\x61\x72\x69\x6E\x67\x20\x73\x75\x63\x68\x20\x73\x74\x61\x74\x65\x2E\x0A\x0A\x46\x69\x6E\x67\x65\x72\x70\x72\x69\x6E\x74\x69\x6E\x67\x20\x75\x73\x65\x73\x20\x75\x6E\x69\x71\x75\x65\x20\x61\x73\x70\x65\x63\x74\x73\x20\x6F\x66\x20\x61\x20\x63\x6C\x69\x65\x6E\x74\x27\x73\x20\x6D\x65\x73\x73\x61\x67\x65\x73\x20\x61\x6E\x64\x20\x62\x65\x68\x61\x76\x69\x6F\x75\x72\x73\x20\x74\x6F\x20\x63\x6F\x6E\x6E\x65\x63\x74\x20\x64\x69\x73\x70\x61\x72\x61\x74\x65\x20\x72\x65\x71\x75\x65\x73\x74\x73\x20\x61\x6E\x64\x20\x63\x6F\x6E\x6E\x65\x63\x74\x69\x6F\x6E\x73\x2E\x20\x46\x6F\x72\x20\x65\x78\x61\x6D\x70\x6C\x65\x2C\x20\x74\x68\x65\x20\x55\x73\x65\x72\x2D\x41\x67\x65\x6E\x74\x20\x72\x65\x71\x75\x65\x73\x74\x20\x68\x65\x61\x64\x65\x72\x20\x63\x6F\x6E\x76\x65\x79\x73\x20\x73\x70\x65\x63\x69\x66\x69\x63\x20\x69\x6E\x66\x6F\x72\x6D\x61\x74\x69\x6F\x6E\x20\x61\x62\x6F\x75\x74\x20\x74\x68\x65\x20\x69\x6D\x70\x6C\x65\x6D\x65\x6E\x74\x61\x74\x69\x6F\x6E\x3B\x20\x74\x68\x65\x20\x41\x63\x63\x65\x70\x74\x2D\x4C\x61\x6E\x67\x75\x61\x67\x65\x20\x72\x65\x71\x75\x65\x73\x74\x20\x68\x65\x61\x64\x65\x72\x20\x63\x6F\x6E\x76\x65\x79\x73\x20\x74\x68\x65\x20\x75\x73\x65\x72\x73\x27\x20\x70\x72\x65\x66\x65\x72\x72\x65\x64\x20\x6C\x61\x6E\x67\x75\x61\x67\x65\x2E\x20\x49\x6E\x20\x63\x6F\x6D\x62\x69\x6E\x61\x74\x69\x6F\x6E\x2C\x20\x61\x20\x6E\x75\x6D\x62\x65\x72\x20\x6F\x66\x20\x74\x68\x65\x73\x65\x20\x6D\x61\x72\x6B\x65\x72\x73\x20\x63\x61\x6E\x20\x62\x65\x20\x75\x73\x65\x64\x20\x74\x6F\x20\x75\x6E\x69\x71\x75\x65\x6C\x79\x20\x69\x64\x65\x6E\x74\x69\x66\x79\x20\x61\x20\x63\x6C\x69\x65\x6E\x74\x2C\x20\x69\x6D\x70\x61\x63\x74\x69\x6E\x67\x20\x69\x74\x73\x20\x63\x6F\x6E\x74\x72\x6F\x6C\x20\x6F\x76\x65\x72\x20\x69\x74\x73\x20\x64\x61\x74\x61\x2E\x20\x41\x73\x20\x61\x20\x72\x65\x73\x75\x6C\x74\x2C\x20\x61\x70\x70\x6C\x69\x63\x61\x74\x69\x6F\x6E\x73\x20\x61\x72\x65\x20\x61\x64\x76\x69\x73\x65\x64\x20\x74\x6F\x20\x73\x70\x65\x63\x69\x66\x79\x20\x74\x68\x61\x74\x20\x63\x6C\x69\x65\x6E\x74\x73\x20\x73\x68\x6F\x75\x6C\x64\x20\x6F\x6E\x6C\x79\x20\x65\x6D\x69\x74\x20\x74\x68\x65\x20\x69\x6E\x66\x6F\x72\x6D\x61\x74\x69\x6F\x6E\x20\x74\x68\x65\x79\x20\x6E\x65\x65\x64\x20\x74\x6F\x20\x66\x75\x6E\x63\x74\x69\x6F\x6E\x20\x69\x6E\x20\x72\x65\x7

draft-ietf-httpbis-variants.md

@@ -66,13 +66,13 @@ Even when the headers' semantics are understood, a cache does not know enough ab
 
 For example, if a cache has stored the following request/response pair:
 
-~~~ example
+~~~ http-message
 GET /foo HTTP/1.1
 Host: www.example.com
 Accept-Language: en;q=0.5, fr;q=1.0
 
 ~~~
-~~~ example
+~~~ http-message
 HTTP/1.1 200 OK
 Content-Type: text/html
 Content-Language: en
@@ -90,18 +90,18 @@ Its companion Variant-Key response header field ({{variant-key}}) indicates the
 
 When this specification is in use, the example above might become:
 
-~~~ example
+~~~ http-message
 GET /foo HTTP/1.1
 Host: www.example.com
 Accept-Language: en;q=0.5, fr;q=1.0
 
 ~~~
-~~~ example
+~~~ http-message
 HTTP/1.1 200 OK
 Content-Type: text/html
 Content-Language: en
 Vary: Accept-Language
-Variants: Accept-Language;de;en;jp
+Variants: accept-language;de;en;jp
 Variant-Key: en
 Transfer-Encoding: chunked
 
@@ -145,31 +145,31 @@ Note that an available-value that is a token is interpreted as a string containi
 
 So, given this example header field:
 
-~~~ example
-Variants: Accept-Encoding=(gzip)
+~~~ http-message
+Variants: accept-encoding=(gzip)
 ~~~
 
 a recipient can infer that the only content-coding available for that resource is "gzip" (along with the "identity" non-encoding; see {{content-encoding}}).
 
 Given:
 
-~~~ example
+~~~ http-message
 Variants: accept-encoding=()
 ~~~
 
 a recipient can infer that no content-codings (beyond identity) are supported. Note that as always, field-name is case-insensitive.
 
 A more complex example:
 
-~~~ example
-Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr)
+~~~ http-message
+Variants: accept-encoding=(gzip br), accept-language=(en fr)
 ~~~
 
 Here, recipients can infer that two content-codings in addition to "identity" are available, as well as two content languages. Note that, as with all Structured Header dictionaries, they might occur in the same header field or separately, like this:
 
-~~~ example
-Variants: Accept-Encoding=(gzip brotli)
-Variants: Accept-Language=(en fr)
+~~~ http-message
+Variants: accept-encoding=(gzip brotli)
+Variants: accept-language=(en fr)
 ~~~
 
 The ordering of available-values is significant, as it might be used by the header's algorithm for selecting a response (in this example, the first language is the default; see {{content-language}}).
@@ -215,7 +215,7 @@ Each inner-list member is treated as identifying an available-value for the corr
 For example:
 
 ~~~ example
-Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr)
+Variants: accept-encoding=(gzip br), accept-language=(en fr)
 Variant-Key: (gzip fr)
 ~~~
 
@@ -224,7 +224,7 @@ This header pair indicates that the representation has a "gzip" content-coding a
 If the response can be used to satisfy more than one request, they can be listed in additional members.  For example:
 
 ~~~ example
-Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr)
+Variants: accept-encoding=(gzip br), accept-language=(en fr)
 Variant-Key: (gzip fr), ("identity" fr)
 ~~~
 
@@ -233,7 +233,7 @@ indicates that this response can be used for requests whose Accept-Encoding algo
 When more than one Variant-Key value is in a response, the first one present MUST correspond to the request that caused that response to be generated. For example:
 
 ~~~ example
-Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr)
+Variants: accept-encoding=(gzip br), accept-language=(en fr)
 Variant-Key: (gzip fr), (identity fr), (br fr oops)
 ~~~
 

sf.json

@@ -1,4 +1,6 @@
 {
     "cache-status": "list",
-    "proxy-status": "list"
+    "proxy-status": "list",
+    "variant-key": "list",
+    "variants": "dict"
 }