Skip to content
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

How to deserialize optional @httpPayload-bound shapes? #2311

Open
david-perez opened this issue Jun 6, 2024 · 0 comments
Open

How to deserialize optional @httpPayload-bound shapes? #2311

david-perez opened this issue Jun 6, 2024 · 0 comments
Labels
client This issue involves the specification for client software. protocol-test New protocol tests are needed server This issue involves the specification for server software.

Comments

@david-perez
Copy link
Contributor

I already raised this to some extent in:

The problem is how to deserialize something like:

structure OperationBoundInput {
    @httpPayload
    message: String
}

It is unclear, if the user doesn't provide a value for message in the HTTP body, whether a server should deserialize message as None or as "".

Note that the HTTP RFC differentiates between HTTP messages with no body (no Content-Length or Transfer-Encoding header) and HTTP messages with an empty body (Content-Length: 0). This is only the case for requests.

For response messages, whether or not a message-body is included with a message is dependent on both the request method and the response status code (section 6.1.1)

So we could use that distinction to deserialize one way or another, but I think the UX would be confusing and the implementation prone to bugs.

A much simpler possibility is if we enforced @httpPayload to be coupled with @required or @default when the target of the member shape is a simple shape type. This would be in accordance with the decision that was taken in IDL v2 for @streaming blob shapes.

If the target member shape is an aggregate type, protocols' serialization formats should have "enclosing tokens" to delimit the aggregate data (e.g. {} in JSON), so we could ascribe the absence of those markers to deserialization as None.

@kstich kstich added protocol-test New protocol tests are needed client This issue involves the specification for client software. server This issue involves the specification for server software. labels Nov 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client This issue involves the specification for client software. protocol-test New protocol tests are needed server This issue involves the specification for server software.
Projects
None yet
Development

No branches or pull requests

2 participants