schema-based JSON deserializer: add
strict_timestamp_formatssetting (#4848)Motivation and Context
The schema-based
JsonDeserializerdoes not enforce@timestampFormat. Any JSON number is read as epoch seconds regardless of the member’s format, and a string for anepoch-secondsordate-timemember is parsed as an offset-awaredate-time. A server must answer such bodies with a 400SerializationException; the restJson1 protocol testsRestJsonBodyTimestamp{Default,DateTime,HttpDate}Rejects*(10 tests) require it.With the published
aws-smithy-json 0.63.0:
Member format Body Result default (epoch-seconds) {"plain":"1985-04-12T23:20:50Z"}accepted, should be rejected date-time{"dt":1515531081}accepted, should be rejected date-time{"dt":"1996-12-19T16:39:57-08:00"}accepted, should be rejected http-date{"hd":1515531081}accepted, should be rejected Clients rely on this tolerance, so it stays the default.
Description
JsonCodecSettingsgainsstrict_timestamp_formats(off by default). When enabled, a timestamp must use exactly the wire form its resolved format prescribes: a JSON number forepoch-seconds, an RFC 3339 string without a UTC offset fordate-time, an IMF-fixdate string forhttp-date. This mirrors the token-based parser’sexpect_timestamp_or_null, which the legacy server uses. Lenient behavior is unchanged.With the setting on, all values from the 10 protocol tests are rejected except
1515531081ABCand0x42inRestJsonBodyTimestampDefaultRejectsMalformedEpochSeconds, which are trailing-bytes cases handled by #4846.Independent of #4846 and #4847. All three bump
aws-smithy-jsonto 0.63.1; whichever merges later drops its bump commit on rebase.Testing
Unit tests per format in strict mode, plus a test that the default settings keep the current client behavior.
Checklist
- Changelog entry in
.changelog.
Co-authored-by: Landon James lnj@amazon.com
版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802047560号
Smithy Rust
Smithy code generators for Rust that generate clients, servers, and the entire AWS SDK. The latest unreleased SDK build can be found in aws-sdk-rust/next.
Design documentation
All internal and external interfaces are considered unstable and subject to change without notice.
Setup
./gradlewwill setup gradle for you. JDK 17 is required.Development
For development, pre-commit hooks make it easier to pass automated linting when opening a pull request. Setup:
Project Layout
aws: AWS specific codegen & Rust code (signing, endpoints, customizations, etc.) Common commands:./gradlew :aws:sdk:assemble: Generate (but do not test / compile etc.) a fresh SDK intosdk/build/aws-sdk./gradlew :aws:sdk:sdkTest: Generate & run all tests for a fresh SDK. (Note that these tests require Go to be installed for FIP support to compile properly)./gradlew :aws:sdk:{cargoCheck, cargoTest, cargoDocs, cargoClippy}: Generate & run specified cargo command.codegen-core: Common code generation logic useful for clients and serverscodegen-client: Smithy client code generationcodegen-client-test: Smithy protocol test generation & integration tests for Smithy client whitelabel codedesign: Design documentation. See the design/README.md for details about building / viewing.codegen-server: Smithy server code generationcodegen-server-test: Smithy protocol test generation & integration tests for Smithy server whitelabel codeexamples: A collection of server implementation examplesTesting
Running all of smithy-rs’s tests can take a very long time, so it’s better to know which parts to test based on the changes being made, and allow continuous integration to find other issues when posting a pull request.
In general, the components of smithy-rs affect each other in the following order (with earlier affecting later):
rust-runtimecodegenandcodegen-serveraws/rust-runtimeaws/codegen-aws-sdkSome components, such as
codegen-client-testandcodegen-server-test, are purely for testing other components.Testing
rust-runtimeandaws/rust-runtimeTo test the
rust-runtimecrates:To test the
aws/rust-runtimecrates:Some runtime crates have a
additional-ciscript that can also be run. These scripts often requirecargo-hackandcargo-udepsto be installed.Testing Client/Server Codegen
To test the code generation, the following can be used:
Several Kotlin unit tests generate Rust projects and compile them. When these fail, they typically output links to the location of the generated code so that it can be inspected.
To look at generated code when the codegen tests fail, check these paths depending on the test suite that’s failing:
codegen-client-test/build/smithyprojections/codegen-client-testcodegen-server-test/build/smithyprojections/codegen-server-testTesting SDK Codegen
See the readme in
aws/sdk/for more information about these targets as they can be configured to generate more or less AWS service clients.The generated SDK will be placed in
aws/sdk/build/aws-sdk.MSRV Policy
The MSRV (Minimum Supported Rust Version) for the crates in this project is
stable-2, i.e. the currentstableRust version and the prior two versions. Older versions may work. In rare circumstances our MSRV may exceedstable-2for security purposes (ex: to update a dependency for a security fix that requires an MSRV bump).Increasing the MSRV is treated as a minor change rather than a major (breaking) one, per Cargo’s SemVer guidance. The MSRV is not increased automatically; when we do increase it, each affected published crate is versioned accordingly:
1.xcrates are increased with a minor release (e.g.1.4.2→1.5.0), and0.xcrates are increased with a patch release (e.g.0.62.1→0.62.2).