HTTP OPTIONS request returns invalid content

[subotic]

SIPI seems to return a redundant CRLF (\r\n) upon HTTP OPTIONS request. Since the OPTIONS response should have a content length of 0, this is invalid behaviour. As such, Traefik logs an error whenever such an OPTIONS request to SIPI occurs. The error is not critical though and does not seem affect the functionality of anything.

Example logs can be found here: https://app.datadoghq.eu/logs?query=host%3Adasch-dsp-prod-01%20service%3Atraefik%20%20%20%20%20%28%28options%20AND%20dsp-iiif%40docker%29%20OR%20unsolicited%29&cols=host%2Cservice&index=&messageDisplay=inline&stream*sort=time%2Cdesc&viz=stream&from_ts=1667372378119&to_ts=1667375452917&live=false

The error can be reproduced with the following example cURL call:

-H "accept: /"
-H "accept-encoding: gzip, deflate, br"
-H "accept-language: en-GB,en-US;q=0.9,en;q=0.8,de;q=0.7"
-H "access-control-request-headers: content-type"
-H "access-control-request-method: GET"
-H "origin: https://admin.test.dasch.swiss"
-H "referer: https://admin.test.dasch.swiss/"
-H "sec-fetch-dest: empty"
-H "sec-fetch-mode: cors"
-H "sec-fetch-site: same-site"
https://iiif.test.dasch.swiss/0801/CMvHll1RiUJ-GHuNz2N2SH4.jpx/knora.json```

However, the returned invalid data cannot be seen via cURL because it just ignores it. It can be captured through tcpdump (sudo tcpdump -i any -c50 -nn -w sipidump.pcap port 1024) and viewed in Wireshark:

First, SIPI sends the correct response headers and trailing CRLF separating the header and content.
but then also the additional invalid CRLF (0x0d 0x0a), which shouldn’t exist because the content length should be 0.

[subotic]

@lrosenth This would also need a look from you.