That would work, but I'm rather trying to find out whether digital 
preservation softwares have problems with service-style URLs for 
bitstreams in general. Because if that is the case, it could be relevant 
for the further development of the (open source) repository software we 
are using.



Am 24.04.2017 um 13:15 schrieb Andreas Orphanides:
> Here's a silly idea that maybe runs the risk of rushing to a solution
> without actually addressing the core question... could you set up a proxy
> that provides a URL ending in the correct filename?
>
> On Mon, Apr 24, 2017 at 4:28 AM, Benedikt Kroll <
> [log in to unmask]> wrote:
>
>> 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.
>>>>
>>>