Compressed attachments are being returned with the uncompressed length in the first 8 bytes

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enable storage compression in your config
2. Add an attachment
3. Access the attachment via the /compressed-data endpoint

What is the expected output? What do you see instead?
The data should be returned as the attachment in a valid deflate byte stream.  
The
8 byte uncompressed length is currently being returned in front of the deflate 
stream
which is non standard and would require that the client be aware of this.  If 
the client
is a web browser, there is no way to workaround this.

What version of the product are you using? On what operating system?
0.8.2 on windows

Please provide any additional information below.
I have added code to set the HTTP Header Encoding:deflate for the 
compressed-data endpoint
to take advantage of the browser's ability to natively decompress the data.  
The browser properly decodes the
deflate byte stream if I skip the 8 bytes before returning it.

Original issue reported on code.google.com by cha...@gmail.com on 9 Sep 2014 at 4:19

[GoogleCodeExporter]

The "/compressed-data" endpoint is used to access the raw data, as stored by 
Orthanc on the filesystem after compression (it is enabled). The internal 
structure of this data is totally opaque and should not be interpreted by the 
user, as other compression methods could be introduced in future versions of 
Orthanc (e.g. bzip2 or snappy).

The reason "/compressed-data" and "/compressed-md5" exist is for system daemons 
to be able to detect possible disk corruption.

To summarize, do not try and parse "/compressed-data".

Original comment by s.jodo...@gmail.com on 11 Sep 2014 at 12:27

• Changed state: Invalid

[GoogleCodeExporter]

There are huge performance and scalability benefits if you can stream a 
compressed data stream directly from disk to the web browser.  To do this, the 
data needs to be compressed in a format that a web browser can decompress - 
either gzip or deflate.  I understand that this use case was not the intention 
of /compressed-data, but addressing this use case is worth considering.  I will 
create a card for this on the trello, thanks

Original comment by cha...@gmail.com on 11 Sep 2014 at 1:18