Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/http range/v30 #6409

Merged
merged 17 commits into from
Sep 27, 2021
Merged

Conversation

catenacyber
Copy link
Contributor

Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/1576

Describe changes:

  • Uses a generic container (a thread-safe hash table whose key is the url/filename) to store file parts with HTTP Range header
  • handles reassembly of these parts, while enforcing a global memcap

suricata-verify-pr: 531
OISF/suricata-verify#531

Continues #6355 with comments taken into account

For testing : https://github.com/jasonish/suricata-http-range-test

victorjulien and others added 17 commits September 24, 2021 15:22
Compares two buffers with their two sizes
adds a container, ie a thread safe hash table whose
key is the filename

keep a tree of unordered ranges, up to a memcap limit

adds HTPFileOpenWithRange to handle like HTPFileOpen
if there is a range : open 2 files, one for the whole reassembled,
and one only for the current range
Simplify locking by using the THashData lock instead of a separate
range lock.

Avoid size_t in function arguments.

Clean up file handling functions.

Implement handling of alloc errors.

Rename yaml entry to byterange

Unify public api naming
Better structure design to ensure that one flow maximum
is owning and appending into the file, adding fileOwning field.

Adds also a gap field in a range buffer, so that we can
feed the gap on closing, when we are protected from concurrency
by a lock, (lock which got removed in the append path)

Fixes memcap when encountering a duplicate while inserting
in red and black tree

Adds many comments
To make concurrency reasoning clearer
so that borrow check gets happy
for future compatibility with rust
A block is determined out of order on opening.
But on closing, the gap before it may have been filled.
So, we must post-process it, ie iterate over the red and black
tree so see what blocks we can get.
Move the content-range parsing code to rust
@codecov
Copy link

codecov bot commented Sep 24, 2021

Codecov Report

Merging #6409 (98f84d5) into master (a480ec2) will decrease coverage by 0.03%.
The diff coverage is 69.26%.

@@            Coverage Diff             @@
##           master    #6409      +/-   ##
==========================================
- Coverage   77.02%   76.99%   -0.04%     
==========================================
  Files         612      613       +1     
  Lines      186105   186492     +387     
==========================================
+ Hits       143353   143594     +241     
- Misses      42752    42898     +146     
Flag Coverage Δ
fuzzcorpus 52.83% <49.06%> (+<0.01%) ⬆️
suricata-verify 51.72% <70.68%> (+0.03%) ⬆️
unittests 62.98% <3.90%> (-0.13%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 4336

@victorjulien victorjulien merged commit 98f84d5 into OISF:master Sep 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants