From ece8ce1cebe1e5804ce8b3282f88841dcdafb083 Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Thu, 15 Jul 2021 14:29:59 +0000 Subject: [PATCH] Update content of files --- data/core.telegram.org/api/errors.html | 41 ++++++++++++------------ data/core.telegram.org/api/invoking.html | 8 ++--- 2 files changed, 25 insertions(+), 24 deletions(-) diff --git a/data/core.telegram.org/api/errors.html b/data/core.telegram.org/api/errors.html index b97fb4dd60..11e7b48406 100644 --- a/data/core.telegram.org/api/errors.html +++ b/data/core.telegram.org/api/errors.html @@ -41,28 +41,27 @@

There will be errors when working with the API, and they must be correctly handled on the client.

An error is characterized by several parameters:

-

Error Code

+

Error Code

Numerical value similar to HTTP status. Contains information on the type of error that occurred: for example, a data input error, privacy error, or server error. This is a required parameter.

-

Error Type

+

Error Type

A string literal in the form of /[A-Z_0-9]+/, which summarizes the problem. For example, AUTH_KEY_UNREGISTERED. This is an optional parameter.

-

Error Constructors

+

Error Constructors

There should be a way to handle errors that are returned in rpc_error constructors.

Below is a list of error codes and their meanings:

-

303 SEE_OTHER

+

303 SEE_OTHER

The request must be repeated, but directed to a different data center.

-

Examples of Errors:

+

Examples of Errors:

-

In all these cases, the error description’s string literal contains the number of the data center (instead of the X) to which the repeated query must be sent. -More information about redirects between data centers »

-

400 BAD_REQUEST

+

In all these cases, the error description’s string literal contains the number of the data center (instead of the X) to which the repeated query must be sent.
More information about redirects between data centers »

+

400 BAD_REQUEST

The query contains errors. In the event that a request was created using a form and contains user generated data, the user should be notified that the data must be corrected before the query is repeated.

-

Examples of Errors:

+

Examples of Errors:

-

401 UNAUTHORIZED

+

401 UNAUTHORIZED

There was an unauthorized attempt to use functionality available only to authorized users.

-

Examples of Errors:

+

Examples of Errors:

-

403 FORBIDDEN

+

403 FORBIDDEN

Privacy violation. For example, an attempt to write a message to someone who has blacklisted the current user.

-

404 NOT_FOUND

+

404 NOT_FOUND

An attempt to invoke a non-existent object, such as a method.

-

406 NOT_ACCEPTABLE

+

406 NOT_ACCEPTABLE

Similar to 400 BAD_REQUEST, but the app should not display any error messages to user in UI as a result of this response. The error message will be delivered via updateServiceNotification instead.

-

420 FLOOD

+

420 FLOOD

The maximum allowed number of attempts to invoke the given method with the given input parameters has been exceeded. For example, in an attempt to request a large number of text messages (SMS) for the same phone number.

-

Error Example:

+

Error Example:

-

500 INTERNAL

+

500 INTERNAL

An internal server error occurred while a request was being processed; for example, there was a disruption while accessing a database or file storage.

If a client receives a 500 error, or you believe this error should not have occurred, please collect as much information as possible about the query and error and send it to the developers.

-

Other Error Codes

-

If a server returns an error with a code other than the ones listed above, it may be considered the same as a 500 error and treated as an internal server error.

+

Other Error Codes

+

If a server returns an error with a code other than the ones listed above, it may be considered the same as a 500 error and treated as an internal server error.

+ diff --git a/data/core.telegram.org/api/invoking.html b/data/core.telegram.org/api/invoking.html index 01d931a421..26d0501904 100644 --- a/data/core.telegram.org/api/invoking.html +++ b/data/core.telegram.org/api/invoking.html @@ -46,7 +46,7 @@

The need to add a new object constructor or to add/remove a field in a constructor creates a backwards compatibility problem for previous versions of API clients. After all, simply changing a constructor in a schema also changes its number. To address this problem, each schema update is separated into a layer.
A layer is a collection of updated methods or constructors in a TL schema. Each layer is numbered with sequentially increasing numbers starting with 2. The first layer is the base layer — the TL schema without any changes.

There is helper method to let the API know that a client supports Layer layer:

invokeWithLayer#da9b0d0d {X:Type} layer:int query:!X = X;
-

The helper method invokeWithLayer can be used only together with initConnection: the present layer will be saved with all other parameters of the client and future calls will be using this saved value. See more below..

+

The helper method invokeWithLayer can be used only together with initConnection: the present layer will be saved with all other parameters of the client and future calls will be using this saved value. See more below.

List of Available Layers

Saving Client Info

It is possible to save information about the current client on the server in conjunction with an authorization key. This may help eliminate client-side problems with certain releases on certain devices or with certain localizations, as well as eliminate the need for sending layer information in each call.

@@ -62,8 +62,8 @@

invokeAfterMsg#cb9f372d {X:Type} msg_id:long query:!X = X;
invokeAfterMsgs#3dc4b4f0 {X:Type} msg_ids:Vector<long> query:!X = X;

-

They may be used, for example, if a client attempts to send accumulated messages after the Internet connection has been restored after being absent for a long time. In this case, the 32-bit number 0xcb9f372d must be added before the method number in each call, followed by a 64-bit message identifier, msg_id, which contains the previous call in the queue.
The second method is similar, except it takes several messages that must be waited for.

-

If the waiting period exceeds 0.5 seconds (this value may change in the future) and no result has appeared, the method will return the 400 MSG_WAIT_TIMEOUT error.

+

They may be used, for example, if a client attempts to send accumulated messages after the Internet connection has been restored after being absent for a long time. In this case, the 32-bit number 0xcb9f372d must be added before the method number in each call, followed by a 64-bit message identifier, msg_id, which contains the previous request in the queue.
The second method is similar, except it takes several messages that must be waited for.

+

If the waiting period exceeds 0.5 seconds (this value may change in the future) and no result has appeared, the method will be executed just the same." => "If the waiting period exceeds 0.5 seconds (this value may change in the future) and no result has appeared, the method will return the 400 MSG_WAIT_TIMEOUT error.

Helper Method Sequence

Important: if the helper methods invokeAfterMsg / invokeAfterMsgs are used together with invokeWithLayerN or other helper methods, invokeAfterMsg / invokeAfterMsgs must always be the outermost wrapper.

Data Compression

@@ -73,7 +73,7 @@

Before transmitting a query, the string containing the entire body of the serialized high-level query (starting with the method number) must be compressed using gzip. If the resulting string is smaller than the original, it makes sense to transmit the gzip_packed constructor.

There is no point in doing the above when transmitting binary multimedia data (photos, videos) or small messages (up to 255 bytes).

Uncompressing Data

-

By default, the server compresses the response to any call as well as updates, in accordance with the rules stated above. If the gzip_packed constructor is received as a response in rpc_result, then the string that follows must be extracted and uncompressed. Processing then continues on the resulting new string.

+

By default, the server compresses the response to any request as well as updates, in accordance with the rules stated above. If the gzip_packed constructor is received as a response in rpc_result, then the string that follows must be extracted and uncompressed. Processing then continues on the resulting new string.