Strange Content-Range header for search results

[chkalch]

Content-Range-Header can have a range-end that is larger than size.

According to RFC 7233 this is at least considered an error for byte-ranges:

A Content-Range field value is invalid if it contains [...] a complete-length value less than or equal to its last-byte-pos value.

This might not be the case for search-results but it looks like an error at first glance.

To Reproduce Search for resources so that the number of results is not dividable by page-size. Now go to last page and examine Content-Range.

An alternative way ist to create a resource:

curl 'http://localhost:8090/api/v1/dataresources/' -i -X POST \
    -H 'Content-Type: application/json' \
    -d '{
  "creators" : [ {
    "id" : null,
    "familyName" : "Doe",
    "givenName" : "John",
    "affiliations" : [ "Karlsruhe Institute of Technology" ]
  } ],
  "titles" : [ {
    "id" : null,
    "value" : "Most basic resource for testing",
    "titleType" : "OTHER",
    "lang" : null
  } ],
  "resourceType" : {
    "id" : null,
    "value" : "testingSample",
    "typeGeneral" : "DATASET"
  }
}'

Search for it (replace ID with the id from the result of the previous step):

curl 'http://localhost:8080/api/v1/dataresources/search' -i -X POST \
    -H 'Content-Type: application/json' \
    -d '{
  "id" : <ID>
}'

Now Content-Range will be 0-19/1, and range-end (19) is larger than size (1).

Expected behavior range-end less than size, for example 0-0/1 for the previous example.

Version (output of actuator/info)

{
"git": {
  "branch": "main",
  "commit": {
    "id": "4e90c6a",
    "time": "2023-07-31T11:21:49Z"
  }
  },
  "build": {
    "artifact": "base-repo",
    "name": "base-repo",
    "time": "2023-12-13T15:17:52.545Z",
    "version": "1.4.1-SNAPSHOT"
  }
}

[github-actions[bot]]

Branch issue-240-Strange_Content-Range_header_for_search_results created!

[ThomasJejkal]

Fix Summary: The created Content-Range header has been fixed to satisfy RFC 7233, i.e., let not exceed lastIndex the total number of elements and return HTTP 416 (RangeNotSatisfyable) in case unsatisfyable range requests are submitted. A special case was the situation, when no results are returned. While RFC 7233 is focussed on byte array submission, which will probably return HTTP 404 if nothing was found, in our case also empty result sets can be returned such that no start and end index can be provided. For that case, a Content-Range header with the value */0 will be returned and has to be properly evaluated.