Parse URLs using boost::Url

[Qup42]

This PR cleans up the parsing of HTTP Requests and switches to boost::Url for URL parsing.
This should fix issues with the following types of HTTP requests:

• POST requests that additionally have query parameters as part of the URL
• POST requests that store the unescaped query in the query body (there previously was a bug in this case that tried to unescape and already unescaped query.

The only (known) limitation that remains for now is that duplicate HTTP parameters throw an error, because we are not yet sure about their semantics.

[codecov]

Codecov Report

Attention: Patch coverage is 70.58824% with 15 lines in your changes missing coverage. Please review.

Project coverage is 92.51%. Comparing base (370cb7d) to head (3ddc490).
Report is 14 commits behind head on master.

Files with missing lines	Patch %	Lines
src/engine/Server.cpp	58.33%	15 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1417      +/-   ##
==========================================
- Coverage   94.13%   92.51%   -1.62%     
==========================================
  Files         347      353       +6     
  Lines       25636    26487     +851     
  Branches     3450     3551     +101     
==========================================
+ Hits        24132    24504     +372     
- Misses       1462     1941     +479     
  Partials       42       42              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[joka921]

An opportunity to also fix another bug.

The real solution is to completely handle the URL parsing using Boos::Url which wasn't yet released at the time we implemented this rather hacky URL parser.

[sonarcloud]

Quality Gate passed

Issues
5 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[joka921]

Thanks, this should fix some longstanding bugs and makes the code much easier to read.

One major thing:
We should have unit tests for this code
(for the UrlParser, as well as for the (is it static or can it be static) method in Server.cpp that does the dispatch between GET and the various types of POST.

[Qup42]

Some basic tests are now present. They will be extended a little bit more.

• A thought with Update in mind: I would advocate for having a type level distinction for Queries and Updates (be it with a variant or different fields). With this distinction we can make sure that Updates and Queries are not confused. E.g. passing something in via /?query=... which actually is an Update. This might be helpful if one wants to restrict updates later on. It can also be done after parsing the queries, but I think doing it earlier is less error prone. The standard also don't specify this confusion of queries and updates.
• To my knowledge multiple graphs generally work but named graphs are not finished yet. default-graph-uri and named-graph-uri can be passed in via the HTTP request itself. Imo this lends itself to a follow-up PR now or some time later. The two parameters can be specified multiple times. Currently parameters can only be specified once due to the usage of a set. Then the parameters should of course also be processed.

[joka921]

This is starting to look really nice.
I still have some suggestions and some questions, but we are definitely getting there.

[joka921]

Okay, So this means that in HTTP there can be duplicate parameters in general, and the semantics depend on whatever the service does.
So probably, the value type of the parameters should not be string but HashSet<string> or something like this.
Then the consuming code (in this case the Server.cpp has to check, whiich of these can and cannot appear multiple times. At least add a comment in the respective code in the Parser, s.t. we can revisit it at a later time (I currently am working on the named graph support).

[Qup42]

The specs (RFC and similar) actually don't specify semantics for multiple values for a query parameter.
Probably a topic for the followup PR, but anyways: What would be the reason against simply using a multiset instead of a set here? Is it that abseil does not provide a multiset and we'd have to resort to std::multiset?
This comment is just a temporary note for me. For now I'd add some TODOs in appropriate places and warnings to the result if these parameters are used.

[joka921]

Only a small single comment left, address it and we are ready to merge.

[sonarcloud]

Quality Gate passed

Issues
5 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[joka921]

Thank you very much for improving the URL parser.