Project

General

Profile

Feature #1576

http: byte-range support

Added by Victor Julien over 5 years ago. Updated 4 months ago.

Status:
In Review
Priority:
Normal
Target version:
Effort:
Difficulty:
Label:


Related issues

Related to Task #2309: SuriCon 2017 brainstormNewVictor JulienActions
Related to Feature #2485: http: log byte range with file extractionClosedPhilippe AntoineActions
Related to Feature #4117: http2: byte-range supportAssignedPhilippe AntoineActions
Has duplicate Bug #2326: File extraction not properly handling http range requestsClosedActions
Has duplicate Feature #1017: Add support for content-rangeClosedActions
#1

Updated by Andreas Herz over 5 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
#2

Updated by Victor Julien over 5 years ago

Related to #1017

#3

Updated by Victor Julien over 3 years ago

  • Related to Task #2309: SuriCon 2017 brainstorm added
#4

Updated by Victor Julien about 3 years ago

  • Related to Feature #2485: http: log byte range with file extraction added
#5

Updated by Raymond Hansen over 2 years ago

First step would be to document the chunks of file(s) as identified per sensor, if multiple sensors are in use.

#6

Updated by Victor Julien over 2 years ago

  • Has duplicate Bug #2326: File extraction not properly handling http range requests added
#7

Updated by Victor Julien about 2 years ago

#8

Updated by Philippe Antoine about 2 years ago

  • Assignee changed from OISF Dev to Philippe Antoine
#9

Updated by Philippe Antoine about 2 years ago

My understanding is the following :
We now log the byte-range but we would like suricata to handle the complete file reassembly (in case there is any).
Is that correct ?
Is there already an example of suricata of reassembly over TCP ? And in this case over different flows ?

#10

Updated by Andreas Herz over 1 year ago

  • Status changed from New to Assigned
#11

Updated by Andreas Herz over 1 year ago

We will split those in multiple smaller tasks.

#12

Updated by Philippe Antoine over 1 year ago

First is rebuilding the file if multiple requests/responses are in the same flow

#13

Updated by Andreas Herz over 1 year ago

Does anyone remember WHAT smaller tasks we wanted to create :)?

#14

Updated by Philippe Antoine over 1 year ago

First is rebuilding file if multiple transactions are in the same flow (maybe first subclass, if they are in the right order)
Then next task would be to see what to do if the transactions are across many flows

#15

Updated by Victor Julien over 1 year ago

  • Target version changed from TBD to 6.0.0beta1
#16

Updated by Philippe Antoine over 1 year ago

  • Status changed from Assigned to In Review
#17

Updated by Philippe Antoine about 1 year ago

  • Status changed from In Review to Assigned
  • Target version changed from 6.0.0beta1 to 7.0rc1
#18

Updated by Victor Julien 12 months ago

  • Related to deleted (Feature #1017: Add support for content-range)
#19

Updated by Victor Julien 12 months ago

  • Has duplicate Feature #1017: Add support for content-range added
#20

Updated by Philippe Antoine 8 months ago

#21

Updated by Philippe Antoine 4 months ago

So, we would like :

- To handle ranges over multiple flows, ie use another container than the flow (the url for instance)
  • This container can be generic with a key, and a type for the key
    - To handle unordered ranges
  • That means storing an unordered range up until we can do the reassembly
  • We need to limit the memory consumption... use a global memcap for these containers ?
  • We also need timeouts (the new container shall timeout as flow time out)
#22

Updated by Philippe Antoine 4 months ago

  • Status changed from Assigned to In Progress
#23

Updated by Philippe Antoine 4 months ago

  • Status changed from In Progress to In Review

Also available in: Atom PDF