So this happend when trying to ingest a file to the longterm archive 
from a repository:

The repository's bitstream URL for a PDF file did not end on .pdf, but 
the mimetype was sent correctly. So the URL looked like 
https://test/bitstream/id/123456 The preservation system (a commercial 
product) did not accept this bitstream URL as part of an OAI harvesting 
response.

The error message was that the bitstream URL must contain a valid file 
name and must end with an extension according to its mime type. So the 
expected URL would need to look like https://test/bitstream/123456.pdf

This would mean that using this preservation system, we will not be able 
to harvest from a repository that uses service endpoints, not regular 
file links to deliver bitstreams.

I'm trying to find out whether it is common behaviour for preservation 
systems to require file URLs rather than service URLs to ingest 
bitstreams. Any experience on how preservation software you use handles 
this detail would be appreciated!

Thanks!
Benedikt



Am 21.04.2017 um 18:46 schrieb Cary Gordon:
> Could you be a bit more specific about the issue you encountered?
>
> Thanks,
>
> Cary
>
> Cary Gordon
> The Cherry Hill Company
> http://chillco.com
>
>> On Apr 21, 2017, at 12:53 AM, Benedikt Kroll <[log in to unmask]> wrote:
>>
>> We run into a situation where this occured, and I'm trying to find out what other preservation software also do this – and if so, maybe also get to know why this check is done.