Skip to content

CR 1.9 Mechanism to specify HTTP RFC 2616 section 14 Headers 14.35 Range and 14.16 Content Range

Leah Prescott edited this page May 28, 2014 · 1 revision

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16 Content Range

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35 Range

It is common practice to 'cat' multiple files into one larger files for a variety of reasons. Some file formats do this (WARC?). Other times this is done because of particularities of the underlying storage mechanism are optimized for physical files of a certain size. In these cases, the file we are describing may actually be split across two physical files.

In these cases, byte ranges need to be recorded in addition to the xlink:href. If these files are sitting in a modern apache server, HTTP headers can be specified to retrieve the "real" file out of the concatenated file.

METS needs some mechanism in FLocat to record information sufficient for a developer to be able to generate the headers needed to get the file that is being described by the METS document.



Also, what about headers that would influence content negotiation of the xlink:href; should these be supported somehow as well? Maybe we need a generic header mechanism?

https### _4922663812``://github.com/mets/METS-board.wiki.git

Clone this wiki locally