http.response.status_code as long instead of keyword or integer

Hello , I did not found any discussion on this topic so , I ask the question In ECS the http.response.status_code is mapped as long , why ?

Using an integer brings the advantage of taking up less space, but we are not supposed to do digital operations (sum/avg…) on an HTTP status because all codes are between 100 and 599.

Using a keyword will allow to run an aggregation without specifying a null_value. The keyword type will also allow to make range query if necessary (it will be in alphanumeric order): ECS source code

 - name: response.status_code
      format: string
      level: extended
      type: long
      description: >
        HTTP response status code.
      example: 404

[djptek]

Here’s an example of partition using programmatically generated response codes (long) for every possible value using Lens

[djptek]

Hi @blookot

add a second http.response.status_code_keyword field

this would work - you’d need to add e.g. some painless in the index pipeline to populate that field &/or do a reindex to add this to your legacy data if required