getData fails to check for I/O errors

[RKrahl]

When the client requests the download of a dataset having more then one datafile using the getData call, ids.server will send a zip file in the body of the reply. Now if an I/O errors occurs while streaming this zip file, e.g. if the plugin fails to read one of the datafiles, the HTTP status of the response will still be ok (200), e.g. it will not indicate any error. However the zip file in the body will be corrupt.

[RKrahl]

This is a tricky one, because ids.server streams the zip in the response right away. E.g. it replies with a ZipOutputStream and thus creates the zip directly writing it in the HTTP reply stream. This is the right way to do it, because it results in the best performance. However, when an error occurs while assembling the reply, the HTTP status and the start of the zip file is already been written and cannot be changed anymore.

[RKrahl]

This is related to #79.