b2_upload_file

An upload authorization token obtained from b2_get_upload_url.

The name of the file, in percent-encoded UTF-8. For example, spaces should be replaced with %20. For more information, see Files for requirements on file names and String Encoding for how to encode strings.

The MIME type of the content of the file, which will be returned in the Content-Type header when downloading the file. Use the Content-Type b2/x-auto to automatically set the stored Content-Type post upload. In the case where a file extension is absent or the lookup fails, the Content-Type is set to application/octet-stream. The Content-Type mappings can be perused here.

The number of bytes in the file being uploaded.

Note: Chunked transfer encoding, which allows the Content-Length header to be omitted, is not supported.

When sending the SHA1 checksum at the end, the Content-Length should be set to the size of the file plus the 40 bytes of hex checksum.

The SHA1 checksum of the content of the file. B2 will check this when the file is uploaded, to make sure that the file arrived correctly. It will be returned in the X-Bz-Content-Sha1 header when the file is downloaded.

You may optionally provide the SHA1 at the end of the upload. See the section on Uploading.

If the original source of the file being uploaded has a last modified time concept, Backblaze recommends using this spelling of one of your X-Bz-Info-* headers (see below). Using a standard spelling allows different B2 clients and the B2 web user interface to interoperate correctly. The value should be a base 10 number which represents a UTC time when the original source file was last modified. It is a base 10 number of milliseconds since midnight, January 1, 1970 UTC. This fits in a 64 bit integer such as the type "long" in the programming language Java. It is intended to be compatible with Java's time long. For example, it can be passed directly into the Java call Date.setTime(long time).

If this is present, B2 will use it as the value of the 'Content-Disposition' header when the file is downloaded (unless it's overridden by a value given in the download request). The value must match the grammar specified in RFC 6266. Parameter continuations are not supported. 'Extended-value's are supported for charset 'UTF-8' (case-insensitive) when the language is empty. Note that this file info will not be included in downloads as a x-bz-info-b2-content-disposition header. Instead, it (or the value specified in a request) will be in the Content-Disposition.

If this is present, B2 will use it as the value of the 'Content-Language' header when the file is downloaded (unless it's overridden by a value given in the download request). The value must match the grammar specified in RFC 2616. Note that this file info will not be included in downloads as a x-bz-info-b2-content-language header. Instead, it (or the value specified in a request) will be in the Content-Language header.

If this is present, B2 will use it as the value of the 'Expires' header when the file is downloaded (unless it's overridden by a value given in the download request). The value must match the grammar specified in RFC 2616. Note that this file info will not be included in downloads as a x-bz-info-b2-expires header. Instead, it (or the value specified in a request) will be in the Expires header.

If this is present, B2 will use it as the value of the 'Cache-Control' header when the file is downloaded (unless it's overridden by a value given in the download request), and overriding the value defined at the bucket level. The value must match the grammar specified in RFC 2616. Note that this file info will not be included in downloads as a x-bz-info-cache-control header. Instead, it (or the value specified in a request) will be in the Cache-Control header.

If this is present, B2 will use it as the value of the 'Content-Encoding' header when the file is downloaded (unless it's overridden by a value given in the download request). The value must match the grammar specified in RFC 2616. Note that this file info will not be included in downloads as a x-bz-info-b2-content-encoding header. Instead, it (or the value specified in a request) will be in the Content-Encoding header.

The * part of the header name is replaced with the name of a custom field in the file information stored with the file, and the value is an arbitrary UTF-8 string, percent-encoded. The same info headers sent with the upload will be returned with the download. The header name is case insensitive.

If this is present, B2 will use it as the value of the upload timestamp. The value should be a base 10 number that represents a UTC time when the original source file was uploaded. It is a base 10 number of milliseconds since midnight, January 1st, 1970 UTC. This fits in a 64-bit integer, such as the type long in Java, and so it can be passed directly into the Java call Date.setTime(long time). The value must not use a date that is set to a time in the future.

Note: The timestamp should not interfere with the bucket lifecycle rules.

For example, if the timestamp created during upload is older than the time specified in the daysFromUploadingToHiding lifecycle rules field, the upload will result in a 400 error. A conflict between the timestamp and a lifecycle rule, such as daysFromHidingToDeleted, may also result in a file being deleted as soon as it is uploaded.

If this is present, specifies the Object Lock legal hold status for the file. Valid values for this header are on and off. Setting the value requires the writeFileLegalHolds capability and that the bucket is Object Lock-enabled.

If this is present, specifies the Object Lock retention mode for the file. Valid values for this header are governance and compliance. Setting the value requires the writeFileRetentions capability and that the bucket is Object Lock-enabled.

If this header is present, then a valid X-Bz-File-Retention-Retain-Until-Timestamp header must be present as well.

If this is present, specifies a Object Lock retention timestamp in the future, after which the intended Object Lock will expire. This header value must be specified as a base 10 number of milliseconds since midnight, January 1, 1970 UTC. Setting the value requires the writeFileRetentions capability and that the bucket is Object Lock-enabled.
If this header is present, then a valid X-Bz-File-Retention-Mode header must be present as well.

If this is present, B2 will encrypt the uploaded data before storing the file using Server-Side Encryption with Backblaze-Managed Keys (SSE-B2) with the algorithm specified in this header. Currently, the only supported value for this header is AES256.

This header must not be present if SSE-C headers (X-Bz-Server-Side-Encryption-Customer-*, see below) are included with this request, and vice versa.

If this is present, B2 will encrypt the uploaded data before storing the file using Server-Side Encryption with Customer-Managed Keys (SSE-C) with the algorithm specified in this header. Currently, the only supported value for this header is AES256.

If this is present, it specifies the base64-encoded encryption key for Backblaze B2 to use in encrypting data with Server-Side Encryption with Customer-Managed Keys (SSE-C). The value of the header is used to store the file and then is immediately discarded. The key must be appropriate for use with the algorithm specified in the X-Bz-Server-Side-Encryption-Customer-Algorithm header.

If this is present, it specifies the base64-encoded 128-bit MD5 digest of the encryption key to be used with Server-Side Encryption with Customer-Managed Keys (SSE-C). Backblaze B2 uses this header to verify that the encryption key was transmitted correctly.