session: Purge epoch headers

Previously added `__NEOFS__NETMAP*` X-headers did not justify themselves:
 - no one has ever used them;
 - even if you try, it’s not clear how to work with them.

Data users operate with containers and objects, they are unaware and
uninterested in system time details. If an object is available, system
must be able to respond to them. Where and when exactly to look for data
is best known only to the storage system itself.

Closes #282.

Signed-off-by: Leonard Lyubich <leonard@morphbits.io>

object/service.proto

@@ -20,17 +20,6 @@ service ObjectService {
   // be restored by concatenation of object message payload and all chunks
   // keeping the receiving order.
   //
-  // Extended headers can change `Get` behaviour:
-  // * __NEOFS__NETMAP_EPOCH \
-  //   Will use the requsted version of Network Map for object placement
-  //   calculation.
-  // * __NEOFS__NETMAP_LOOKUP_DEPTH \
-  //   Will try older versions (starting from `__NEOFS__NETMAP_EPOCH` if specified or
-  //   the latest one otherwise) of Network Map to find an object until the depth
-  //   limit is reached.
-  //
-  // Please refer to detailed `XHeader` description.
-  //
   // Statuses:
   // - **OK** (0, SECTION_SUCCESS): \
   //   object has been successfully read;
@@ -54,13 +43,6 @@ service ObjectService {
   // object payload. All messages, except first one, SHOULD be payload chunks.
   // Chunk messages SHOULD be sent in the direct order of fragmentation.
   //
-  // Extended headers can change `Put` behaviour:
-  // * __NEOFS__NETMAP_EPOCH \
-  //   Will use the requsted version of Network Map for object placement
-  //   calculation.
-  //
-  // Please refer to detailed `XHeader` description.
-  //
   // Statuses:
   // - **OK** (0, SECTION_SUCCESS): \
   //   object has been successfully saved in the container;
@@ -161,16 +143,6 @@ service ObjectService {
   // restored by concatenation of all received payload chunks keeping the receiving
   // order.
   //
-  // Extended headers can change `GetRange` behaviour:
-  // * __NEOFS__NETMAP_EPOCH \
-  //   Will use the requsted version of Network Map for object placement
-  //   calculation.
-  // * __NEOFS__NETMAP_LOOKUP_DEPTH \
-  //   Will try older versions of Network Map to find an object until the depth
-  //   limit is reached.
-  //
-  // Please refer to detailed `XHeader` description.
-  //
   // Statuses:
   // - **OK** (0, SECTION_SUCCESS): \
   //   data range of the object payload has been successfully read;
@@ -194,16 +166,6 @@ service ObjectService {
   // length) tuples. Hashes order in response corresponds to the ranges order in
   // the request. Note that hash is calculated for XORed data.
   //
-  // Extended headers can change `GetRangeHash` behaviour:
-  // * __NEOFS__NETMAP_EPOCH \
-  //   Will use the requsted version of Network Map for object placement
-  //   calculation.
-  // * __NEOFS__NETMAP_LOOKUP_DEPTH \
-  //   Will try older versions of Network Map to find an object until the depth
-  //   limit is reached.
-  //
-  // Please refer to detailed `XHeader` description.
-  //
   // Statuses:
   // - **OK** (0, SECTION_SUCCESS): \
   //   data range of the object payload has been successfully hashed;

proto-docs/object.md

@@ -95,17 +95,6 @@ messages, except the first one, carry payload chunks. The requested object can
 be restored by concatenation of object message payload and all chunks
 keeping the receiving order.
 
-Extended headers can change `Get` behaviour:
-* __NEOFS__NETMAP_EPOCH \
-  Will use the requsted version of Network Map for object placement
-  calculation.
-* __NEOFS__NETMAP_LOOKUP_DEPTH \
-  Will try older versions (starting from `__NEOFS__NETMAP_EPOCH` if specified or
-  the latest one otherwise) of Network Map to find an object until the depth
-  limit is reached.
-
-Please refer to detailed `XHeader` description.
-
 Statuses:
 - **OK** (0, SECTION_SUCCESS): \
   object has been successfully read;
@@ -133,13 +122,6 @@ session package). Chunk messages are considered by server as a part of an
 object payload. All messages, except first one, SHOULD be payload chunks.
 Chunk messages SHOULD be sent in the direct order of fragmentation.
 
-Extended headers can change `Put` behaviour:
-* __NEOFS__NETMAP_EPOCH \
-  Will use the requsted version of Network Map for object placement
-  calculation.
-
-Please refer to detailed `XHeader` description.
-
 Statuses:
 - **OK** (0, SECTION_SUCCESS): \
   object has been successfully saved in the container;
@@ -256,16 +238,6 @@ Like in `Get` method, the response uses gRPC stream. Requested range can be
 restored by concatenation of all received payload chunks keeping the receiving
 order.
 
-Extended headers can change `GetRange` behaviour:
-* __NEOFS__NETMAP_EPOCH \
-  Will use the requsted version of Network Map for object placement
-  calculation.
-* __NEOFS__NETMAP_LOOKUP_DEPTH \
-  Will try older versions of Network Map to find an object until the depth
-  limit is reached.
-
-Please refer to detailed `XHeader` description.
-
 Statuses:
 - **OK** (0, SECTION_SUCCESS): \
   data range of the object payload has been successfully read;
@@ -293,16 +265,6 @@ applying XOR operation with the provided `salt`. Ranges are set of (offset,
 length) tuples. Hashes order in response corresponds to the ranges order in
 the request. Note that hash is calculated for XORed data.
 
-Extended headers can change `GetRangeHash` behaviour:
-* __NEOFS__NETMAP_EPOCH \
-  Will use the requsted version of Network Map for object placement
-  calculation.
-* __NEOFS__NETMAP_LOOKUP_DEPTH \
-  Will try older versions of Network Map to find an object until the depth
-  limit is reached.
-
-Please refer to detailed `XHeader` description.
-
 Statuses:
 - **OK** (0, SECTION_SUCCESS): \
   data range of the object payload has been successfully hashed;

proto-docs/session.md

@@ -285,18 +285,8 @@ Key name must be a unique valid UTF-8 string. Value can't be empty. Requests or
 Responses with duplicated header names or headers with empty values will be
 considered invalid.
 
-There are some "well-known" headers starting with `__NEOFS__` prefix that
-affect system behaviour:
-
-* __NEOFS__NETMAP_EPOCH \
-  Netmap epoch to use for object placement calculation. The `value` is string
-  encoded `uint64` in decimal presentation. If set to '0' or not set, the
-  current epoch only will be used.
-* __NEOFS__NETMAP_LOOKUP_DEPTH \
-  If object can't be found using current epoch's netmap, this header limits
-  how many past epochs the node can look up through. The `value` is string
-  encoded `uint64` in decimal presentation. If set to '0' or not set, only the
-  current epoch will be used.
+Headers with `__NEOFS__` prefix are reserved for system needs, regular clients
+should avoid using them.
 
 
 | Field | Type | Label | Description |

session/types.proto

@@ -137,18 +137,8 @@ message SessionToken {
 // Responses with duplicated header names or headers with empty values will be
 // considered invalid.
 //
-// There are some "well-known" headers starting with `__NEOFS__` prefix that
-// affect system behaviour:
-//
-// * __NEOFS__NETMAP_EPOCH \
-//   Netmap epoch to use for object placement calculation. The `value` is string
-//   encoded `uint64` in decimal presentation. If set to '0' or not set, the
-//   current epoch only will be used.
-// * __NEOFS__NETMAP_LOOKUP_DEPTH \
-//   If object can't be found using current epoch's netmap, this header limits
-//   how many past epochs the node can look up through. The `value` is string
-//   encoded `uint64` in decimal presentation. If set to '0' or not set, only the
-//   current epoch will be used.
+// Headers with `__NEOFS__` prefix are reserved for system needs, regular clients
+// should avoid using them.
 message XHeader {
   // Key of the X-Header
   string key = 1 [json_name = "key"];