mirror of https://github.com/OISF/suricata
http1: do not re-parse Content-Disposition header
Ticket: 8529 When Suricata handles a HTTP1 response body, it does so with a file, and tries to get the filename from the Content-Disposition header if any, then from the uri. If it failed to find a file name, it tried again every time there was new data from the response body, even if there was no new data to find a file name in either the header nor the uri. This causes a slowdown in the case the Content-Disposition header is big. Fix is to set the flag on the first call of the callback, to be sure that we will parse the Content-Disposition header for a filename header only once per http1 response.pull/15328/merge
parent
6d437956e2
commit
9aaa6f7854
Loading…
Reference in New Issue