range: better closing for out of order ranges

Ticket: 5132

In case of a duplicate range, we can return early, because
there is no new data to process.

More importantly, this commit adds a check about wether the file
got closed meanwhile, so that this just completed out of order
range, even if it brings new data, is now irrelevant.
This can happen for instance if there was a gap...

diff --git a/src/app-layer-htp-range.c b/src/app-layer-htp-range.c
index ed7d6b1540592325dc32af4dadf3c85f359028be..9e837f36048d6762810f19a62bea7b86c47e43e2 100644 (file)
--- a/src/app-layer-htp-range.c
+++ b/src/app-layer-htp-range.c
@@ -493,6 +493,8 @@ File *HttpRangeClose(HttpRangeContainerBlock *c, uint16_t flags)
                 (void)SC_ATOMIC_SUB(ContainerUrlRangeList.ht->memuse, c->current->buflen);
                 SCFree(c->current->buffer);
                 SCFree(c->current);
+                c->current = NULL;
+                return NULL;
             }
             SCLogDebug("inserted range fragment");
             c->current = NULL;
@@ -500,6 +502,10 @@ File *HttpRangeClose(HttpRangeContainerBlock *c, uint16_t flags)
                 // we have to wait for the flow owning the file
                 return NULL;
             }
+            if (c->container->files->tail == NULL) {
+                // file has already been closed meanwhile
+                return NULL;
+            }
             // keep on going, maybe this out of order chunk
             // became the missing part between open and close
         }