-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate type for object header #652
Comments
I always did not understand why there is no header while IMO it is a natural understanding for our HEAD operation and objects in general: every object has a header and every object has a payload. Sometimes we need only a header and vice versa. I have not opened any issues about it. |
Yeah, we need this type, passing |
signature is not a part of header itself https://github.com/nspcc-dev/neofs-api/blob/e66b25d4bf2afc4472023e1e2c2467f694f5a0e1/object/types.proto#L226, so it's transmitted beside https://github.com/nspcc-dev/neofs-api/blob/e66b25d4bf2afc4472023e1e2c2467f694f5a0e1/object/service.proto#L462 |
Header, SignedHeader, Object? |
|
It's so tempting for me to make it a method with cached internal value ( |
cached values are often a source of errors. I would stick with simple tuples with open logic
https://pkg.go.dev/github.com/nspcc-dev/neofs-sdk-go/object#Object.MarshalHeaderJSON is what i remember. https://github.com/nspcc-dev/neo-go/blob/5f92da21fa43e4fe80fb965c78d5d244b6003ffd/pkg/services/oracle/neofs/neofs.go#L185. The various tuples can be used:
and i remember no usecase where we need (ID, signature, header) tuple finally, for now i see |
it must be noted that transition to the heading types must be carried out carefully. For example, ALSO!!!: do not forget about field numbers. |
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Closes #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. Request/response signing and verification functions have been added to `crypto` package A. They are used by the API client and will also be used by https://github.com/nspcc-dev/neofs-node. 3. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 4. Test binaries/JSONs/signatures that followed the erroneous behavior of p.3 are fixed. 5. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. API client unit tests and AIO integration ones PASS, therefore, there is no more way to track more regressions for now. If problems arise in apps when updating the lib, fixes will be added later before the major release. Closes #214. Refs #226. Refs #270. Closes #452. Refs #532. Closes #551 (it's almost impossible to do now). Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 3. Test binaries/JSONs/signatures that followed the erroneous behavior of p.2 are fixed. 4. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. NOTE: `client` package is going to be changed the same way in the following commits. NOTE 2: some tests panic due to protobuf namespace conflict, which will be fixed automatically after the move is complete. Closes #214. Refs #226. Refs #532. Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Since 527c964, proto-generated code is located in the current code library. Previously, the neofs-api-go module's code was used for protocol interactions. In essence, it is a super-layer on top of the `google.golang.org/protobuf` module with only one feature: stable marshalling (Protocol Buffers with ascending field order). Since it is now provided by local `proto/*` packages, there is no longer a need for a separate module. In addition to trimming the code base and refactoring, a bonus is the allocation of fewer intermediate Go objects, which will have a beneficial effect on runtime. Although most of the changes are refactorings, the following changes have been applied: 1. All exported elements that depended on neofs-api-go types are permanently removed. They could not be excluded via a temporary deprecation mark as this would cause a conflict with importing ''*.pb.go' files. Such elements were not recommended for use in advance, so most of the updated software will not suffer from breakages. 2. `neofs-api-go` a bug with interpreting enums as unsigned numbers, while protobuf lib decodes them into `~int32`. In addition, during encoding/decoding, all unknown enum values were set to zero, which could lead to data loss. This commit fixes both issues. Separating the fix from the refactoring would have required adding artificial buggy code, it was decided not to generate it. 3. Test binaries/JSONs/signatures that followed the erroneous behavior of p.2 are fixed. 4. While replacement of `ReadFromV2` methods called `FromProtoMessage`, `ProtoMessage` method replacing `WriteToV2`, taking into account the proposal from #532 and existing use cases, now dynamically allocates the message structure. NOTE: `client` package is going to be changed the same way in the following commits. NOTE 2: some tests panic due to protobuf namespace conflict, which will be fixed automatically after the move is complete. Closes #214. Refs #226. Refs #532. Fixes #606. Refs #652. Signed-off-by: Leonard Lyubich <[email protected]>
Is your feature request related to a problem? Please describe.
currently,
object
providesObject
structure type, but noHeader
one. This type would be helpful for HEAD ops (Client
, node storage, etc.). Now such ops return instances of theObject
type with unset payload field. I see following drawbacks in this approach:Describe the solution you'd like
Additional context
iirc @carpawell had questions why there is no header type. I couldnt find any issue, pls share if smth already exists
The text was updated successfully, but these errors were encountered: