You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ESRF ICAT+ API sometimes reports files that have zero length.
While a zero-length file is valid, it turns out that the ICAT+ interface uses this to report files for which there was some kind of non-trivial, persistent problem. In effect, these are files for which their data has been "lost".
The practical results is that any attempt to download such files trigger an 500 HTTP status code on the server. It is impossible to transfer such files.
As a practical work-around, it would be helpful if the ESRF DOI parser would filter out zero-length files.
More generally, it may be appropriate for the DOI parser to be extended to support reporting back that some files have been (in some sense) "lost" and cannot be copied.
The text was updated successfully, but these errors were encountered:
Short Description of the issue
The ESRF ICAT+ API sometimes reports files that have zero length.
While a zero-length file is valid, it turns out that the ICAT+ interface uses this to report files for which there was some kind of non-trivial, persistent problem. In effect, these are files for which their data has been "lost".
The practical results is that any attempt to download such files trigger an
500
HTTP status code on the server. It is impossible to transfer such files.As a practical work-around, it would be helpful if the ESRF DOI parser would filter out zero-length files.
More generally, it may be appropriate for the DOI parser to be extended to support reporting back that some files have been (in some sense) "lost" and cannot be copied.
The text was updated successfully, but these errors were encountered: