The BitstreamRestController does not correctly calculate the etag and content-length HTTP header when a cover page is generated for a given file.
Here we can see that the original bitstream is always used for the calculation.
In case a cover page is generated the bitstream will be post-processed while both headers still will use the original stream. This can lead to unexpected behavior of the system if e.g. an incorrect content-length header is returned to the client.
Version: main branch
To Reproduce
Steps to reproduce the behavior:
Use an Item with an attached pdf.
Access the pdf via the bitstream controller (with cover page enabled/disabled)
Compare content-length and etag headers for both variants
Expected behavior
content-length and etag should be distinct when cover pages are enabled or disabled
Describe the bug
The BitstreamRestController does not correctly calculate the etag and content-length HTTP header when a cover page is generated for a given file.
Here we can see that the original bitstream is always used for the calculation.
In case a cover page is generated the bitstream will be post-processed while both headers still will use the original stream. This can lead to unexpected behavior of the system if e.g. an incorrect content-length header is returned to the client.
Version: main branch
To Reproduce Steps to reproduce the behavior:
Use an Item with an attached pdf. Access the pdf via the bitstream controller (with cover page enabled/disabled) Compare content-length and etag headers for both variants
Expected behavior
content-length and etag should be distinct when cover pages are enabled or disabled
Related work PR to fix the issue: https://github.com/DSpace/DSpace/pull/9666