Add initial stab at mime_type for file objects #760
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Address #749 file objects.
While "Content-Type" in HTTP headers and related protocols utilize
MIME type descriptions, they are offered as a hint to the other
end of the connection so they know how to handle the data. However,
in the context of a file, the MIME type should be more authoritative
in that tools like Zeek, Suricata, and other tools that use
libmagic or yara to detect filetypes provide information based upon
a match to a pattern of bytes.
For #554, I think retaining the headers as
Content-Type
makes senseas this is the configured value set by the server (or client). I think
it is useful to compare what was advertised vs what was actually sent,
e.g. the header value in
http.response.content-type
vsfile.mime_type
of the file transferred.