Example for HTTP extension in specification is invalid

[TcM1911]

The provided example for HTTP extension does not follow the specification. The dictionary values in the request_header MUST be a list of string. The example has strings.

Description text:

Each key in the dictionary MUST be the name of the header field and SHOULD preserve case, e.g., User-Agent. The corresponding value for each dictionary key MUST always be a list of type string to support when a header field is repeated.

Example:

{
  "type": "network-traffic",
  "spec_version": "2.1",
  "id": "network-traffic--f8ae967a-3dc3-5cdf-8f94-8505abff00c2",
  "dst_ref": "ipv4-addr--6da8dad3-4de3-5f8e-ab23-45d0b8f12f16",
  "protocols": ["tcp", "http"],
  "extensions": {
    "http-request-ext": {
      "request_method": "get",
      "request_value": "/download.html",
      "request_version": "http/1.1",
      "request_header": {
        "Accept-Encoding": "gzip,deflate",
        "User-Agent": "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113",
        "Host": "www.example.com"
      }
    }
  }
}

[rpiazza]

Thanks @TcM1911 - This is a good catch. Unfortunately, the spec has been published, so no changes can be made at this time. If you look at the json schema (see https://github.com/oasis-open/cti-stix2-json-schemas/blob/master/schemas/observables/network-traffic.json) it also is incorrect, according to the spec, which is why this error wasn't caught. This will be addressed in any new version of the spec in the future.

[ejratl]

The TC must make a decision about whether to update the spec language or whether to update the example and the schema. The Errata will explain the decision and the implications. Updating the schema is problematic because it may invalidate objects in the field.

Reference material (courtesy jmg): https://datatracker.ietf.org/doc/html/rfc2616#section-4.2