diff --git a/data/web/corefork.telegram.org/api/config.html b/data/web/corefork.telegram.org/api/config.html index 08f45df873..ecf8e68fba 100644 --- a/data/web/corefork.telegram.org/api/config.html +++ b/data/web/corefork.telegram.org/api/config.html @@ -352,9 +352,9 @@ While help.getConfig returns MTProto-specif

caption_length_limit_premium

The maximum UTF-8 length of media captions sendable by non-Premium users (integer)

upload_max_fileparts_default

-

The maximum size of files uploadable by non-Premium users (integer, indicates the number of 512kb file parts, so the size in bytes is determined by multiplying by 524288)

+

The maximum number of file parts uploadable by non-Premium users (integer, the maximum file size can be extrapolated by multiplying this value by 524288, the biggest possible chunk size))

upload_max_fileparts_premium

-

The maximum size of files uploadable by Premium users (integer, indicates the number of 512kb file parts, so the size in bytes is determined by multiplying by 524288)

+

The maximum number of file parts uploadable by Premium users (integer, the maximum file size can be extrapolated by multiplying this value by 524288, the biggest possible chunk size))

about_length_limit_default

The maximum UTF-8 length of bios of non-Premium users (integer)

about_length_limit_premium

diff --git a/data/web/corefork.telegram.org/api/files.html b/data/web/corefork.telegram.org/api/files.html index b3128e05f5..f33dec8230 100644 --- a/data/web/corefork.telegram.org/api/files.html +++ b/data/web/corefork.telegram.org/api/files.html @@ -74,17 +74,19 @@ upload.saveFilePart#b304a621 file_id:long file_part:int bytes:bytes = Bool; upload.saveBigFilePart#de7b673d file_id:long file_part:int file_total_parts:int bytes:bytes = Bool;

Before transmitting the contents of the file itself, the file has to be assigned a unique 64-bit client identifier: file_id.

-

The file's binary content is then split into parts. All parts must have the same size ( part_size ) and the following conditions must be met:

+

The file's binary content is then split into parts. All parts must have the same size (part_size) and the following conditions must be met:

The last part does not have to satisfy these conditions, provided its size is less than part_size.

-

Each part should have a sequence number, file_part, with a value ranging from 0 to the value of one of the following appConfig fields minus 1:

+

The following appConfig fields specify the maximum number of uploadable file parts:

+

Note that the limit of uploadable file parts does not account for the part_size: thus the total file size limit can only be reached with the biggest possible part_size of 512KB, which is actually the recommended part_size to avoid excessive protocol overhead.

+

Each part should have a sequence number, file_part, with a value ranging from 0 to the value of the appropriate config parameter minus 1.

After the file has been partitioned you need to choose a method for saving it on the server. Use upload.saveBigFilePart in case the full size of the file is more than 10 MB and upload.saveFilePart for smaller files.

Each call saves a portion of the data in a temporary location on the server to be used later. The storage life of each portion of data is between several minutes and several hours (depending on how busy the storage area is). After this time, the file part will become unavailable. To increase the time efficiency of a file save operation, we recommend using a call queue, so X pieces of the file are being saved at any given moment in time. Each successful operation to save a part invokes the method call to save the next part. The value of X can be tuned to achieve maximum performance.

When using one of the methods mentioned above to save file parts, one of the following data input errors may be returned:

@@ -96,7 +98,7 @@
  • FILE_PART_SIZE_INVALID - 512KB cannot be evenly divided by part_size
  • FILE_PART_SIZE_CHANGED - The part size is different from the size of one of the previous parts in the same file
    • -

    While the parts are being uploaded, an MD5 hash of the file contents can also be computed to be used later as the md5_checksum parameter in the inputFile constructor (since it is checked only by the server, for encrypted secret chat files it must be generated from the encrypted file). +

    While the parts are being uploaded, an MD5 hash of the file contents can also be computed to be used later as the md5_checksum parameter in the inputFile constructor (since it is checked only by the server, for encrypted secret chat files it must be generated from the encrypted file).
    After the entire file is successfully saved, the final method may be called and passed the generated inputFile object. In case the upload.saveBigFilePart method is used, the inputFileBig constructor must be passed, in other cases use inputFile.