Quality digital preservation software will ignore file extensions and file
names for file type identification and use JHOVE or similar.

Cheers
Stuart

On Tuesday, April 25, 2017, Benedikt Kroll <[log in to unmask]>
wrote:

> 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.
>>>>>
>>>>>
>>>>

-- 
--
...let us be heard from red core to black sky