Files¶
Uploading files¶
A file is uploaded to an entry with graph type None (a local information resource) using a PUT request on the entry's resource URI:
PUT http://{host}/store/{context}/resource/{entryId}
The file can either be sent as the raw request body or as a file part of a multipart/form-data request. The raw body is stored with the media type given in the parameter mimeType, or else in the Content-Type header, and the filename of an optional Content-Disposition header. A multipart request may carry any part name: a part named file is used when it carries a filename, otherwise the first part carrying a filename, otherwise the first part carrying content. An optional part mimeType overrides the media type of the file part.
The upload requires write access to the resource. The request body is only read after the access check.
Upload limits¶
The maximum size of an uploaded file is configured in entrystore.properties:
entrystore.data.max-file-size=bytes[unit] (default: 1G, -1 for no limit)
The units k, M, G and T are powers of 1024. Larger uploads are answered with 413 and the previously stored file of the entry is kept. The limit only applies to uploads; files that are already stored, including larger ones, remain readable and are exported and backed up as before. The context quota is checked as well.
A raw request body is streamed into the data folder, so the limit also applies to bodies without Content-Length. Multipart uploads are written to temporary files in spring.servlet.multipart.location (by default a directory below java.io.tmpdir) before they are stored. The multipart size limits spring.servlet.multipart.max-file-size and spring.servlet.multipart.max-request-size default to -1B (no limit). A request whose Content-Length exceeds them is answered with 413; a body that exceeds them while it is being sent may end in a connection reset instead. A multipart request to a route that does not accept uploads is answered with 415.
While an upload is in progress it is written to a hidden file .<uuid>.part next to the data file. These files are skipped by context export, backup and import, and leftover files are deleted at startup. An upload that fails or is rejected midway leaves the previously stored file intact.
EntryStore 5.x
In 5.x entrystore.data.max-file-size has no default, i.e. the file size is not limited unless configured. An upload that fails midway or exceeds the quota may leave the entry without its previous file. See Upgrading from 5.x to 6.x.
Downloading files¶
A file is downloaded with a GET request on the entry's resource URI. It is served with Content-Disposition: inline and its filename, so that browsers can display it. With the parameter download the response uses Content-Disposition: attachment instead. Inline delivery can be disabled for all files with the following setting:
entrystore.http.allow-content-disposition-inline=true|false (default: true)
Range requests are supported. Responses carry Last-Modified and ETag headers and can be revalidated, see HTTP caching and formats.
Checksum¶
Starting with EntryStore 5.1, every document uploaded will have a hashcode. This can be used to verify that the uploaded document is not corrupted.
The hashcode is included as Digest header (e.g. Digest: sha-256=<hex>) in the HTTP response when accessing a resource/file using the following URL pattern:
GET http://{host}/store/{context}/resource/{entryId}
It is also included as resource.sha256 in the resource's entry information object, which can be accessed using the following URL pattern:
GET http://{host}/store/{context}/entry/{entryId}?includeAll
The hashcode is generated using SHA-256 and is stored together with the uploaded file with the extension .sha256.
Any document created before version 5.1 will not have this hashcode. You can remedy this by re-uploading the document.