Support for RFC 7233 (Range Requests).

[jtjbrady]

This pull request adds support for HTTP range requests to handleFileDownload.

Range requests allow a client to request only a portion of a file to be transferred. What I actually use this for is for transferring data or log files which grow over time, rather than retreiving the whole file every time, this allows the client to resume the download.

If you're happy to add support for range requests I'll write some unit tests.

[dfaure-kdab]

No objections in principle, assuming unittests indeed.

BTW CI says: ```
KDSoap/src/KDSoapServer/KDSoapServerSocket.cpp:498:58: error: Mixing iterators with const_iterators [-Wclazy-strict-iterators]
next = requestedRanges.erase(next);

[jtjbrady]

Yes, I spotted that one, I guess you don't see the "review", maybe it only goes to the author, so I asked myself to review it?
What I said was:

Is the correct change to stop clazy complaining about this

next = requestedRanges.erase(QVector<QPair<int, int>>::const_iterator(next));

I'm assuming this is a clazy false positive or am I missing something?

That part of the code is:

                    // Coalesce
                    for (auto first = requestedRanges.begin(), next = first + 1; next != requestedRanges.end();) {
                        if (next->first <= first->second) {
                            // Next is directly after (or overlaps) first, so merge it into first.
                            first->second = qMax(first->second, next->second);
                            next = requestedRanges.erase(next);
                        } else {
                            first = next;
                            ++next;
                        }
                    }

As far as I am concerned "first" has to be an iterator not a const_iterator because of the line first->second = qMax(first->second, next->second);
The erase function has always confused me to a degree by taking a const_iterator parameter and returning an iterator.

[dfaure-kdab]

The erase function has always confused me to a degree by taking a const_iterator parameter and returning an iterator.

Then clazy is technically correct, this code does convert a const_iterator into an iterator ;-) But yes it's a kind of false positive because it's a case where it doesn't matter (IIRC the goal of detecting these conversions is to avoid implicit detaching in iterator-based for loops).

We have the same issue in our in-house application, you can add the same suppression:

it = m_entries.erase(it); // clazy:exclude=strict-iterators