Uh oh!
There was an error while loading. Please reload this page.
reject empty values in a mutation request body - #628
Open
cportele wants to merge 2 commits into
Open
Conversation
A property element that is present but carries no value states an empty value. The GML decoder dropped it, so an empty value could not be told apart from an absent property anywhere downstream: it silently discarded what the document said, and a request that set a property to nothing looked like one that left it out. It is now decoded as an empty value, the way a JSON member with "" always was. Decoders can also reject such a value outright, for the input formats alike and without a second parse of the content: a new event handler wraps the handler a decoder emits to, next to the read-only one, and sees the values as the decoder resolved them, so an element that carries its value in xlink:href and one that states xsi:nil need no case of their own. A value the document omits, or states as null, does not reach the handler and is unaffected. The GML decoder no longer describes such a rejection as a parse failure — the document parsed, only the value was rejected.
The stream that decodes and encodes a mutation is run with join(), which wraps a failure in a CompletionException whose message is the cause's toString() — so every error reported for a failed action was prefixed with the class name of the exception behind it. How the stream is run is nobody else's business, so the wrapper no longer escapes the method that created it. A cause that is itself wrapped now also reaches the encoder-error translation, which turns a database or JSON parse failure into a message written for the client instead of relaying the raw one.
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of ldproxy/ldproxy#1767.
A property element that is present but carries no value states an empty value.
The GML decoder dropped it, so an empty value could not be told apart from an
absent property anywhere downstream: it silently discarded what the document
said, and a request that set a property to nothing looked like one that left it
out. It is now decoded as an empty value, the way a JSON member with "" always
was.
Decoders can also reject such a value outright, for the input formats alike and
without a second parse of the content: a new event handler wraps the handler a
decoder emits to, next to the read-only one, and sees the values as the decoder
resolved them, so an element that carries its value in xlink:href and one that
states xsi:nil need no case of their own. A value the document omits, or states
as null, does not reach the handler and is unaffected.
The GML decoder no longer describes such a rejection as a parse failure — the
document parsed, only the value was rejected.
In addition, this PR removes the exception class name in a feature mutation error message:
The stream that decodes and encodes a mutation is run with join(), which wraps
a failure in a CompletionException whose message is the cause's toString() —
so every error reported for a failed action was prefixed with the class name of
the exception behind it. How the stream is run is nobody else's business, so the
wrapper no longer escapes the method that created it.
A cause that is itself wrapped now also reaches the encoder-error translation,
which turns a database or JSON parse failure into a message written for the
client instead of relaying the raw one.