@@ -13716,6 +13717,120 @@ Cha Fix examples +RFC: File-per-change changelog + +Status: RFC +Applies to: client and server + +For a summarized list of proposed changes, see the Changes Checklist section. +Historically, the smithy-rs and AWS SDK for Rust's changelogs and release notes have been +generated from the changelogger tool in tools/ci-build/changelogger. This is a tool built +specifically for development and release of smithy-rs, and it requires developers to add +changelog entries to a root CHANGELOG.next.toml file. Upon release, the [[smithy-rs]] entries +in this file go into the smithy-rs release notes, and the [[aws-sdk-rust]] entries are associated +with a smithy-rs release commit hash, and added to the aws/SDK_CHANGELOG.next.json for +incorporation into the AWS SDK's changelog when it releases. +This system has gotten us far, but it has always made merging PRs into main more difficult +since the central CHANGELOG.next.toml file is almost always a merge conflict for two PRs +with changelog entries. +This RFC proposes a new approach to change logging that will remedy the merge conflict issue, +and explains how this can be done without disrupting the current release process. +The proposed developer experience +There will be a changelog/ directory in the smithy-rs root where +developers can add changelog entry Markdown files. Any file name can be picked +for these entries. Suggestions are the development branch name for the +change, or the PR number. +The changelog entry format will change to make it easier to duplicate entries +across both smithy-rs and aws-sdk-rust, a common use-case. +This new format will make use of Markdown front matter in the YAML format. +This change in format has a couple benefits: + +It's easier to write change entries in Markdown than in a TOML string. +There's no way to escape special characters (such as quotes) in a TOML string, +so the text that can be a part of the message will be expanded. + +While it would be preferable to use TOML for the front matter (and there are libraries +that support that), it will use YAML so that GitHub's Markdown renderer will recognize it. +A changelog entry file will look as follows: +--- +# Adding `aws-sdk-rust` here duplicates this entry into the SDK changelog. +applies_to: ["client", "server", "aws-sdk-rust"] +authors: ["author1", "author2"] +references: ["smithy-rs#1234", "aws-sdk-rust#1234"] +# The previous `meta` section is broken up into its constituents: +breaking: false +# This replaces "tada": +new_feature: false +bug_fix: false +--- + +Some message for the change. + +Implementation +When a release is performed, the release script will generate the release notes, +update the CHANGELOG.md file, copy SDK changelog entries into the SDK, +and delete all the files in changelog/. +SDK Entries +The SDK changelog entries currently end up in aws/SDK_CHANGELOG.next.json, and each entry +is given age and since_commit entries. The age is a number that starts at zero, and gets +incremented with every smithy-rs release. When it reaches a hardcoded threshold, that entry +is removed from aws/SDK_CHANGELOG.next.json. The SDK release process uses the since_commit +to determine which changelog entries go into the next SDK release's changelog. +The SDK release process doesn't write back to smithy-rs, and history has shown that it +can't since this leads to all sorts of release issues as PRs get merged into smithy-rs +while the release is in progress. Thus, this age/since_commit dichotomy needs to +stay in place. +The aws/SDK_CHANGELOG.next.json will stay in place in its current format without changes. +Its JSON format is capable of escaping characters in the message string, so it will be +compatible with the transition from TOML to Markdown with YAML front matter. +The SDK_CHANGELOG.next.json file has had merge conflicts in the past, but this only +happened when the release process wasn't followed correctly. If we're consistent with +our release process, it should never have conflicts. +Safety requirements +Implementation will be tricky since it needs to be done without disrupting the existing +release process. The biggest area of risk is the SDK sync job that generates individual +commits in the aws-sdk-rust repo for each commit in the smithy-rs release. Fortunately, +the changelogger is invoked a single time at the very end of that process, and only +the latest changelogger version that is included in the build image. Thus, we can safely +refactor the changelogger tool so long as the command-line interface for it remains +backwards compatible. (We could change the CLI interface as well, but it will +require synchronizing the smithy-rs changes with changes to the SDK release scripts.) +At a high level, these requirements must be observed to do this refactor safely: + +The CLI for the changelogger render subcommand MUST stay the same, or have minimal +backwards compatible changes made to it. +The SDK_CHANGELOG.next.json format can change, but MUST remain a single JSON file. +If it is changed at all, the existing file MUST be transitioned to the new format, +and a mechanism MUST be in place for making sure it is the correct format after +merging with other PRs. It's probably better to leave this file alone though, or make +any changes to it backwards compatible. + +Future Improvements +After the initial migration, additional niceties could be added such as pulling authors +from git history rather than needing to explicitly state them (at least by default; there +should always be an option to override the author in case a maintainer adds a changelog +entry on behalf of a contributor). +Changes checklist + + +Refactor changelogger and smithy-rs-tool-common to separate the changelog +serialization format from the internal representation used for rendering and splitting. + +Implement deserialization for the new Markdown entry format + +Incorporate new format into the changelogger render subcommand + +Incorporate new format into the changelogger split subcommand + +Port existing CHANGELOG.next.toml to individual entries + +Update sdk-lints to fail if CHANGELOG.next.toml exists at all to avoid losing +changelog entries during merges. + +Dry-run test against the smithy-rs release process. + +Dry-run test against the SDK release process. + Contributing This is a collection of written resources for smithy-rs and SDK contributors. diff --git a/design/rfcs/overview.html b/design/rfcs/overview.html index 0fac2178db..872e25a34e 100644 --- a/design/rfcs/overview.html +++ b/design/rfcs/overview.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP @@ -221,6 +221,7 @@ RFC-0039: Forward Compatible Errors RFC-0040: Behavior Versions RFC-0041: Improve client error ergonomics +RFC-0042: File-per-change changelog diff --git a/design/rfcs/rfc0001_shared_config.html b/design/rfcs/rfc0001_shared_config.html index 5b55188da5..67a3ad6c24 100644 --- a/design/rfcs/rfc0001_shared_config.html +++ b/design/rfcs/rfc0001_shared_config.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0002_http_versions.html b/design/rfcs/rfc0002_http_versions.html index 4be7abbed8..b51eb975c5 100644 --- a/design/rfcs/rfc0002_http_versions.html +++ b/design/rfcs/rfc0002_http_versions.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0003_presigning_api.html b/design/rfcs/rfc0003_presigning_api.html index 2ac9702f1c..9f99a08200 100644 --- a/design/rfcs/rfc0003_presigning_api.html +++ b/design/rfcs/rfc0003_presigning_api.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0004_retry_behavior.html b/design/rfcs/rfc0004_retry_behavior.html index d8e1475cbc..6f53213c4e 100644 --- a/design/rfcs/rfc0004_retry_behavior.html +++ b/design/rfcs/rfc0004_retry_behavior.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0005_service_generation.html b/design/rfcs/rfc0005_service_generation.html index 072064e7e2..e88ec502ce 100644 --- a/design/rfcs/rfc0005_service_generation.html +++ b/design/rfcs/rfc0005_service_generation.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0006_service_specific_middleware.html b/design/rfcs/rfc0006_service_specific_middleware.html index ee8ece6d62..497e10d427 100644 --- a/design/rfcs/rfc0006_service_specific_middleware.html +++ b/design/rfcs/rfc0006_service_specific_middleware.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0007_split_release_process.html b/design/rfcs/rfc0007_split_release_process.html index 2b560f17e4..c9248ae3e7 100644 --- a/design/rfcs/rfc0007_split_release_process.html +++ b/design/rfcs/rfc0007_split_release_process.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0008_paginators.html b/design/rfcs/rfc0008_paginators.html index d9f03e3b26..e377973f97 100644 --- a/design/rfcs/rfc0008_paginators.html +++ b/design/rfcs/rfc0008_paginators.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0009_example_consolidation.html b/design/rfcs/rfc0009_example_consolidation.html index 88bd7d1457..ebcc1d9ab6 100644 --- a/design/rfcs/rfc0009_example_consolidation.html +++ b/design/rfcs/rfc0009_example_consolidation.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0010_waiters.html b/design/rfcs/rfc0010_waiters.html index edf199db3b..e6347f6b6d 100644 --- a/design/rfcs/rfc0010_waiters.html +++ b/design/rfcs/rfc0010_waiters.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0011_crates_io_alpha_publishing.html b/design/rfcs/rfc0011_crates_io_alpha_publishing.html index 742c4e0c0c..800f723022 100644 --- a/design/rfcs/rfc0011_crates_io_alpha_publishing.html +++ b/design/rfcs/rfc0011_crates_io_alpha_publishing.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0012_independent_crate_versioning.html b/design/rfcs/rfc0012_independent_crate_versioning.html index b27104167d..23d1c13650 100644 --- a/design/rfcs/rfc0012_independent_crate_versioning.html +++ b/design/rfcs/rfc0012_independent_crate_versioning.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0013_body_callback_apis.html b/design/rfcs/rfc0013_body_callback_apis.html index 82764bb040..08a5be58ec 100644 --- a/design/rfcs/rfc0013_body_callback_apis.html +++ b/design/rfcs/rfc0013_body_callback_apis.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0014_timeout_config.html b/design/rfcs/rfc0014_timeout_config.html index ffd64868c2..3518b4df2a 100644 --- a/design/rfcs/rfc0014_timeout_config.html +++ b/design/rfcs/rfc0014_timeout_config.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0015_using_features_responsibly.html b/design/rfcs/rfc0015_using_features_responsibly.html index 43a47330a8..7d66272279 100644 --- a/design/rfcs/rfc0015_using_features_responsibly.html +++ b/design/rfcs/rfc0015_using_features_responsibly.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0016_flexible_checksum_support.html b/design/rfcs/rfc0016_flexible_checksum_support.html index f6a2fe9ab3..4dc27535bf 100644 --- a/design/rfcs/rfc0016_flexible_checksum_support.html +++ b/design/rfcs/rfc0016_flexible_checksum_support.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0017_customizable_client_operations.html b/design/rfcs/rfc0017_customizable_client_operations.html index f7f7a9a43c..2854b32be4 100644 --- a/design/rfcs/rfc0017_customizable_client_operations.html +++ b/design/rfcs/rfc0017_customizable_client_operations.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0018_logging_sensitive.html b/design/rfcs/rfc0018_logging_sensitive.html index 4928db10ad..614566a16f 100644 --- a/design/rfcs/rfc0018_logging_sensitive.html +++ b/design/rfcs/rfc0018_logging_sensitive.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0019_event_streams_errors.html b/design/rfcs/rfc0019_event_streams_errors.html index 149c110377..2adb777473 100644 --- a/design/rfcs/rfc0019_event_streams_errors.html +++ b/design/rfcs/rfc0019_event_streams_errors.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0020_service_builder.html b/design/rfcs/rfc0020_service_builder.html index f8bbe96eb7..9ae9e11074 100644 --- a/design/rfcs/rfc0020_service_builder.html +++ b/design/rfcs/rfc0020_service_builder.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0021_dependency_versions.html b/design/rfcs/rfc0021_dependency_versions.html index 8e95d5e2b5..27abebb1da 100644 --- a/design/rfcs/rfc0021_dependency_versions.html +++ b/design/rfcs/rfc0021_dependency_versions.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0022_error_context_and_compatibility.html b/design/rfcs/rfc0022_error_context_and_compatibility.html index f985f25adb..f48da1c049 100644 --- a/design/rfcs/rfc0022_error_context_and_compatibility.html +++ b/design/rfcs/rfc0022_error_context_and_compatibility.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0023_refine_builder.html b/design/rfcs/rfc0023_refine_builder.html index 4f81317b8a..00cf8eb401 100644 --- a/design/rfcs/rfc0023_refine_builder.html +++ b/design/rfcs/rfc0023_refine_builder.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0024_request_id.html b/design/rfcs/rfc0024_request_id.html index d15d6ae3c3..5b9d0bc7bd 100644 --- a/design/rfcs/rfc0024_request_id.html +++ b/design/rfcs/rfc0024_request_id.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0025_constraint_traits.html b/design/rfcs/rfc0025_constraint_traits.html index 35c3d77939..7f19755203 100644 --- a/design/rfcs/rfc0025_constraint_traits.html +++ b/design/rfcs/rfc0025_constraint_traits.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0026_client_crate_organization.html b/design/rfcs/rfc0026_client_crate_organization.html index 6de001edc0..5e8dad4ac1 100644 --- a/design/rfcs/rfc0026_client_crate_organization.html +++ b/design/rfcs/rfc0026_client_crate_organization.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0027_endpoints_20.html b/design/rfcs/rfc0027_endpoints_20.html index 359fcf42f0..239bf218ce 100644 --- a/design/rfcs/rfc0027_endpoints_20.html +++ b/design/rfcs/rfc0027_endpoints_20.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0028_sdk_credential_cache_type_safety.html b/design/rfcs/rfc0028_sdk_credential_cache_type_safety.html index e20873d8e7..130d888696 100644 --- a/design/rfcs/rfc0028_sdk_credential_cache_type_safety.html +++ b/design/rfcs/rfc0028_sdk_credential_cache_type_safety.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0029_new_home_for_cred_types.html b/design/rfcs/rfc0029_new_home_for_cred_types.html index 2a8db4a693..b01886b5b5 100644 --- a/design/rfcs/rfc0029_new_home_for_cred_types.html +++ b/design/rfcs/rfc0029_new_home_for_cred_types.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0030_serialization_and_deserialization.html b/design/rfcs/rfc0030_serialization_and_deserialization.html index b82ee0e920..ab98eb9564 100644 --- a/design/rfcs/rfc0030_serialization_and_deserialization.html +++ b/design/rfcs/rfc0030_serialization_and_deserialization.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0031_providing_fallback_credentials_on_timeout.html b/design/rfcs/rfc0031_providing_fallback_credentials_on_timeout.html index d460611ed0..cf661c05c3 100644 --- a/design/rfcs/rfc0031_providing_fallback_credentials_on_timeout.html +++ b/design/rfcs/rfc0031_providing_fallback_credentials_on_timeout.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0032_better_constraint_violations.html b/design/rfcs/rfc0032_better_constraint_violations.html index 3ce4af8a31..b1539c0cab 100644 --- a/design/rfcs/rfc0032_better_constraint_violations.html +++ b/design/rfcs/rfc0032_better_constraint_violations.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0033_improve_sdk_request_id_access.html b/design/rfcs/rfc0033_improve_sdk_request_id_access.html index 155627d453..f456c53816 100644 --- a/design/rfcs/rfc0033_improve_sdk_request_id_access.html +++ b/design/rfcs/rfc0033_improve_sdk_request_id_access.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0034_smithy_orchestrator.html b/design/rfcs/rfc0034_smithy_orchestrator.html index e43d7bdecd..ee7d8ba810 100644 --- a/design/rfcs/rfc0034_smithy_orchestrator.html +++ b/design/rfcs/rfc0034_smithy_orchestrator.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0035_collection_defaults.html b/design/rfcs/rfc0035_collection_defaults.html index 81b4fc64ed..2e812882ee 100644 --- a/design/rfcs/rfc0035_collection_defaults.html +++ b/design/rfcs/rfc0035_collection_defaults.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0036_http_dep_elimination.html b/design/rfcs/rfc0036_http_dep_elimination.html index 0452bb272a..c334e852c2 100644 --- a/design/rfcs/rfc0036_http_dep_elimination.html +++ b/design/rfcs/rfc0036_http_dep_elimination.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0037_http_wrapper.html b/design/rfcs/rfc0037_http_wrapper.html index 906404bc1f..f0a2d6a152 100644 --- a/design/rfcs/rfc0037_http_wrapper.html +++ b/design/rfcs/rfc0037_http_wrapper.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0038_retry_classifier_customization.html b/design/rfcs/rfc0038_retry_classifier_customization.html index 3bf1b1a8ac..57fc63756f 100644 --- a/design/rfcs/rfc0038_retry_classifier_customization.html +++ b/design/rfcs/rfc0038_retry_classifier_customization.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0039_forward_compatible_errors.html b/design/rfcs/rfc0039_forward_compatible_errors.html index 7c9d39a7b9..06bc8bff27 100644 --- a/design/rfcs/rfc0039_forward_compatible_errors.html +++ b/design/rfcs/rfc0039_forward_compatible_errors.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0040_behavior_versions.html b/design/rfcs/rfc0040_behavior_versions.html index ffca64b434..47ed94253b 100644 --- a/design/rfcs/rfc0040_behavior_versions.html +++ b/design/rfcs/rfc0040_behavior_versions.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP diff --git a/design/rfcs/rfc0041_improve_client_error_ergonomics.html b/design/rfcs/rfc0041_improve_client_error_ergonomics.html index 211327d0ca..2c2b82b751 100644 --- a/design/rfcs/rfc0041_improve_client_error_ergonomics.html +++ b/design/rfcs/rfc0041_improve_client_error_ergonomics.html @@ -88,7 +88,7 @@ - 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP @@ -276,7 +276,7 @@ Changes C - + @@ -290,7 +290,7 @@ Changes C - + diff --git a/design/rfcs/rfc0042_file_per_change_changelog.html b/design/rfcs/rfc0042_file_per_change_changelog.html new file mode 100644 index 0000000000..5b3e976610 --- /dev/null +++ b/design/rfcs/rfc0042_file_per_change_changelog.html @@ -0,0 +1,343 @@ + + + + + + RFC-0042: File-per-change changelog - Smithy Rust + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 1. Design Overview2. Tenets3. Design FAQ4. Transport4.1. HTTP Operations4.2. HTTP Middleware4.3. TLS Connector5. Smithy5.1. Simple Shapes5.2. Recursive Shapes5.3. Aggregate Shapes5.4. Endpoint Resolution5.5. Backwards Compatibility6. Client6.1. What is the 'orchestrator' and why does it exist?6.2. Identity and Auth7. Server7.1. Middleware7.2. Instrumentation7.3. Accessing Un-modelled Data7.4. The Anatomy of a Service7.5. Generating Common Service Code8. RFCs8.1. RFC-0001: Sharing configuration between multiple clients8.2. RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream8.3. RFC-0003: API for Pre-signed URLs8.4. RFC-0004: Retry Behavior8.5. RFC-0005: Smithy Rust service framework8.6. RFC-0006: Service-specific middleware8.7. RFC-0007: Split release process8.8. RFC-0008: Paginators8.9. RFC-0009: Example Consolidation8.10. RFC-0010: Waiters8.11. RFC-0011: Publishing Alpha to Crates.io8.12. RFC-0012: Independent Crate Versioning8.13. RFC-0013: Body Callback APIs8.14. RFC-0014: Fine-grained timeout configuration8.15. RFC-0015: How Cargo "features" should be used in the SDK and runtime crates8.16. RFC-0016: Supporting Flexible Checksums8.17. RFC-0017: Customizable Client Operations8.18. RFC-0018: Logging in the Presence of Sensitive Data8.19. RFC-0019: Event Streams Errors8.20. RFC-0020: Service Builder Improvements8.21. RFC-0021: Dependency Versions8.22. RFC-0022: Error Context and Compatibility8.23. RFC-0023: Evolving the new service builder API8.24. RFC-0024: RequestID8.25. RFC-0025: Constraint traits8.26. RFC-0026: Client Crate Organization8.27. RFC-0027: Endpoints 2.08.28. RFC-0028: SDK Credential Cache Type Safety8.29. RFC-0029: Finding New Home for Credential Types8.30. RFC-0030: Serialization And Deserialization8.31. RFC-0031: Providing Fallback Credentials on Timeout8.32. RFC-0032: Better Constraint Violations8.33. RFC-0033: Improving access to request IDs in SDK clients8.34. RFC-0034: Smithy Orchestrator8.35. RFC-0035: Collection Defaults8.36. RFC-0036: HTTP Dependency Exposure8.37. RFC-0037: The HTTP Wrapper8.38. RFC-0038: User-configurable retry classification8.39. RFC-0039: Forward Compatible Errors8.40. RFC-0040: Behavior Versions8.41. RFC-0041: Improve client error ergonomics8.42. RFC-0042: File-per-change changelog9. Contributing9.1. Writing and debugging a low-level feature that relies on HTTP + + + + + + + + + + + + + + + + + + + + + + + Light + Rust + Coal + Navy + Ayu + + + + + + + Smithy Rust + + + + + + + + + + + + + + + + + + + + + + + + + + RFC: File-per-change changelog + +Status: RFC +Applies to: client and server + +For a summarized list of proposed changes, see the Changes Checklist section. +Historically, the smithy-rs and AWS SDK for Rust's changelogs and release notes have been +generated from the changelogger tool in tools/ci-build/changelogger. This is a tool built +specifically for development and release of smithy-rs, and it requires developers to add +changelog entries to a root CHANGELOG.next.toml file. Upon release, the [[smithy-rs]] entries +in this file go into the smithy-rs release notes, and the [[aws-sdk-rust]] entries are associated +with a smithy-rs release commit hash, and added to the aws/SDK_CHANGELOG.next.json for +incorporation into the AWS SDK's changelog when it releases. +This system has gotten us far, but it has always made merging PRs into main more difficult +since the central CHANGELOG.next.toml file is almost always a merge conflict for two PRs +with changelog entries. +This RFC proposes a new approach to change logging that will remedy the merge conflict issue, +and explains how this can be done without disrupting the current release process. +The proposed developer experience +There will be a changelog/ directory in the smithy-rs root where +developers can add changelog entry Markdown files. Any file name can be picked +for these entries. Suggestions are the development branch name for the +change, or the PR number. +The changelog entry format will change to make it easier to duplicate entries +across both smithy-rs and aws-sdk-rust, a common use-case. +This new format will make use of Markdown front matter in the YAML format. +This change in format has a couple benefits: + +It's easier to write change entries in Markdown than in a TOML string. +There's no way to escape special characters (such as quotes) in a TOML string, +so the text that can be a part of the message will be expanded. + +While it would be preferable to use TOML for the front matter (and there are libraries +that support that), it will use YAML so that GitHub's Markdown renderer will recognize it. +A changelog entry file will look as follows: +--- +# Adding `aws-sdk-rust` here duplicates this entry into the SDK changelog. +applies_to: ["client", "server", "aws-sdk-rust"] +authors: ["author1", "author2"] +references: ["smithy-rs#1234", "aws-sdk-rust#1234"] +# The previous `meta` section is broken up into its constituents: +breaking: false +# This replaces "tada": +new_feature: false +bug_fix: false +--- + +Some message for the change. + +Implementation +When a release is performed, the release script will generate the release notes, +update the CHANGELOG.md file, copy SDK changelog entries into the SDK, +and delete all the files in changelog/. +SDK Entries +The SDK changelog entries currently end up in aws/SDK_CHANGELOG.next.json, and each entry +is given age and since_commit entries. The age is a number that starts at zero, and gets +incremented with every smithy-rs release. When it reaches a hardcoded threshold, that entry +is removed from aws/SDK_CHANGELOG.next.json. The SDK release process uses the since_commit +to determine which changelog entries go into the next SDK release's changelog. +The SDK release process doesn't write back to smithy-rs, and history has shown that it +can't since this leads to all sorts of release issues as PRs get merged into smithy-rs +while the release is in progress. Thus, this age/since_commit dichotomy needs to +stay in place. +The aws/SDK_CHANGELOG.next.json will stay in place in its current format without changes. +Its JSON format is capable of escaping characters in the message string, so it will be +compatible with the transition from TOML to Markdown with YAML front matter. +The SDK_CHANGELOG.next.json file has had merge conflicts in the past, but this only +happened when the release process wasn't followed correctly. If we're consistent with +our release process, it should never have conflicts. +Safety requirements +Implementation will be tricky since it needs to be done without disrupting the existing +release process. The biggest area of risk is the SDK sync job that generates individual +commits in the aws-sdk-rust repo for each commit in the smithy-rs release. Fortunately, +the changelogger is invoked a single time at the very end of that process, and only +the latest changelogger version that is included in the build image. Thus, we can safely +refactor the changelogger tool so long as the command-line interface for it remains +backwards compatible. (We could change the CLI interface as well, but it will +require synchronizing the smithy-rs changes with changes to the SDK release scripts.) +At a high level, these requirements must be observed to do this refactor safely: + +The CLI for the changelogger render subcommand MUST stay the same, or have minimal +backwards compatible changes made to it. +The SDK_CHANGELOG.next.json format can change, but MUST remain a single JSON file. +If it is changed at all, the existing file MUST be transitioned to the new format, +and a mechanism MUST be in place for making sure it is the correct format after +merging with other PRs. It's probably better to leave this file alone though, or make +any changes to it backwards compatible. + +Future Improvements +After the initial migration, additional niceties could be added such as pulling authors +from git history rather than needing to explicitly state them (at least by default; there +should always be an option to override the author in case a maintainer adds a changelog +entry on behalf of a contributor). +Changes checklist + + +Refactor changelogger and smithy-rs-tool-common to separate the changelog +serialization format from the internal representation used for rendering and splitting. + +Implement deserialization for the new Markdown entry format + +Incorporate new format into the changelogger render subcommand + +Incorporate new format into the changelogger split subcommand + +Port existing CHANGELOG.next.toml to individual entries + +Update sdk-lints to fail if CHANGELOG.next.toml exists at all to avoid losing +changelog entries during merges. + +Dry-run test against the smithy-rs release process. + +Dry-run test against the SDK release process. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/design/searchindex.js b/design/searchindex.js index 14068c6034..94d2d5db26 100644 --- a/design/searchindex.js +++ b/design/searchindex.js @@ -1 +1 @@ -Object.assign(window.search, {"doc_urls":["overview.html#design-overview","overview.html#acknowledgments","overview.html#external-api-overview","overview.html#internals","overview.html#code-generation","tenets.html#rust-sdk-design-tenets","tenets.html#details-justifications-and-ramifications","tenets.html#batteries-included-but-replaceable","tenets.html#make-common-problems-easy-to-solve","tenets.html#design-for-the-future","faq.html#design-faq","faq.html#what-is-smithy","faq.html#why-is-there-one-crate-per-service","faq.html#why-dont-the-sdk-service-crates-implement-serdeserialize-or-serdedeserialize-for-any-types","faq.html#i-want-to-add-new-request-building-behavior-should-i-add-that-functionality-to-the-make_operation-codegen-or-write-a-request-altering-middleware","transport/overview.html#transport","transport/overview.html#where-we-are-today","transport/overview.html#where-we-want-to-go","transport/operation.html#http-based-operations","transport/operation.html#operation-phases","transport/operation.html#input-construction","transport/operation.html#operation-construction","transport/operation.html#operation-dispatch-and-middleware","transport/operation.html#operation-parsing-and-response-loading","transport/middleware.html#http-middleware","transport/connector.html","smithy/overview.html#smithy","smithy/overview.html#internals","smithy/simple_shapes.html#simple-shapes","smithy/simple_shapes.html#big-numbers","smithy/simple_shapes.html#timestamps","smithy/simple_shapes.html#strings","smithy/simple_shapes.html#document-types","smithy/recursive_shapes.html#recursive-shapes","smithy/aggregate_shapes.html#aggregate-shapes","smithy/aggregate_shapes.html#list","smithy/aggregate_shapes.html#set","smithy/aggregate_shapes.html#map","smithy/aggregate_shapes.html#structure","smithy/aggregate_shapes.html#example-structure-output","smithy/aggregate_shapes.html#union","smithy/aggregate_shapes.html#generated-union-example","smithy/endpoint.html#endpoint-resolution","smithy/endpoint.html#requirements","smithy/endpoint.html#design","smithy/backwards-compat.html#backwards-compatibility","smithy/backwards-compat.html#new-operation-added","smithy/backwards-compat.html#new-member-added-to-structure","smithy/backwards-compat.html#summary","smithy/backwards-compat.html#validation--required-members","smithy/backwards-compat.html#new-union-variant-added","client/overview.html#smithy-client","client/orchestrator.html#what-is-the-orchestrator","client/orchestrator.html#how-is-an-orchestrator-configured","client/orchestrator.html#what-does-the-orchestrator-do","client/orchestrator.html#how-is-the-orchestrator-implemented-in-rust","client/orchestrator.html#avoiding-generics-at-all-costs","client/orchestrator.html#the-actual-code","client/orchestrator.html#frequently-asked-questions","client/orchestrator.html#why-cant-users-create-and-use-their-own-runtime-plugins","client/orchestrator.html#why-does-the-orchestrator-exist","client/orchestrator.html#why-does-this-document-exist-when-theres-already-an-orchestrator-rfc","client/identity_and_auth.html#identity-and-auth-in-clients","client/identity_and_auth.html#terminology","client/identity_and_auth.html#overview-of-smithy-client-auth","client/identity_and_auth.html#the-configuration-stage","client/identity_and_auth.html#the-execution-stage","client/identity_and_auth.html#how-this-looks-in-rust","client/identity_and_auth.html#challenges-with-this-identity-design","server/overview.html#smithy-server","server/middleware.html#middleware","server/middleware.html#introduction-to-tower","server/middleware.html#applying-middleware","server/middleware.html#a-outer-middleware","server/middleware.html#b-route-middleware","server/middleware.html#c-operation-specific-http-middleware","server/middleware.html#d-operation-specific-model-middleware","server/middleware.html#plugin-system","server/instrumentation.html#instrumentation","server/instrumentation.html#spans-over-the-requestresponse-lifecycle","server/instrumentation.html#example","server/instrumentation.html#interactions-with-sensitivity","server/from_parts.html#accessing-un-modelled-data","server/anatomy.html#the-anatomy-of-a-service","server/anatomy.html#operations","server/anatomy.html#serialization-and-deserialization","server/anatomy.html#upgrading-a-model-service","server/anatomy.html#routers","server/anatomy.html#plugins","server/anatomy.html#builders","server/anatomy.html#accessing-unmodelled-data","server/code_generation.html#generating-common-service-code","server/code_generation.html#folder-structure","server/code_generation.html#generating-code","rfcs/overview.html#rfcs","rfcs/overview.html#previously-submitted-rfcs","rfcs/rfc0001_shared_config.html#aws-configuration-rfc","rfcs/rfc0001_shared_config.html#usage-guide","rfcs/rfc0001_shared_config.html#getting-started","rfcs/rfc0001_shared_config.html#sharing-configuration-between-multiple-services","rfcs/rfc0001_shared_config.html#specifying-a-custom-credential-provider","rfcs/rfc0001_shared_config.html#proposed-design","rfcs/rfc0001_shared_config.html#shared-config-implementation","rfcs/rfc0001_shared_config.html#sleep--connectors","rfcs/rfc0001_shared_config.html#the-build-method-on-config","rfcs/rfc0001_shared_config.html#stability-and-versioning","rfcs/rfc0001_shared_config.html#changes-checklist","rfcs/rfc0001_shared_config.html#open-issues","rfcs/rfc0002_http_versions.html#rfc-supporting-multiple-http-versions-for-sdks-that-use-event-stream","rfcs/rfc0002_http_versions.html#terminology","rfcs/rfc0002_http_versions.html#how-clients-work-today","rfcs/rfc0002_http_versions.html#solving-the-connector-creation-problem","rfcs/rfc0002_http_versions.html#solving-the-connector-selection-problem","rfcs/rfc0002_http_versions.html#changes-checklist","rfcs/rfc0003_presigning_api.html#rfc-api-for-presigned-urls","rfcs/rfc0003_presigning_api.html#terminology","rfcs/rfc0003_presigning_api.html#presigned-url-config","rfcs/rfc0003_presigning_api.html#fluent-presigned-url-api","rfcs/rfc0003_presigning_api.html#input-presigned-url-api","rfcs/rfc0003_presigning_api.html#behind-the-scenes","rfcs/rfc0003_presigning_api.html#modeling-presigning","rfcs/rfc0003_presigning_api.html#avoiding-name-collision","rfcs/rfc0003_presigning_api.html#changes-checklist","rfcs/rfc0004_retry_behavior.html#rfc-retry-behavior","rfcs/rfc0004_retry_behavior.html#terminology","rfcs/rfc0004_retry_behavior.html#configuring-the-maximum-number-of-retries","rfcs/rfc0004_retry_behavior.html#setting-an-environment-variable","rfcs/rfc0004_retry_behavior.html#calling-a-method-on-an-aws-shared-config","rfcs/rfc0004_retry_behavior.html#calling-a-method-on-service-specific-config","rfcs/rfc0004_retry_behavior.html#disabling-retries","rfcs/rfc0004_retry_behavior.html#behind-the-scenes","rfcs/rfc0004_retry_behavior.html#changes-checklist","rfcs/rfc0005_service_generation.html#rfc-smithy-rust-service-framework","rfcs/rfc0005_service_generation.html#requirements","rfcs/rfc0005_service_generation.html#smithy-model-driven-code-generation","rfcs/rfc0005_service_generation.html#performance","rfcs/rfc0005_service_generation.html#extensibility","rfcs/rfc0005_service_generation.html#observability","rfcs/rfc0005_service_generation.html#client-generation","rfcs/rfc0005_service_generation.html#benchmarking","rfcs/rfc0005_service_generation.html#model-validation","rfcs/rfc0006_service_specific_middleware.html#rfc-service-specific-middleware","rfcs/rfc0006_service_specific_middleware.html#terminology","rfcs/rfc0006_service_specific_middleware.html#detailed-design","rfcs/rfc0006_service_specific_middleware.html#changes-checklist","rfcs/rfc0007_split_release_process.html#rfc-split-release-process","rfcs/rfc0007_split_release_process.html#terminology","rfcs/rfc0007_split_release_process.html#requirements","rfcs/rfc0007_split_release_process.html#background-how-publishing-worked-before","rfcs/rfc0007_split_release_process.html#proposed-solution","rfcs/rfc0007_split_release_process.html#avoiding-mistakes-by-disallowing-creation-of-publish-ready-bundles-outside-of-ci","rfcs/rfc0007_split_release_process.html#alternatives-considered","rfcs/rfc0007_split_release_process.html#publish-smithy-runtime-crates-from-smithy-rs-build-artifacts","rfcs/rfc0007_split_release_process.html#keep-smithy-runtime-crates-in-smithy-rs","rfcs/rfc0007_split_release_process.html#changes-checklist","rfcs/rfc0008_paginators.html#summary","rfcs/rfc0008_paginators.html#details","rfcs/rfc0008_paginators.html#updates-to-ergonomic-clients","rfcs/rfc0008_paginators.html#discussion-areas","rfcs/rfc0008_paginators.html#on-sendawait","rfcs/rfc0008_paginators.html#on-tokio_streamstream","rfcs/rfc0008_paginators.html#on-generics","rfcs/rfc0008_paginators.html#changes-checklist","rfcs/rfc0009_example_consolidation.html#rfc-examples-consolidation","rfcs/rfc0009_example_consolidation.html#requirements","rfcs/rfc0009_example_consolidation.html#example-ci-in-smithy-rs","rfcs/rfc0009_example_consolidation.html#auto-sync-to-aws-sdk-rust-from-smithy-rs-changes","rfcs/rfc0009_example_consolidation.html#process-risks","rfcs/rfc0009_example_consolidation.html#alternatives","rfcs/rfc0009_example_consolidation.html#aws-sdk-rust-as-the-source-of-truth","rfcs/rfc0009_example_consolidation.html#changes-checklist","rfcs/rfc0010_waiters.html#rfc-waiters","rfcs/rfc0010_waiters.html#terminology","rfcs/rfc0010_waiters.html#requirements","rfcs/rfc0010_waiters.html#waiter-api","rfcs/rfc0010_waiters.html#waiter-implementation","rfcs/rfc0010_waiters.html#changes-checklist","rfcs/rfc0011_crates_io_alpha_publishing.html#rfc-publishing-the-alpha-sdk-to-cratesio","rfcs/rfc0011_crates_io_alpha_publishing.html#terminology","rfcs/rfc0011_crates_io_alpha_publishing.html#requirements","rfcs/rfc0011_crates_io_alpha_publishing.html#versioning","rfcs/rfc0011_crates_io_alpha_publishing.html#yanking","rfcs/rfc0011_crates_io_alpha_publishing.html#concrete-scenarios","rfcs/rfc0011_crates_io_alpha_publishing.html#proposal","rfcs/rfc0011_crates_io_alpha_publishing.html#short-term-changes-checklist","rfcs/rfc0012_independent_crate_versioning.html#rfc-independent-crate-versioning","rfcs/rfc0012_independent_crate_versioning.html#terminology","rfcs/rfc0012_independent_crate_versioning.html#requirements","rfcs/rfc0012_independent_crate_versioning.html#versioning","rfcs/rfc0012_independent_crate_versioning.html#release-identification","rfcs/rfc0012_independent_crate_versioning.html#yanking","rfcs/rfc0012_independent_crate_versioning.html#phase-1-dev-preview","rfcs/rfc0012_independent_crate_versioning.html#version-tracking","rfcs/rfc0012_independent_crate_versioning.html#versioning-for-code-generated-sdk-service-crates","rfcs/rfc0012_independent_crate_versioning.html#versioning-for-runtime-crates","rfcs/rfc0012_independent_crate_versioning.html#yanking-1","rfcs/rfc0012_independent_crate_versioning.html#changes-checklist","rfcs/rfc0012_independent_crate_versioning.html#phase-2-stability-and-1x","rfcs/rfc0013_body_callback_apis.html#rfc-callback-apis-for-bytestream-and-sdkbody","rfcs/rfc0013_body_callback_apis.html#the-implementation","rfcs/rfc0013_body_callback_apis.html#implementing-checksums","rfcs/rfc0014_timeout_config.html#rfc-fine-grained-timeout-configuration","rfcs/rfc0014_timeout_config.html#terminology","rfcs/rfc0014_timeout_config.html#general-terms","rfcs/rfc0014_timeout_config.html#http-stack-terms","rfcs/rfc0014_timeout_config.html#timeout-terms","rfcs/rfc0014_timeout_config.html#configuring-timeouts","rfcs/rfc0014_timeout_config.html#configuration-options","rfcs/rfc0014_timeout_config.html#sdk-specific-defaults-set-by-aws-service-teams","rfcs/rfc0014_timeout_config.html#prior-art","rfcs/rfc0014_timeout_config.html#behind-the-scenes","rfcs/rfc0014_timeout_config.html#middlewares-for-aws-client-requests","rfcs/rfc0014_timeout_config.html#middlewares-for-smithy-client-requests","rfcs/rfc0014_timeout_config.html#changes-checklist","rfcs/rfc0014_timeout_config.html#implementing-http-request-timeouts","rfcs/rfc0015_using_features_responsibly.html#rfc-how-cargo-features-should-be-used-in-the-sdk-and-runtime-crates","rfcs/rfc0015_using_features_responsibly.html#some-background-on-features","rfcs/rfc0015_using_features_responsibly.html#features-should-be-additive","rfcs/rfc0015_using_features_responsibly.html#what-does-this-mean-for-the-sdk","rfcs/rfc0015_using_features_responsibly.html#avoid-writing-code-that-relies-on-only-activating-one-feature-from-a-set-of-mutually-exclusive-features","rfcs/rfc0015_using_features_responsibly.html#we-should-avoid-using-cfgnotfeature--some-feature","rfcs/rfc0015_using_features_responsibly.html#dont-default-to-defining-default-features","rfcs/rfc0015_using_features_responsibly.html#further-reading","rfcs/rfc0016_flexible_checksum_support.html#rfc-supporting-flexible-checksums","rfcs/rfc0016_flexible_checksum_support.html#what-is-the-flexible-checksums-feature","rfcs/rfc0016_flexible_checksum_support.html#implementing-checksums","rfcs/rfc0016_flexible_checksum_support.html#refactoring-aws-smithy-checksums","rfcs/rfc0016_flexible_checksum_support.html#checksumbody","rfcs/rfc0016_flexible_checksum_support.html#checksumvalidatedbody","rfcs/rfc0016_flexible_checksum_support.html#awschunkedbody-and-awschunkedbodyoptions","rfcs/rfc0016_flexible_checksum_support.html#sigv4-update","rfcs/rfc0016_flexible_checksum_support.html#inlineables","rfcs/rfc0016_flexible_checksum_support.html#codegen","rfcs/rfc0016_flexible_checksum_support.html#implementation-checklist","rfcs/rfc0017_customizable_client_operations.html#rfc-customizable-client-operations","rfcs/rfc0017_customizable_client_operations.html#terminology","rfcs/rfc0017_customizable_client_operations.html#proposal","rfcs/rfc0017_customizable_client_operations.html#why-not-remove-async-from-customize-to-make-this-more-ergonomic","rfcs/rfc0017_customizable_client_operations.html#why-the-name-customize","rfcs/rfc0017_customizable_client_operations.html#changes-checklist","rfcs/rfc0018_logging_sensitive.html#rfc-logging-in-the-presence-of-sensitive-data","rfcs/rfc0018_logging_sensitive.html#terminology","rfcs/rfc0018_logging_sensitive.html#background","rfcs/rfc0018_logging_sensitive.html#http-binding-traits","rfcs/rfc0018_logging_sensitive.html#scope-and-guidelines","rfcs/rfc0018_logging_sensitive.html#routing","rfcs/rfc0018_logging_sensitive.html#runtime-crates","rfcs/rfc0018_logging_sensitive.html#proposal","rfcs/rfc0018_logging_sensitive.html#debug-logging","rfcs/rfc0018_logging_sensitive.html#code-generated-logging-middleware","rfcs/rfc0018_logging_sensitive.html#http-debugdisplay-wrappers","rfcs/rfc0018_logging_sensitive.html#middleware-position","rfcs/rfc0018_logging_sensitive.html#logging-within-the-router","rfcs/rfc0018_logging_sensitive.html#developer-guideline","rfcs/rfc0018_logging_sensitive.html#alternative-proposals","rfcs/rfc0018_logging_sensitive.html#use-request-extensions","rfcs/rfc0018_logging_sensitive.html#accommodate-the-sensitivity-in-middleware-api","rfcs/rfc0018_logging_sensitive.html#redact-values-using-a-tracing-layer","rfcs/rfc0018_logging_sensitive.html#changes-checklist","rfcs/rfc0019_event_streams_errors.html#rfc-errors-for-event-streams","rfcs/rfc0019_event_streams_errors.html#the-user-experience-if-this-rfc-is-implemented","rfcs/rfc0019_event_streams_errors.html#how-to-actually-implement-this-rfc","rfcs/rfc0019_event_streams_errors.html#changes-checklist","rfcs/rfc0020_service_builder.html#rfc-service-builder-improvements","rfcs/rfc0020_service_builder.html#terminology","rfcs/rfc0020_service_builder.html#background","rfcs/rfc0020_service_builder.html#handlers","rfcs/rfc0020_service_builder.html#builder","rfcs/rfc0020_service_builder.html#router","rfcs/rfc0020_service_builder.html#comparison-to-axum","rfcs/rfc0020_service_builder.html#proposal","rfcs/rfc0020_service_builder.html#remove-two-step-build-procedure","rfcs/rfc0020_service_builder.html#statically-check-for-missing-handlers","rfcs/rfc0020_service_builder.html#switch-from-for-router-to-an-operationregistrybuild-method","rfcs/rfc0020_service_builder.html#operations-as-middleware-constructors","rfcs/rfc0020_service_builder.html#service-parameterized-routers","rfcs/rfc0020_service_builder.html#protocol-specific-routers","rfcs/rfc0020_service_builder.html#protocol-specific-errors","rfcs/rfc0020_service_builder.html#type-erasure-with-the-name-of-the-smithy-service","rfcs/rfc0020_service_builder.html#combined-proposal","rfcs/rfc0020_service_builder.html#changes-checklist","rfcs/rfc0021_dependency_versions.html#rfc-dependency-versions","rfcs/rfc0021_dependency_versions.html#categorization-of-crates","rfcs/rfc0021_dependency_versions.html#support-crates-for-applications","rfcs/rfc0021_dependency_versions.html#dependency-version-rules","rfcs/rfc0021_dependency_versions.html#what-is-a-minimum-secure-version-when-there-are-multiple-major-versions","rfcs/rfc0021_dependency_versions.html#changes-checklist","rfcs/rfc0022_error_context_and_compatibility.html#rfc-error-context-and-compatibility","rfcs/rfc0022_error_context_and_compatibility.html#past-approaches-in-smithy-rs","rfcs/rfc0022_error_context_and_compatibility.html#case-study-invalidfullurierror","rfcs/rfc0022_error_context_and_compatibility.html#case-study-profileparseerror","rfcs/rfc0022_error_context_and_compatibility.html#case-study-code-generated-client-errors","rfcs/rfc0022_error_context_and_compatibility.html#approaches-from-other-projects","rfcs/rfc0022_error_context_and_compatibility.html#stdioerror","rfcs/rfc0022_error_context_and_compatibility.html#hyper-10","rfcs/rfc0022_error_context_and_compatibility.html#opaque-error-sources","rfcs/rfc0022_error_context_and_compatibility.html#error-proposal","rfcs/rfc0022_error_context_and_compatibility.html#actionable-error-pattern","rfcs/rfc0022_error_context_and_compatibility.html#informative-error-pattern","rfcs/rfc0022_error_context_and_compatibility.html#displaying-full-error-context","rfcs/rfc0022_error_context_and_compatibility.html#changes-checklist","rfcs/rfc0022_error_context_and_compatibility.html#error-code-review-checklist","rfcs/rfc0023_refine_builder.html#rfc-evolving-the-new-service-builder-api","rfcs/rfc0023_refine_builder.html#overview","rfcs/rfc0023_refine_builder.html#handling-missing-operations","rfcs/rfc0023_refine_builder.html#compiler-errors-cannot-be-tuned","rfcs/rfc0023_refine_builder.html#the-cost-of-a-runtime-error","rfcs/rfc0023_refine_builder.html#providing-clear-feedback","rfcs/rfc0023_refine_builder.html#simplifying-pokemonservicebuilders-signature","rfcs/rfc0023_refine_builder.html#branching---incompatible-types","rfcs/rfc0023_refine_builder.html#refactoring-into-smaller-functions---prepare-for-some-type-juggling","rfcs/rfc0023_refine_builder.html#cut-them-down-going-from-2n1-to-2-generic-parameters","rfcs/rfc0023_refine_builder.html#alternatives-allow-new-plugins-to-be-registered-after-builder-creation","rfcs/rfc0023_refine_builder.html#alternatives-lazy-and-eager-on-demand-type-erasure","rfcs/rfc0023_refine_builder.html#builder-extensions-what-now","rfcs/rfc0023_refine_builder.html#playing-around-with-the-design","rfcs/rfc0023_refine_builder.html#changes-checklist","rfcs/rfc0024_request_id.html#rfc-requestid-in-business-logic-handlers","rfcs/rfc0024_request_id.html#terminology","rfcs/rfc0024_request_id.html#the-user-experience-if-this-rfc-is-implemented","rfcs/rfc0024_request_id.html#changes-checklist","rfcs/rfc0024_request_id.html#changes-since-the-rfc-has-been-approved","rfcs/rfc0025_constraint_traits.html#rfc-constraint-traits","rfcs/rfc0025_constraint_traits.html#implementation","rfcs/rfc0025_constraint_traits.html#example-implementation-for-the-length-trait","rfcs/rfc0025_constraint_traits.html#request-deserialization","rfcs/rfc0025_constraint_traits.html#length-trait","rfcs/rfc0025_constraint_traits.html#pattern-trait","rfcs/rfc0025_constraint_traits.html#uniqueitems-trait","rfcs/rfc0025_constraint_traits.html#trait-precedence-and-naming-of-the-tuple-struct","rfcs/rfc0025_constraint_traits.html#unresolved-questions","rfcs/rfc0025_constraint_traits.html#alternative-design","rfcs/rfc0026_client_crate_organization.html#rfc-client-crate-organization","rfcs/rfc0026_client_crate_organization.html#previous-organization","rfcs/rfc0026_client_crate_organization.html#proposed-changes","rfcs/rfc0026_client_crate_organization.html#establish-a-pattern-for-builder-organization","rfcs/rfc0026_client_crate_organization.html#organize-code-generated-types-by-operation","rfcs/rfc0026_client_crate_organization.html#reorganize-the-crate-root","rfcs/rfc0026_client_crate_organization.html#conditionally-remove-builder-from-crateclient","rfcs/rfc0026_client_crate_organization.html#create-a-primitives-module","rfcs/rfc0026_client_crate_organization.html#repurpose-the-types-module","rfcs/rfc0026_client_crate_organization.html#repurpose-the-original-crateerror-module","rfcs/rfc0026_client_crate_organization.html#flatten-the-presigning-module","rfcs/rfc0026_client_crate_organization.html#remove-the-empty-modules","rfcs/rfc0026_client_crate_organization.html#new-organization","rfcs/rfc0026_client_crate_organization.html#changes-checklist","rfcs/rfc0027_endpoints_20.html#rfc-endpoints-20","rfcs/rfc0027_endpoints_20.html#terminology","rfcs/rfc0027_endpoints_20.html#the-user-experience-if-this-rfc-is-implemented","rfcs/rfc0027_endpoints_20.html#overview","rfcs/rfc0027_endpoints_20.html#overriding-endpoints","rfcs/rfc0027_endpoints_20.html#new-endpoint-traits","rfcs/rfc0027_endpoints_20.html#endpoint-params","rfcs/rfc0027_endpoints_20.html#the-default-endpoint-resolver","rfcs/rfc0027_endpoints_20.html#how-to-actually-implement-this-rfc","rfcs/rfc0027_endpoints_20.html#code-generating-client-context-params","rfcs/rfc0027_endpoints_20.html#creating-params","rfcs/rfc0027_endpoints_20.html#converting-a-smithy-endpoint-to-an-aws-endpoint","rfcs/rfc0027_endpoints_20.html#implementing-the-rules-engine","rfcs/rfc0027_endpoints_20.html#changes-checklist","rfcs/rfc0027_endpoints_20.html#alternative-designs","rfcs/rfc0027_endpoints_20.html#context-aware-endpoint-traits","rfcs/rfc0028_sdk_credential_cache_type_safety.html#rfc-sdk-credential-cache-type-safety","rfcs/rfc0028_sdk_credential_cache_type_safety.html#credentialscache-and-configloadercredentials_cache","rfcs/rfc0028_sdk_credential_cache_type_safety.html#changes-checklist","rfcs/rfc0028_sdk_credential_cache_type_safety.html#appendix-alternatives-considered","rfcs/rfc0028_sdk_credential_cache_type_safety.html#alternative-a-providecachedcredentials-trait","rfcs/rfc0028_sdk_credential_cache_type_safety.html#alternative-b-cachecredentials-trait","rfcs/rfc0028_sdk_credential_cache_type_safety.html#alternative-c-credentialscache-struct-with-composition","rfcs/rfc0029_new_home_for_cred_types.html#rfc-finding-new-home-for-credential-types","rfcs/rfc0029_new_home_for_cred_types.html#assumptions","rfcs/rfc0029_new_home_for_cred_types.html#problems","rfcs/rfc0029_new_home_for_cred_types.html#proposed-solution","rfcs/rfc0029_new_home_for_cred_types.html#rejected-alternative","rfcs/rfc0029_new_home_for_cred_types.html#changes-checklist","rfcs/rfc0030_serialization_and_deserialization.html#rfc-serialization-and-deserialization","rfcs/rfc0030_serialization_and_deserialization.html#terminology","rfcs/rfc0030_serialization_and_deserialization.html#overview","rfcs/rfc0030_serialization_and_deserialization.html#use-case","rfcs/rfc0030_serialization_and_deserialization.html#feature-gate","rfcs/rfc0030_serialization_and_deserialization.html#enabling-feature","rfcs/rfc0030_serialization_and_deserialization.html#feature-gate-for-serialization-and-de-serialization","rfcs/rfc0030_serialization_and_deserialization.html#keeping-both-features-behind-the-same-feature-gate","rfcs/rfc0030_serialization_and_deserialization.html#different-feature-gates-for-different-data-types","rfcs/rfc0030_serialization_and_deserialization.html#implementation","rfcs/rfc0030_serialization_and_deserialization.html#smithy-types","rfcs/rfc0030_serialization_and_deserialization.html#blob","rfcs/rfc0030_serialization_and_deserialization.html#datetime","rfcs/rfc0030_serialization_and_deserialization.html#document","rfcs/rfc0030_serialization_and_deserialization.html#number","rfcs/rfc0030_serialization_and_deserialization.html#builder-types-and-non-builder-types","rfcs/rfc0030_serialization_and_deserialization.html#enum-representation","rfcs/rfc0030_serialization_and_deserialization.html#untagged","rfcs/rfc0030_serialization_and_deserialization.html#internal","rfcs/rfc0030_serialization_and_deserialization.html#external-and-adjacent","rfcs/rfc0030_serialization_and_deserialization.html#data-types-to-skip-serializationdeserialization","rfcs/rfc0030_serialization_and_deserialization.html#data-types-to-exclude-from-serde-code-generation","rfcs/rfc0030_serialization_and_deserialization.html#serde-traits-implemented-on-builder-of-output-types","rfcs/rfc0030_serialization_and_deserialization.html#fn-set_fields-to-allow-users-to-use-externally-created-input","rfcs/rfc0030_serialization_and_deserialization.html#other-concerns","rfcs/rfc0030_serialization_and_deserialization.html#model-evolution","rfcs/rfc0030_serialization_and_deserialization.html#introduction-of-new-fields","rfcs/rfc0030_serialization_and_deserialization.html#introduction-of-new-data-type","rfcs/rfc0030_serialization_and_deserialization.html#discussions","rfcs/rfc0030_serialization_and_deserialization.html#sensitive-information","rfcs/rfc0030_serialization_and_deserialization.html#compile-time","rfcs/rfc0030_serialization_and_deserialization.html#misleading-results","rfcs/rfc0030_serialization_and_deserialization.html#appendix","rfcs/rfc0030_serialization_and_deserialization.html#use-case-examples","rfcs/rfc0030_serialization_and_deserialization.html#changes-checklist","rfcs/rfc0031_providing_fallback_credentials_on_timeout.html#rfc-providing-fallback-credentials-on-external-timeout","rfcs/rfc0031_providing_fallback_credentials_on_timeout.html#terminology","rfcs/rfc0031_providing_fallback_credentials_on_timeout.html#assumption","rfcs/rfc0031_providing_fallback_credentials_on_timeout.html#problem","rfcs/rfc0031_providing_fallback_credentials_on_timeout.html#proposal","rfcs/rfc0031_providing_fallback_credentials_on_timeout.html#how-to-actually-implement-this-rfc","rfcs/rfc0031_providing_fallback_credentials_on_timeout.html#alternative","rfcs/rfc0031_providing_fallback_credentials_on_timeout.html#changes-checklist","rfcs/rfc0031_providing_fallback_credentials_on_timeout.html#possible-enhancement","rfcs/rfc0032_better_constraint_violations.html#rfc-better-constraint-violations","rfcs/rfc0032_better_constraint_violations.html#terminology","rfcs/rfc0032_better_constraint_violations.html#impossible-constraint-violations","rfcs/rfc0032_better_constraint_violations.html#background","rfcs/rfc0032_better_constraint_violations.html#problem","rfcs/rfc0032_better_constraint_violations.html#solution-proposal","rfcs/rfc0032_better_constraint_violations.html#collecting-constraint-violations","rfcs/rfc0032_better_constraint_violations.html#background-1","rfcs/rfc0032_better_constraint_violations.html#problem-1","rfcs/rfc0032_better_constraint_violations.html#solution-proposal-1","rfcs/rfc0032_better_constraint_violations.html#tightness-of-constraint-violations","rfcs/rfc0032_better_constraint_violations.html#problem-2","rfcs/rfc0032_better_constraint_violations.html#final-solution-proposal","rfcs/rfc0032_better_constraint_violations.html#checklist","rfcs/rfc0033_improve_sdk_request_id_access.html#rfc-improving-access-to-request-ids-in-sdk-clients","rfcs/rfc0033_improve_sdk_request_id_access.html#terminology","rfcs/rfc0033_improve_sdk_request_id_access.html#sdksmithy-purity","rfcs/rfc0033_improve_sdk_request_id_access.html#proposed-changes","rfcs/rfc0033_improve_sdk_request_id_access.html#make-request-id-retrieval-on-errors-consistent","rfcs/rfc0033_improve_sdk_request_id_access.html#implement-requestid-for-outputs","rfcs/rfc0033_improve_sdk_request_id_access.html#implement-requestid-for-operation-and-operationresponse","rfcs/rfc0033_improve_sdk_request_id_access.html#implement-requestid-for-result","rfcs/rfc0033_improve_sdk_request_id_access.html#example-interactions","rfcs/rfc0033_improve_sdk_request_id_access.html#generic-handling-case","rfcs/rfc0033_improve_sdk_request_id_access.html#success-case","rfcs/rfc0033_improve_sdk_request_id_access.html#error-case-with-sdkerror","rfcs/rfc0033_improve_sdk_request_id_access.html#error-case-with-operation-error","rfcs/rfc0033_improve_sdk_request_id_access.html#changes-checklist","rfcs/rfc0033_improve_sdk_request_id_access.html#appendix-a-alternate-solution-for-access-on-successful-responses","rfcs/rfc0033_improve_sdk_request_id_access.html#appendix-b-adding-requestid-as-a-string-to-outputs-via-model-transform","rfcs/rfc0034_smithy_orchestrator.html#smithy-orchestrator","rfcs/rfc0034_smithy_orchestrator.html#tldr","rfcs/rfc0034_smithy_orchestrator.html#terminology","rfcs/rfc0034_smithy_orchestrator.html#the-user-experience-if-this-rfc-is-implemented","rfcs/rfc0034_smithy_orchestrator.html#service-clients-and-operations-are-configured-with-runtime-plugins","rfcs/rfc0034_smithy_orchestrator.html#requests-and-responses-are-modified-by-interceptors","rfcs/rfc0034_smithy_orchestrator.html#interceptor-context","rfcs/rfc0034_smithy_orchestrator.html#how-to-implement-this-rfc","rfcs/rfc0034_smithy_orchestrator.html#integrating-with-the-orchestrator","rfcs/rfc0034_smithy_orchestrator.html#layered-configuration-stored-in-type-maps","rfcs/rfc0034_smithy_orchestrator.html#the-aws-smithy-orchestrator-crate","rfcs/rfc0034_smithy_orchestrator.html#faq","rfcs/rfc0034_smithy_orchestrator.html#changes-checklist","rfcs/rfc0035_collection_defaults.html#rfc-collection-defaults","rfcs/rfc0035_collection_defaults.html#terminology","rfcs/rfc0035_collection_defaults.html#the-user-experience-if-this-rfc-is-implemented","rfcs/rfc0035_collection_defaults.html#how-to-actually-implement-this-rfc","rfcs/rfc0035_collection_defaults.html#could-this-be-implemented-for-hashmap","rfcs/rfc0035_collection_defaults.html#isnt-this-handled-by-the-default-trait","rfcs/rfc0035_collection_defaults.html#changes-checklist","rfcs/rfc0036_http_dep_elimination.html#rfc-eliminating-public-http-dependencies","rfcs/rfc0036_http_dep_elimination.html#terminology","rfcs/rfc0036_http_dep_elimination.html#why-is-this-important","rfcs/rfc0036_http_dep_elimination.html#the-user-experience-if-this-rfc-is-implemented","rfcs/rfc0036_http_dep_elimination.html#how-to-actually-implement-this-rfc","rfcs/rfc0036_http_dep_elimination.html#enabling-api-evolution","rfcs/rfc0036_http_dep_elimination.html#http-request-wrapper","rfcs/rfc0036_http_dep_elimination.html#removing-the-sigv4-http-dependency","rfcs/rfc0036_http_dep_elimination.html#removing-the-http-dependency-from-generated-clients","rfcs/rfc0036_http_dep_elimination.html#changes-checklist","rfcs/rfc0037_http_wrapper.html#rfc-the-http-wrapper-type","rfcs/rfc0037_http_wrapper.html#terminology","rfcs/rfc0037_http_wrapper.html#the-user-experience-if-this-rfc-is-implemented","rfcs/rfc0037_http_wrapper.html#how-to-actually-implement-this-rfc","rfcs/rfc0037_http_wrapper.html#future-work","rfcs/rfc0037_http_wrapper.html#changes-checklist","rfcs/rfc0038_retry_classifier_customization.html#rfc-user-configurable-retry-classification","rfcs/rfc0038_retry_classifier_customization.html#terminology","rfcs/rfc0038_retry_classifier_customization.html#how-the-orchestrator-should-model-retries","rfcs/rfc0038_retry_classifier_customization.html#the-user-experience-if-this-rfc-is-implemented","rfcs/rfc0038_retry_classifier_customization.html#defining-a-custom-classifier","rfcs/rfc0038_retry_classifier_customization.html#setting-classifiers","rfcs/rfc0038_retry_classifier_customization.html#default-classifiers","rfcs/rfc0038_retry_classifier_customization.html#how-to-actually-implement-this-rfc","rfcs/rfc0038_retry_classifier_customization.html#the-retryclassifier-trait","rfcs/rfc0038_retry_classifier_customization.html#resolving-the-correct-order-of-multiple-retry-classifiers","rfcs/rfc0038_retry_classifier_customization.html#questions-and-answers","rfcs/rfc0038_retry_classifier_customization.html#changes-checklist","rfcs/rfc0039_forward_compatible_errors.html#rfc-forward-compatible-errors","rfcs/rfc0039_forward_compatible_errors.html#terminology","rfcs/rfc0039_forward_compatible_errors.html#the-user-experience-if-this-rfc-is-implemented","rfcs/rfc0039_forward_compatible_errors.html#how-to-actually-implement-this-rfc","rfcs/rfc0039_forward_compatible_errors.html#locking-down-unhandled","rfcs/rfc0039_forward_compatible_errors.html#deprecating-the-variant","rfcs/rfc0039_forward_compatible_errors.html#changes-checklist","rfcs/rfc0040_behavior_versions.html#rfc-behavior-versions","rfcs/rfc0040_behavior_versions.html#the-user-experience-if-this-rfc-is-implemented","rfcs/rfc0040_behavior_versions.html#how-to-actually-implement-this-rfc","rfcs/rfc0040_behavior_versions.html#design-alternatives-considered","rfcs/rfc0040_behavior_versions.html#changes-checklist","rfcs/rfc0041_improve_client_error_ergonomics.html#rfc-improve-client-error-ergonomics","rfcs/rfc0041_improve_client_error_ergonomics.html#case-study-handling-an-error-in-s3","rfcs/rfc0041_improve_client_error_ergonomics.html#proposal-combine-error-and-errorkind","rfcs/rfc0041_improve_client_error_ergonomics.html#changes-checklist","contributing/overview.html#contributing","contributing/writing_and_debugging_a_low-level_feature_that_relies_on_HTTP.html#writing-and-debugging-a-low-level-feature-that-relies-on-http","contributing/writing_and_debugging_a_low-level_feature_that_relies_on_HTTP.html#background","contributing/writing_and_debugging_a_low-level_feature_that_relies_on_HTTP.html#how-the-sdk-sends-requests-with-a-body","contributing/writing_and_debugging_a_low-level_feature_that_relies_on_HTTP.html#how-the-sdk-sends-requests-with-a-streaming-body","contributing/writing_and_debugging_a_low-level_feature_that_relies_on_HTTP.html#the-issues-i-encountered-while-implementing-checksums-for-streaming-request-bodies","contributing/writing_and_debugging_a_low-level_feature_that_relies_on_HTTP.html#content-encoding-aws-chunked","contributing/writing_and_debugging_a_low-level_feature_that_relies_on_HTTP.html#s3-requires-a-content-length-unless-you-also-set-transfer-encoding-chunked","contributing/writing_and_debugging_a_low-level_feature_that_relies_on_HTTP.html#adding-trailers-to-a-request-changes-the-size-of-that-request","contributing/writing_and_debugging_a_low-level_feature_that_relies_on_HTTP.html#hyper-supports-http-request-trailers-but-isnt-compatible-with-content-encoding-aws-chunked","contributing/writing_and_debugging_a_low-level_feature_that_relies_on_HTTP.html#the-stream-is-closing-early-and-i-dont-know-why","contributing/writing_and_debugging_a_low-level_feature_that_relies_on_HTTP.html#what-helped-me-to-understand-the-problems-and-their-solutions","contributing/writing_and_debugging_a_low-level_feature_that_relies_on_HTTP.html"],"index":{"documentStore":{"docInfo":{"0":{"body":42,"breadcrumbs":4,"title":2},"1":{"body":18,"breadcrumbs":3,"title":1},"10":{"body":0,"breadcrumbs":4,"title":2},"100":{"body":74,"breadcrumbs":12,"title":4},"101":{"body":126,"breadcrumbs":10,"title":2},"102":{"body":53,"breadcrumbs":11,"title":3},"103":{"body":40,"breadcrumbs":10,"title":2},"104":{"body":27,"breadcrumbs":11,"title":3},"105":{"body":107,"breadcrumbs":10,"title":2},"106":{"body":67,"breadcrumbs":10,"title":2},"107":{"body":10,"breadcrumbs":10,"title":2},"108":{"body":82,"breadcrumbs":20,"title":9},"109":{"body":81,"breadcrumbs":12,"title":1},"11":{"body":24,"breadcrumbs":3,"title":1},"110":{"body":165,"breadcrumbs":14,"title":3},"111":{"body":134,"breadcrumbs":15,"title":4},"112":{"body":315,"breadcrumbs":15,"title":4},"113":{"body":79,"breadcrumbs":13,"title":2},"114":{"body":40,"breadcrumbs":11,"title":4},"115":{"body":49,"breadcrumbs":8,"title":1},"116":{"body":159,"breadcrumbs":10,"title":3},"117":{"body":151,"breadcrumbs":11,"title":4},"118":{"body":53,"breadcrumbs":11,"title":4},"119":{"body":240,"breadcrumbs":9,"title":2},"12":{"body":80,"breadcrumbs":6,"title":4},"120":{"body":36,"breadcrumbs":9,"title":2},"121":{"body":22,"breadcrumbs":10,"title":3},"122":{"body":59,"breadcrumbs":9,"title":2},"123":{"body":45,"breadcrumbs":8,"title":3},"124":{"body":154,"breadcrumbs":6,"title":1},"125":{"body":57,"breadcrumbs":9,"title":4},"126":{"body":42,"breadcrumbs":8,"title":3},"127":{"body":37,"breadcrumbs":10,"title":5},"128":{"body":40,"breadcrumbs":10,"title":5},"129":{"body":70,"breadcrumbs":7,"title":2},"13":{"body":96,"breadcrumbs":10,"title":8},"130":{"body":182,"breadcrumbs":7,"title":2},"131":{"body":157,"breadcrumbs":7,"title":2},"132":{"body":33,"breadcrumbs":12,"title":5},"133":{"body":0,"breadcrumbs":8,"title":1},"134":{"body":15,"breadcrumbs":12,"title":5},"135":{"body":109,"breadcrumbs":8,"title":1},"136":{"body":24,"breadcrumbs":8,"title":1},"137":{"body":34,"breadcrumbs":8,"title":1},"138":{"body":6,"breadcrumbs":9,"title":2},"139":{"body":13,"breadcrumbs":8,"title":1},"14":{"body":97,"breadcrumbs":16,"title":14},"140":{"body":9,"breadcrumbs":9,"title":2},"141":{"body":91,"breadcrumbs":10,"title":4},"142":{"body":112,"breadcrumbs":7,"title":1},"143":{"body":64,"breadcrumbs":8,"title":2},"144":{"body":49,"breadcrumbs":8,"title":2},"145":{"body":68,"breadcrumbs":10,"title":4},"146":{"body":80,"breadcrumbs":7,"title":1},"147":{"body":79,"breadcrumbs":7,"title":1},"148":{"body":69,"breadcrumbs":10,"title":4},"149":{"body":142,"breadcrumbs":8,"title":2},"15":{"body":13,"breadcrumbs":2,"title":1},"150":{"body":44,"breadcrumbs":15,"title":9},"151":{"body":0,"breadcrumbs":8,"title":2},"152":{"body":137,"breadcrumbs":14,"title":8},"153":{"body":179,"breadcrumbs":12,"title":6},"154":{"body":69,"breadcrumbs":8,"title":2},"155":{"body":131,"breadcrumbs":5,"title":1},"156":{"body":321,"breadcrumbs":5,"title":1},"157":{"body":29,"breadcrumbs":7,"title":3},"158":{"body":0,"breadcrumbs":6,"title":2},"159":{"body":19,"breadcrumbs":5,"title":1},"16":{"body":24,"breadcrumbs":2,"title":1},"160":{"body":18,"breadcrumbs":5,"title":1},"161":{"body":29,"breadcrumbs":5,"title":1},"162":{"body":33,"breadcrumbs":6,"title":2},"163":{"body":73,"breadcrumbs":8,"title":3},"164":{"body":58,"breadcrumbs":6,"title":1},"165":{"body":46,"breadcrumbs":9,"title":4},"166":{"body":85,"breadcrumbs":13,"title":8},"167":{"body":87,"breadcrumbs":7,"title":2},"168":{"body":0,"breadcrumbs":6,"title":1},"169":{"body":144,"breadcrumbs":10,"title":5},"17":{"body":55,"breadcrumbs":3,"title":2},"170":{"body":48,"breadcrumbs":7,"title":2},"171":{"body":118,"breadcrumbs":6,"title":2},"172":{"body":81,"breadcrumbs":5,"title":1},"173":{"body":55,"breadcrumbs":5,"title":1},"174":{"body":73,"breadcrumbs":6,"title":2},"175":{"body":169,"breadcrumbs":6,"title":2},"176":{"body":34,"breadcrumbs":6,"title":2},"177":{"body":41,"breadcrumbs":11,"title":5},"178":{"body":42,"breadcrumbs":7,"title":1},"179":{"body":0,"breadcrumbs":7,"title":1},"18":{"body":45,"breadcrumbs":6,"title":3},"180":{"body":117,"breadcrumbs":7,"title":1},"181":{"body":50,"breadcrumbs":7,"title":1},"182":{"body":73,"breadcrumbs":8,"title":2},"183":{"body":229,"breadcrumbs":7,"title":1},"184":{"body":35,"breadcrumbs":10,"title":4},"185":{"body":68,"breadcrumbs":10,"title":4},"186":{"body":42,"breadcrumbs":7,"title":1},"187":{"body":0,"breadcrumbs":7,"title":1},"188":{"body":138,"breadcrumbs":7,"title":1},"189":{"body":27,"breadcrumbs":8,"title":2},"19":{"body":10,"breadcrumbs":5,"title":2},"190":{"body":20,"breadcrumbs":7,"title":1},"191":{"body":32,"breadcrumbs":10,"title":4},"192":{"body":104,"breadcrumbs":8,"title":2},"193":{"body":163,"breadcrumbs":12,"title":6},"194":{"body":268,"breadcrumbs":9,"title":3},"195":{"body":40,"breadcrumbs":7,"title":1},"196":{"body":69,"breadcrumbs":8,"title":2},"197":{"body":34,"breadcrumbs":10,"title":4},"198":{"body":18,"breadcrumbs":11,"title":5},"199":{"body":547,"breadcrumbs":7,"title":1},"2":{"body":88,"breadcrumbs":5,"title":3},"20":{"body":66,"breadcrumbs":5,"title":2},"200":{"body":198,"breadcrumbs":8,"title":2},"201":{"body":38,"breadcrumbs":12,"title":5},"202":{"body":9,"breadcrumbs":8,"title":1},"203":{"body":99,"breadcrumbs":9,"title":2},"204":{"body":220,"breadcrumbs":10,"title":3},"205":{"body":128,"breadcrumbs":9,"title":2},"206":{"body":40,"breadcrumbs":9,"title":2},"207":{"body":56,"breadcrumbs":9,"title":2},"208":{"body":5,"breadcrumbs":14,"title":7},"209":{"body":33,"breadcrumbs":9,"title":2},"21":{"body":53,"breadcrumbs":5,"title":2},"210":{"body":36,"breadcrumbs":9,"title":2},"211":{"body":49,"breadcrumbs":11,"title":4},"212":{"body":321,"breadcrumbs":11,"title":4},"213":{"body":18,"breadcrumbs":9,"title":2},"214":{"body":88,"breadcrumbs":11,"title":4},"215":{"body":2,"breadcrumbs":16,"title":7},"216":{"body":75,"breadcrumbs":11,"title":2},"217":{"body":36,"breadcrumbs":11,"title":2},"218":{"body":66,"breadcrumbs":11,"title":2},"219":{"body":162,"breadcrumbs":20,"title":11},"22":{"body":59,"breadcrumbs":6,"title":3},"220":{"body":76,"breadcrumbs":13,"title":4},"221":{"body":209,"breadcrumbs":14,"title":5},"222":{"body":47,"breadcrumbs":11,"title":2},"223":{"body":21,"breadcrumbs":10,"title":4},"224":{"body":32,"breadcrumbs":9,"title":3},"225":{"body":19,"breadcrumbs":8,"title":2},"226":{"body":1039,"breadcrumbs":10,"title":4},"227":{"body":385,"breadcrumbs":7,"title":1},"228":{"body":320,"breadcrumbs":7,"title":1},"229":{"body":944,"breadcrumbs":8,"title":2},"23":{"body":6,"breadcrumbs":7,"title":4},"230":{"body":167,"breadcrumbs":8,"title":2},"231":{"body":232,"breadcrumbs":7,"title":1},"232":{"body":44,"breadcrumbs":7,"title":1},"233":{"body":24,"breadcrumbs":8,"title":2},"234":{"body":85,"breadcrumbs":10,"title":4},"235":{"body":29,"breadcrumbs":7,"title":1},"236":{"body":202,"breadcrumbs":7,"title":1},"237":{"body":50,"breadcrumbs":12,"title":6},"238":{"body":46,"breadcrumbs":8,"title":2},"239":{"body":35,"breadcrumbs":8,"title":2},"24":{"body":61,"breadcrumbs":5,"title":2},"240":{"body":89,"breadcrumbs":12,"title":5},"241":{"body":71,"breadcrumbs":8,"title":1},"242":{"body":0,"breadcrumbs":8,"title":1},"243":{"body":47,"breadcrumbs":10,"title":3},"244":{"body":91,"breadcrumbs":9,"title":2},"245":{"body":73,"breadcrumbs":8,"title":1},"246":{"body":32,"breadcrumbs":9,"title":2},"247":{"body":54,"breadcrumbs":8,"title":1},"248":{"body":80,"breadcrumbs":9,"title":2},"249":{"body":158,"breadcrumbs":11,"title":4},"25":{"body":43,"breadcrumbs":3,"title":1},"250":{"body":59,"breadcrumbs":10,"title":3},"251":{"body":106,"breadcrumbs":9,"title":2},"252":{"body":54,"breadcrumbs":10,"title":3},"253":{"body":48,"breadcrumbs":9,"title":2},"254":{"body":42,"breadcrumbs":9,"title":2},"255":{"body":128,"breadcrumbs":10,"title":3},"256":{"body":90,"breadcrumbs":11,"title":4},"257":{"body":105,"breadcrumbs":12,"title":5},"258":{"body":39,"breadcrumbs":9,"title":2},"259":{"body":21,"breadcrumbs":10,"title":4},"26":{"body":51,"breadcrumbs":2,"title":1},"260":{"body":65,"breadcrumbs":10,"title":4},"261":{"body":265,"breadcrumbs":9,"title":3},"262":{"body":20,"breadcrumbs":8,"title":2},"263":{"body":51,"breadcrumbs":10,"title":4},"264":{"body":75,"breadcrumbs":7,"title":1},"265":{"body":112,"breadcrumbs":7,"title":1},"266":{"body":246,"breadcrumbs":7,"title":1},"267":{"body":156,"breadcrumbs":7,"title":1},"268":{"body":124,"breadcrumbs":7,"title":1},"269":{"body":380,"breadcrumbs":8,"title":2},"27":{"body":133,"breadcrumbs":2,"title":1},"270":{"body":53,"breadcrumbs":7,"title":1},"271":{"body":23,"breadcrumbs":11,"title":5},"272":{"body":119,"breadcrumbs":10,"title":4},"273":{"body":48,"breadcrumbs":11,"title":5},"274":{"body":717,"breadcrumbs":9,"title":3},"275":{"body":56,"breadcrumbs":9,"title":3},"276":{"body":101,"breadcrumbs":9,"title":3},"277":{"body":90,"breadcrumbs":9,"title":3},"278":{"body":123,"breadcrumbs":11,"title":5},"279":{"body":91,"breadcrumbs":8,"title":2},"28":{"body":38,"breadcrumbs":5,"title":2},"280":{"body":45,"breadcrumbs":8,"title":2},"281":{"body":39,"breadcrumbs":8,"title":3},"282":{"body":57,"breadcrumbs":7,"title":2},"283":{"body":36,"breadcrumbs":8,"title":3},"284":{"body":47,"breadcrumbs":8,"title":3},"285":{"body":39,"breadcrumbs":11,"title":6},"286":{"body":15,"breadcrumbs":7,"title":2},"287":{"body":91,"breadcrumbs":10,"title":4},"288":{"body":18,"breadcrumbs":10,"title":4},"289":{"body":227,"breadcrumbs":9,"title":3},"29":{"body":44,"breadcrumbs":5,"title":2},"290":{"body":110,"breadcrumbs":9,"title":3},"291":{"body":61,"breadcrumbs":12,"title":6},"292":{"body":0,"breadcrumbs":8,"title":2},"293":{"body":65,"breadcrumbs":7,"title":1},"294":{"body":40,"breadcrumbs":8,"title":2},"295":{"body":97,"breadcrumbs":9,"title":3},"296":{"body":55,"breadcrumbs":8,"title":2},"297":{"body":271,"breadcrumbs":9,"title":3},"298":{"body":69,"breadcrumbs":9,"title":3},"299":{"body":69,"breadcrumbs":10,"title":4},"3":{"body":38,"breadcrumbs":3,"title":1},"30":{"body":114,"breadcrumbs":4,"title":1},"300":{"body":22,"breadcrumbs":8,"title":2},"301":{"body":73,"breadcrumbs":10,"title":4},"302":{"body":68,"breadcrumbs":14,"title":6},"303":{"body":91,"breadcrumbs":9,"title":1},"304":{"body":56,"breadcrumbs":11,"title":3},"305":{"body":138,"breadcrumbs":11,"title":3},"306":{"body":141,"breadcrumbs":11,"title":3},"307":{"body":212,"breadcrumbs":11,"title":3},"308":{"body":112,"breadcrumbs":11,"title":3},"309":{"body":306,"breadcrumbs":11,"title":3},"31":{"body":71,"breadcrumbs":4,"title":1},"310":{"body":331,"breadcrumbs":14,"title":6},"311":{"body":189,"breadcrumbs":15,"title":7},"312":{"body":176,"breadcrumbs":15,"title":7},"313":{"body":634,"breadcrumbs":14,"title":6},"314":{"body":87,"breadcrumbs":11,"title":3},"315":{"body":10,"breadcrumbs":11,"title":3},"316":{"body":51,"breadcrumbs":10,"title":2},"317":{"body":12,"breadcrumbs":9,"title":5},"318":{"body":146,"breadcrumbs":5,"title":1},"319":{"body":235,"breadcrumbs":8,"title":4},"32":{"body":60,"breadcrumbs":5,"title":2},"320":{"body":30,"breadcrumbs":6,"title":2},"321":{"body":4,"breadcrumbs":7,"title":3},"322":{"body":241,"breadcrumbs":8,"title":3},"323":{"body":23,"breadcrumbs":6,"title":1},"324":{"body":213,"breadcrumbs":9,"title":4},"325":{"body":134,"breadcrumbs":7,"title":2},"326":{"body":25,"breadcrumbs":7,"title":2},"327":{"body":21,"breadcrumbs":7,"title":2},"328":{"body":26,"breadcrumbs":7,"title":2},"329":{"body":62,"breadcrumbs":10,"title":5},"33":{"body":208,"breadcrumbs":5,"title":2},"330":{"body":153,"breadcrumbs":7,"title":2},"331":{"body":143,"breadcrumbs":7,"title":2},"332":{"body":41,"breadcrumbs":10,"title":4},"333":{"body":161,"breadcrumbs":8,"title":2},"334":{"body":13,"breadcrumbs":8,"title":2},"335":{"body":81,"breadcrumbs":10,"title":4},"336":{"body":93,"breadcrumbs":11,"title":5},"337":{"body":102,"breadcrumbs":9,"title":3},"338":{"body":55,"breadcrumbs":10,"title":4},"339":{"body":21,"breadcrumbs":9,"title":3},"34":{"body":19,"breadcrumbs":5,"title":2},"340":{"body":100,"breadcrumbs":9,"title":3},"341":{"body":28,"breadcrumbs":10,"title":4},"342":{"body":34,"breadcrumbs":9,"title":3},"343":{"body":33,"breadcrumbs":9,"title":3},"344":{"body":109,"breadcrumbs":8,"title":2},"345":{"body":112,"breadcrumbs":8,"title":2},"346":{"body":53,"breadcrumbs":8,"title":3},"347":{"body":75,"breadcrumbs":6,"title":1},"348":{"body":0,"breadcrumbs":9,"title":4},"349":{"body":157,"breadcrumbs":6,"title":1},"35":{"body":13,"breadcrumbs":4,"title":1},"350":{"body":329,"breadcrumbs":7,"title":2},"351":{"body":178,"breadcrumbs":8,"title":3},"352":{"body":122,"breadcrumbs":7,"title":2},"353":{"body":53,"breadcrumbs":8,"title":3},"354":{"body":88,"breadcrumbs":8,"title":3},"355":{"body":134,"breadcrumbs":10,"title":5},"356":{"body":179,"breadcrumbs":7,"title":2},"357":{"body":47,"breadcrumbs":10,"title":5},"358":{"body":8,"breadcrumbs":8,"title":3},"359":{"body":94,"breadcrumbs":7,"title":2},"36":{"body":21,"breadcrumbs":4,"title":1},"360":{"body":0,"breadcrumbs":7,"title":2},"361":{"body":68,"breadcrumbs":9,"title":4},"362":{"body":93,"breadcrumbs":14,"title":6},"363":{"body":213,"breadcrumbs":10,"title":2},"364":{"body":51,"breadcrumbs":10,"title":2},"365":{"body":0,"breadcrumbs":11,"title":3},"366":{"body":154,"breadcrumbs":11,"title":3},"367":{"body":105,"breadcrumbs":12,"title":4},"368":{"body":314,"breadcrumbs":13,"title":5},"369":{"body":34,"breadcrumbs":14,"title":6},"37":{"body":25,"breadcrumbs":4,"title":1},"370":{"body":35,"breadcrumbs":9,"title":1},"371":{"body":168,"breadcrumbs":9,"title":1},"372":{"body":103,"breadcrumbs":10,"title":2},"373":{"body":90,"breadcrumbs":10,"title":2},"374":{"body":40,"breadcrumbs":10,"title":2},"375":{"body":15,"breadcrumbs":8,"title":3},"376":{"body":34,"breadcrumbs":6,"title":1},"377":{"body":83,"breadcrumbs":6,"title":1},"378":{"body":28,"breadcrumbs":7,"title":2},"379":{"body":0,"breadcrumbs":7,"title":2},"38":{"body":92,"breadcrumbs":4,"title":1},"380":{"body":77,"breadcrumbs":7,"title":2},"381":{"body":81,"breadcrumbs":10,"title":5},"382":{"body":26,"breadcrumbs":12,"title":7},"383":{"body":25,"breadcrumbs":11,"title":6},"384":{"body":0,"breadcrumbs":6,"title":1},"385":{"body":16,"breadcrumbs":7,"title":2},"386":{"body":211,"breadcrumbs":6,"title":1},"387":{"body":86,"breadcrumbs":6,"title":1},"388":{"body":21,"breadcrumbs":6,"title":1},"389":{"body":20,"breadcrumbs":6,"title":1},"39":{"body":186,"breadcrumbs":6,"title":3},"390":{"body":31,"breadcrumbs":10,"title":5},"391":{"body":14,"breadcrumbs":7,"title":2},"392":{"body":13,"breadcrumbs":6,"title":1},"393":{"body":14,"breadcrumbs":6,"title":1},"394":{"body":32,"breadcrumbs":7,"title":2},"395":{"body":84,"breadcrumbs":9,"title":4},"396":{"body":103,"breadcrumbs":11,"title":6},"397":{"body":38,"breadcrumbs":11,"title":6},"398":{"body":55,"breadcrumbs":13,"title":8},"399":{"body":0,"breadcrumbs":6,"title":1},"4":{"body":19,"breadcrumbs":4,"title":2},"40":{"body":66,"breadcrumbs":4,"title":1},"400":{"body":11,"breadcrumbs":7,"title":2},"401":{"body":62,"breadcrumbs":8,"title":3},"402":{"body":103,"breadcrumbs":9,"title":4},"403":{"body":0,"breadcrumbs":6,"title":1},"404":{"body":16,"breadcrumbs":7,"title":2},"405":{"body":198,"breadcrumbs":7,"title":2},"406":{"body":30,"breadcrumbs":7,"title":2},"407":{"body":0,"breadcrumbs":6,"title":1},"408":{"body":73,"breadcrumbs":8,"title":3},"409":{"body":45,"breadcrumbs":7,"title":2},"41":{"body":104,"breadcrumbs":6,"title":3},"410":{"body":46,"breadcrumbs":13,"title":6},"411":{"body":60,"breadcrumbs":8,"title":1},"412":{"body":31,"breadcrumbs":8,"title":1},"413":{"body":317,"breadcrumbs":8,"title":1},"414":{"body":215,"breadcrumbs":8,"title":1},"415":{"body":205,"breadcrumbs":10,"title":3},"416":{"body":189,"breadcrumbs":8,"title":1},"417":{"body":18,"breadcrumbs":9,"title":2},"418":{"body":265,"breadcrumbs":9,"title":2},"419":{"body":76,"breadcrumbs":10,"title":4},"42":{"body":0,"breadcrumbs":5,"title":2},"420":{"body":88,"breadcrumbs":7,"title":1},"421":{"body":0,"breadcrumbs":9,"title":3},"422":{"body":94,"breadcrumbs":7,"title":1},"423":{"body":250,"breadcrumbs":7,"title":1},"424":{"body":98,"breadcrumbs":8,"title":2},"425":{"body":0,"breadcrumbs":9,"title":3},"426":{"body":124,"breadcrumbs":7,"title":1},"427":{"body":192,"breadcrumbs":7,"title":1},"428":{"body":352,"breadcrumbs":8,"title":2},"429":{"body":0,"breadcrumbs":9,"title":3},"43":{"body":109,"breadcrumbs":4,"title":1},"430":{"body":194,"breadcrumbs":7,"title":1},"431":{"body":369,"breadcrumbs":9,"title":3},"432":{"body":101,"breadcrumbs":7,"title":1},"433":{"body":139,"breadcrumbs":16,"title":7},"434":{"body":75,"breadcrumbs":10,"title":1},"435":{"body":44,"breadcrumbs":11,"title":2},"436":{"body":24,"breadcrumbs":11,"title":2},"437":{"body":166,"breadcrumbs":15,"title":6},"438":{"body":207,"breadcrumbs":12,"title":3},"439":{"body":24,"breadcrumbs":13,"title":4},"44":{"body":121,"breadcrumbs":4,"title":1},"440":{"body":23,"breadcrumbs":12,"title":3},"441":{"body":0,"breadcrumbs":11,"title":2},"442":{"body":16,"breadcrumbs":12,"title":3},"443":{"body":7,"breadcrumbs":11,"title":2},"444":{"body":11,"breadcrumbs":12,"title":3},"445":{"body":18,"breadcrumbs":13,"title":4},"446":{"body":90,"breadcrumbs":11,"title":2},"447":{"body":28,"breadcrumbs":15,"title":6},"448":{"body":28,"breadcrumbs":18,"title":9},"449":{"body":83,"breadcrumbs":7,"title":2},"45":{"body":66,"breadcrumbs":5,"title":2},"450":{"body":38,"breadcrumbs":6,"title":1},"451":{"body":191,"breadcrumbs":6,"title":1},"452":{"body":55,"breadcrumbs":9,"title":4},"453":{"body":84,"breadcrumbs":11,"title":6},"454":{"body":329,"breadcrumbs":9,"title":4},"455":{"body":62,"breadcrumbs":7,"title":2},"456":{"body":0,"breadcrumbs":7,"title":2},"457":{"body":159,"breadcrumbs":7,"title":2},"458":{"body":325,"breadcrumbs":10,"title":5},"459":{"body":415,"breadcrumbs":9,"title":4},"46":{"body":43,"breadcrumbs":6,"title":3},"460":{"body":122,"breadcrumbs":6,"title":1},"461":{"body":58,"breadcrumbs":7,"title":2},"462":{"body":72,"breadcrumbs":8,"title":3},"463":{"body":21,"breadcrumbs":6,"title":1},"464":{"body":38,"breadcrumbs":9,"title":4},"465":{"body":20,"breadcrumbs":8,"title":3},"466":{"body":26,"breadcrumbs":7,"title":2},"467":{"body":6,"breadcrumbs":9,"title":4},"468":{"body":21,"breadcrumbs":7,"title":2},"469":{"body":49,"breadcrumbs":11,"title":5},"47":{"body":0,"breadcrumbs":7,"title":4},"470":{"body":98,"breadcrumbs":7,"title":1},"471":{"body":192,"breadcrumbs":7,"title":1},"472":{"body":97,"breadcrumbs":10,"title":4},"473":{"body":0,"breadcrumbs":9,"title":3},"474":{"body":15,"breadcrumbs":9,"title":3},"475":{"body":163,"breadcrumbs":9,"title":3},"476":{"body":14,"breadcrumbs":10,"title":4},"477":{"body":26,"breadcrumbs":11,"title":5},"478":{"body":75,"breadcrumbs":8,"title":2},"479":{"body":29,"breadcrumbs":9,"title":4},"48":{"body":116,"breadcrumbs":4,"title":1},"480":{"body":16,"breadcrumbs":6,"title":1},"481":{"body":58,"breadcrumbs":9,"title":4},"482":{"body":280,"breadcrumbs":8,"title":3},"483":{"body":8,"breadcrumbs":7,"title":2},"484":{"body":29,"breadcrumbs":7,"title":2},"485":{"body":37,"breadcrumbs":12,"title":5},"486":{"body":131,"breadcrumbs":8,"title":1},"487":{"body":138,"breadcrumbs":10,"title":3},"488":{"body":20,"breadcrumbs":11,"title":4},"489":{"body":385,"breadcrumbs":10,"title":3},"49":{"body":43,"breadcrumbs":6,"title":3},"490":{"body":88,"breadcrumbs":9,"title":2},"491":{"body":177,"breadcrumbs":9,"title":2},"492":{"body":40,"breadcrumbs":10,"title":3},"493":{"body":104,"breadcrumbs":9,"title":2},"494":{"body":38,"breadcrumbs":13,"title":6},"495":{"body":41,"breadcrumbs":9,"title":2},"496":{"body":80,"breadcrumbs":9,"title":2},"497":{"body":76,"breadcrumbs":10,"title":4},"498":{"body":40,"breadcrumbs":7,"title":1},"499":{"body":153,"breadcrumbs":10,"title":4},"5":{"body":100,"breadcrumbs":5,"title":4},"50":{"body":75,"breadcrumbs":7,"title":4},"500":{"body":0,"breadcrumbs":9,"title":3},"501":{"body":63,"breadcrumbs":9,"title":3},"502":{"body":27,"breadcrumbs":8,"title":2},"503":{"body":46,"breadcrumbs":8,"title":2},"504":{"body":111,"breadcrumbs":8,"title":3},"505":{"body":95,"breadcrumbs":9,"title":4},"506":{"body":110,"breadcrumbs":8,"title":3},"507":{"body":21,"breadcrumbs":8,"title":3},"508":{"body":38,"breadcrumbs":7,"title":2},"509":{"body":40,"breadcrumbs":12,"title":5},"51":{"body":23,"breadcrumbs":3,"title":2},"510":{"body":83,"breadcrumbs":12,"title":5},"511":{"body":137,"breadcrumbs":11,"title":4},"512":{"body":24,"breadcrumbs":9,"title":2},"513":{"body":14,"breadcrumbs":2,"title":1},"514":{"body":0,"breadcrumbs":15,"title":7},"515":{"body":51,"breadcrumbs":9,"title":1},"516":{"body":106,"breadcrumbs":12,"title":4},"517":{"body":72,"breadcrumbs":13,"title":5},"518":{"body":0,"breadcrumbs":15,"title":7},"519":{"body":112,"breadcrumbs":12,"title":4},"52":{"body":111,"breadcrumbs":4,"title":1},"520":{"body":112,"breadcrumbs":17,"title":9},"521":{"body":55,"breadcrumbs":14,"title":6},"522":{"body":134,"breadcrumbs":19,"title":11},"523":{"body":42,"breadcrumbs":13,"title":5},"524":{"body":340,"breadcrumbs":12,"title":4},"525":{"body":2,"breadcrumbs":8,"title":1},"53":{"body":98,"breadcrumbs":5,"title":2},"54":{"body":264,"breadcrumbs":4,"title":1},"55":{"body":0,"breadcrumbs":6,"title":3},"56":{"body":391,"breadcrumbs":6,"title":3},"57":{"body":17,"breadcrumbs":5,"title":2},"58":{"body":0,"breadcrumbs":6,"title":3},"59":{"body":44,"breadcrumbs":9,"title":6},"6":{"body":0,"breadcrumbs":4,"title":3},"60":{"body":12,"breadcrumbs":5,"title":2},"61":{"body":12,"breadcrumbs":9,"title":6},"62":{"body":58,"breadcrumbs":6,"title":3},"63":{"body":47,"breadcrumbs":4,"title":1},"64":{"body":6,"breadcrumbs":7,"title":4},"65":{"body":136,"breadcrumbs":5,"title":2},"66":{"body":117,"breadcrumbs":5,"title":2},"67":{"body":200,"breadcrumbs":5,"title":2},"68":{"body":134,"breadcrumbs":6,"title":3},"69":{"body":22,"breadcrumbs":3,"title":2},"7":{"body":51,"breadcrumbs":4,"title":3},"70":{"body":67,"breadcrumbs":3,"title":1},"71":{"body":122,"breadcrumbs":4,"title":2},"72":{"body":121,"breadcrumbs":4,"title":2},"73":{"body":92,"breadcrumbs":4,"title":2},"74":{"body":111,"breadcrumbs":5,"title":3},"75":{"body":99,"breadcrumbs":7,"title":5},"76":{"body":99,"breadcrumbs":7,"title":5},"77":{"body":319,"breadcrumbs":4,"title":2},"78":{"body":171,"breadcrumbs":3,"title":1},"79":{"body":106,"breadcrumbs":6,"title":4},"8":{"body":42,"breadcrumbs":6,"title":5},"80":{"body":165,"breadcrumbs":3,"title":1},"81":{"body":155,"breadcrumbs":4,"title":2},"82":{"body":260,"breadcrumbs":9,"title":4},"83":{"body":185,"breadcrumbs":5,"title":2},"84":{"body":462,"breadcrumbs":4,"title":1},"85":{"body":177,"breadcrumbs":5,"title":2},"86":{"body":168,"breadcrumbs":6,"title":3},"87":{"body":199,"breadcrumbs":4,"title":1},"88":{"body":215,"breadcrumbs":4,"title":1},"89":{"body":351,"breadcrumbs":4,"title":1},"9":{"body":56,"breadcrumbs":3,"title":2},"90":{"body":229,"breadcrumbs":6,"title":3},"91":{"body":13,"breadcrumbs":9,"title":4},"92":{"body":90,"breadcrumbs":7,"title":2},"93":{"body":288,"breadcrumbs":7,"title":2},"94":{"body":114,"breadcrumbs":2,"title":1},"95":{"body":213,"breadcrumbs":4,"title":3},"96":{"body":80,"breadcrumbs":11,"title":3},"97":{"body":6,"breadcrumbs":10,"title":2},"98":{"body":149,"breadcrumbs":10,"title":2},"99":{"body":127,"breadcrumbs":13,"title":5}},"docs":{"0":{"body":"The AWS Rust SDK aims to provide an official, high quality & complete interface to AWS services. We plan to eventually use the CRT to provide signing & credential management. The Rust SDK will provide first-class support for the CRT as well as Tokio & Hyper . The Rust SDK empowers advanced customers to bring their own HTTP/IO implementations. Our design choices are guided by our Tenets .","breadcrumbs":"Design Overview » Design Overview","id":"0","title":"Design Overview"},"1":{"body":"The design builds on the learnings, ideas, hard work, and GitHub issues of the 142 Rusoto contributors & thousands of users who built this first and learned the hard way.","breadcrumbs":"Design Overview » Acknowledgments","id":"1","title":"Acknowledgments"},"10":{"body":"","breadcrumbs":"Design FAQ » Design FAQ","id":"10","title":"Design FAQ"},"100":{"body":"If you have your own source of credentials, you may opt-out of the standard credential provider chain. To do this, implement the ProvideCredentials trait. NOTE: aws_types::Credentials already implements ProvideCredentials. If you want to use the SDK with static credentials, you're already done! use aws_types::credentials::{ProvideCredentials, provide_credentials::future, Result}; struct MyCustomProvider; impl MyCustomProvider { pub async fn load_credentials(&self) -> Result { todo!() // A regular async function }\n} impl ProvideCredentials for MyCustomProvider { fn provide_credentials<'a>(&'a self) -> future::ProvideCredentials<'a> where Self: 'a, { future::ProvideCredentials::new(self.load_credentials()) }\n} Hint: If your credential provider is not asynchronous, you can use ProvideCredentials::ready instead to save an allocation. After writing your custom provider, you'll use it in when constructing the configuration: #[tokio::main]\nasync fn main() { let config = aws_config::from_env().credentials_provider(MyCustomProvider).load().await; let dynamodb = dynamodb::new(&config);\n}","breadcrumbs":"RFCs » RFC-0001: Sharing configuration between multiple clients » Specifying a custom credential provider","id":"100","title":"Specifying a custom credential provider"},"101":{"body":"Achieving this design consists of three major changes: Add a Config struct to aws-types. This contains a config, but with no logic to construct it. This represents what configuration SDKS need, but not how to load the information from the environment. Create the aws-config crate. aws-config contains the logic to load configuration from the environment. No generated service clients will depend on aws-config. This is critical to avoid circular dependencies and to allow aws-config to depend on other AWS services. aws-config contains individual providers as well as a pre-assembled default provider chain for region and credentials. It will also contain crate features to automatically bring in HTTPS and async-sleep implementations. Remove all \"business logic\" from aws-types. aws-types should be an interface-only crate that is extremely stable. The ProvideCredentials trait should move into aws-types. The region provider trait which only exists to support region-chaining will move out of aws-types into aws-config. Services will continue to generate their own Config structs. These will continue to be customizable as they are today, however, they won't have any default resolvers built in. Each AWS config will implement From<&aws_types::SharedConfig> . A convenience method to new() a fluent client directly from a shared config will also be generated.","breadcrumbs":"RFCs » RFC-0001: Sharing configuration between multiple clients » Proposed Design","id":"101","title":"Proposed Design"},"102":{"body":"This RFC proposes adding region and credentials providers support to the shared config. A future RFC will propose integration with HTTP settings, HTTPs connectors, and async sleep. struct Config { // private fields ...\n} impl Config { pub fn region(&self) -> Option<&Region> { self.region.as_ref() } pub fn credentials_provider(&self) -> Option { self.credentials_provider.clone() } pub fn builder() -> Builder { Builder::default() }\n} The Builder for Config allows customers to provide individual overrides and handles the insertion of the default chain for regions and credentials.","breadcrumbs":"RFCs » RFC-0001: Sharing configuration between multiple clients » Shared Config Implementation","id":"102","title":"Shared Config Implementation"},"103":{"body":"Sleep and Connector are both runtime dependent features. aws-config will define rt-tokio and rustls and native-tls optional features. This centralizes the Tokio/Hyper dependency eventually removing the need for each service to maintain their own Tokio/Hyper features. Although not proposed in this RFC, shared config will eventually gain support for creating an HTTPs client from HTTP settings.","breadcrumbs":"RFCs » RFC-0001: Sharing configuration between multiple clients » Sleep + Connectors","id":"103","title":"Sleep + Connectors"},"104":{"body":"Currently, the .build() method on service config will fill in defaults. As part of this change, .build() called on the service config with missing properties will fill in \"empty\" defaults. If no credentials provider is given, a NoCredentials provider will be set, and Region will remain as None.","breadcrumbs":"RFCs » RFC-0001: Sharing configuration between multiple clients » The .build() method on ::Config","id":"104","title":"The .build() method on ::Config"},"105":{"body":"The introduction of Config to aws-types is not without risks. If a customer depends on a version aws-config that uses Config that is incompatible, they will get confusing compiler errors. An example of a problematic set of dependent versions: ┌─────────────────┐ ┌───────────────┐\n│ aws-types = 0.1 │ │aws-types= 0.2 │\n└─────────────────┘ └───────────────┘ ▲ ▲ │ │ │ │ │ │ ┌─────────┴─────────────┐ ┌────────┴───────┐ │aws-sdk-dynamodb = 0.5 │ │aws-config = 0.6│ └───────────┬───────────┘ └───────┬────────┘ │ │ │ │ │ │ │ │ │ │ ├─────────────────────┬────────┘ │ my-lambda-function │ └─────────────────────┘ To mitigate this risk, we will need to make aws-types essentially permanently stable. Changes to aws-types need to be made with extreme care. This will ensure that two versions of aws-types never end up in a customer's dependency tree. We will dramatically reduce the surface area of aws-types to contain only interfaces. Several breaking changes will be made as part of this, notably, the profile file parsing will be moved out of aws-types. Finally, to mitigate this risk even further, services will pub use items from aws-types directly which means that even if a dependency mismatch exists, it is still possible for customers to work around it.","breadcrumbs":"RFCs » RFC-0001: Sharing configuration between multiple clients » Stability and Versioning","id":"105","title":"Stability and Versioning"},"106":{"body":"ProvideRegion becomes async using a newtype'd future. AsyncProvideCredentials is removed. ProvideCredentials becomes async using a newtype'd future. ProvideCredentials moved into aws-types. Credentials moved into aws-types Create aws-config. Profile-file parsing moved into aws-config, region chain & region environment loaders moved to aws-config. os_shim_internal moved to ??? aws-smithy-types? Add Config to aws-types. Ensure that it's set up to add new members while remaining backwards compatible. Code generate From<&SharedConfig> for ::Config Code generate ::Client::new(&shared_config) Remove ::from_env","breadcrumbs":"RFCs » RFC-0001: Sharing configuration between multiple clients » Changes Checklist","id":"106","title":"Changes Checklist"},"107":{"body":"Connector construction needs to be a function of HTTP settings An AsyncSleep should be added to aws-types::Config","breadcrumbs":"RFCs » RFC-0001: Sharing configuration between multiple clients » Open Issues","id":"107","title":"Open Issues"},"108":{"body":"Status: Accepted For a summarized list of proposed changes, see the Changes Checklist section. Most AWS SDK operations use HTTP/1.1, but bi-directional streaming operations that use the Event Stream message framing format need to use HTTP/2 (h2). Smithy models can also customize which HTTP versions are used in each individual protocol trait. For example, @restJson1 has attributes http and eventStreamHttp to list out the versions that should be used in a priority order. There are two problems in play that this doc attempts to solve: Connector Creation : Customers need to be able to create connectors with the HTTP settings they desire, and these custom connectors must align with what the Smithy model requires. Connector Selection : The generated code must be able to select the connector that best matches the requirements from the Smithy model.","breadcrumbs":"RFCs » RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream » RFC: Supporting multiple HTTP versions for SDKs that use Event Stream","id":"108","title":"RFC: Supporting multiple HTTP versions for SDKs that use Event Stream"},"109":{"body":"Today, there are three layers of Client that are easy to confuse, so to make the following easier to follow, the following terms will be used: Connector : An implementor of Tower's Service trait that converts a request into a response. This is typically a thin wrapper around a Hyper client. Smithy Client : A aws_smithy_client::Client struct that is responsible for gluing together the connector, middleware, and retry policy. This isn't intended to be used directly. Fluent Client : A code generated Client that has methods for each service operation on it. A fluent builder is generated alongside it to make construction easier. AWS Client : A specialized Fluent Client that uses a DynConnector, DefaultMiddleware, and Standard retry policy. All of these are just called Client in code today. This is something that could be clarified in a separate refactor.","breadcrumbs":"RFCs » RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream » Terminology","id":"109","title":"Terminology"},"11":{"body":"Smithy is the interface design language used by AWS services. smithy-rs allows users to generate a Rust client for any Smithy based service (pending protocol support), including those outside of AWS.","breadcrumbs":"Design FAQ » What is Smithy?","id":"11","title":"What is Smithy?"},"110":{"body":"Fluent clients currently keep a handle to a single Smithy client, which is a wrapper around the underlying connector. When constructing operation builders, this handle is Arc cloned and given to the new builder instances so that their send() calls can initiate a request. The generated fluent client code ends up looking like this: struct Handle { client: aws_smithy_client::Client, conf: crate::Config,\n} pub struct Client { handle: Arc>,\n} Functions are generated per operation on the fluent client to gain access to the individual operation builders. For example: pub fn assume_role(&self) -> fluent_builders::AssumeRole { fluent_builders::AssumeRole::new(self.handle.clone())\n} The fluent operation builders ultimately implement send(), which chooses the one and only Smithy client out of the handle to make the request with: pub struct AssumeRole { handle: std::sync::Arc>, inner: crate::input::assume_role_input::Builder,\n} impl AssumeRole where ...{ pub async fn send(self) -> Result> where ... { // Setup code omitted ... // Make the actual request self.handle.client.call(op).await }\n} Smithy clients are constructed from a connector, as shown: let connector = Builder::new() .https() .middleware(...) .build();\nlet client = Client::with_config(connector, Config::builder().build()); The https() method on the Builder constructs the actual Hyper client, and is driven off Cargo features to select the correct TLS implementation. For example: #[cfg(feature = \"rustls\")]\npub fn https() -> Https { let https = hyper_rustls::HttpsConnector::with_native_roots(); let client = hyper::Client::builder().build::<_, SdkBody>(https); // HyperAdapter is a Tower `Service` request -> response connector that just calls the Hyper client crate::hyper_impls::HyperAdapter::from(client)\n}","breadcrumbs":"RFCs » RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream » How Clients Work Today","id":"110","title":"How Clients Work Today"},"111":{"body":"Customers need to be able to provide HTTP settings, such as timeouts, for all connectors that the clients use. These should come out of the SharedConfig when it is used. Connector creation also needs to be customizable so that alternate HTTP implementations can be used, or so that a fake implementation can be used for tests. To accomplish this, SharedConfig will have a make_connector member. A customer would configure it as such: let config = some_shared_config_loader() .with_http_settings(my_http_settings) .with_make_connector(|reqs: &MakeConnectorRequirements| { Some(MyCustomConnector::new(reqs)) }) .await; The passed in MakeConnectorRequirements will hold the customer-provided HttpSettings as well as any Smithy-modeled requirements, which will just be HttpVersion for now. The MakeConnectorRequirements struct will be marked non_exhaustive so that new requirements can be added to it as the SDK evolves. A default make_connector implementation would be provided that creates a Hyper connector based on the Cargo feature flags. This might look something like this: #[cfg(feature = \"rustls\")]\npub fn default_connector(reqs: &HttpRequirements) -> HyperAdapter { let https = hyper_rustls::HttpsConnector::with_native_roots(); let mut builder = hyper::Client::builder(); builder = configure_settings(builder, &reqs.http_settings); if let Http2 = &reqs.http_version { builder = builder.http2_only(true); } HyperAdapter::from(builder.build::<_, SdkBody>(https))\n} For any given service, make_connector could be called multiple times to create connectors for all required HTTP versions and settings. Note: the make_connector returns an Option since an HTTP version may not be required, but rather, preferred according to a Smithy model. For operations that list out [\"h2\", \"HTTP/1.1\"] as the desired versions, a customer could choose to provide only an HTTP 1 connector, and the operation should still succeed.","breadcrumbs":"RFCs » RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream » Solving the Connector Creation Problem","id":"111","title":"Solving the Connector Creation Problem"},"112":{"body":"Each service operation needs to be able to select a connector that meets its requirements best from the customer provided connectors. Initially, the only selection criteria will be the HTTP version, but later when per-operation HTTP settings are implemented, the connector will also need to be keyed off of those settings. Since connector creation is not a cheap process, connectors will need to be cached after they are created. This caching is currently handled by the Handle in the fluent client, which holds on to the Smithy client. This cache needs to be adjusted to: Support multiple connectors, keyed off of the customer provided HttpSettings, and also off of the Smithy modeled requirements. Be lazy initialized. Services that have a mix of Event Stream and non-streaming operations shouldn't create an HTTP/2 client if the customer doesn't intend to use the Event Stream operations that require it. To accomplish this, the Handle will hold a cache that is optimized for many reads and few writes: #[derive(Debug, Hash, Eq, PartialEq)]\nstruct ConnectorKey { http_settings: HttpSettings, http_version: HttpVersion,\n} struct Handle { clients: RwLock, aws_smithy_client::Client>>, conf: crate::Config,\n} pub struct Client { handle: Arc>,\n} With how the generics are organized, the connector type will have to be the same between HTTP implementations, but this should be fine since it is generally a thin wrapper around a separate HTTP implementor. For cases where it is not, the custom connector type can host its own dyn Trait solution. The HttpRequirements struct will hold HttpSettings as copy-on-write so that it can be used for cache lookup without having to clone HttpSettings: struct HttpRequirements<'a> { http_settings: Cow<'a, HttpSettings>, http_version: HttpVersion,\n} impl<'a> HttpRequirements<'a> { // Needed for converting a borrowed HttpRequirements into an owned cache key for cache population pub fn into_owned(self) -> HttpRequirements<'static> { Self { http_settings: Cow::Owned(self.http_settings.into_owned()), http_version: self.http_version, } }\n} With the cache established, each operation needs to be aware of its requirements. The code generator will be updated to store a prioritized list of HttpVersion in the property bag in an input's make_operation() method. This prioritized list will come from the Smithy protocol trait's http or eventStreamHttp attribute, depending on the operation. The fluent client will then pull this list out of the property bag so that it can determine which connector to use. This indirection is necessary so that an operation still holds all information needed to make a service call from the Smithy client directly. Note: This may be extended in the future to be more than just HttpVersion, for example, when per-operation HTTP setting overrides are implemented. This doc is not attempting to solve that problem. In the fluent client, this will look as follows: impl AssumeRole where ... { pub async fn send(self) -> Result> where ... { let input = self.create_input()?; let op = input.make_operation(&self.handle.conf)?; // Grab the `make_connector` implementation let make_connector = self.config.make_connector(); // Acquire the prioritized HttpVersion list let http_versions = op.properties().get::(); // Make the actual request (using default HttpSettings until modifying those is implemented) let client = self.handle .get_or_create_client(make_connector, &default_http_settings(), &http_versions) .await?; client.call(op).await }\n} If an operation requires a specific protocol version, and if the make_connection implementation can't provide that it, then the get_or_create_client() function will return SdkError::ConstructionFailure indicating the error.","breadcrumbs":"RFCs » RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream » Solving the Connector Selection Problem","id":"112","title":"Solving the Connector Selection Problem"},"113":{"body":"Create HttpVersion in aws-smithy-http with Http1_1 and Http2 Refactor existing https() connector creation functions to take HttpVersion Add make_connector to SharedConfig, and wire up the https() functions as a default Create HttpRequirements in aws-smithy-http Implement the connector cache on Handle Implement function to calculate a minimum required set of HTTP versions from a Smithy model in the code generator Update the make_operation code gen to put an HttpVersionList into the operation property bag Update the fluent client send() function code gen grab the HTTP version list and acquire the correct connector with it Add required defaulting for models that don't set the optional http and eventStreamHttp protocol trait attributes","breadcrumbs":"RFCs » RFC-0002: Supporting multiple HTTP versions for SDKs that use Event Stream » Changes Checklist","id":"113","title":"Changes Checklist"},"114":{"body":"Status: Implemented For a summarized list of proposed changes, see the Changes Checklist section. Several AWS services allow for presigned requests in URL form, which is described well by S3's documentation on authenticating requests using query parameters . This doc establishes the customer-facing API for creating these presigned URLs and how they will be implemented in a generic fashion in the SDK codegen.","breadcrumbs":"RFCs » RFC-0003: API for Pre-signed URLs » RFC: API for Presigned URLs","id":"114","title":"RFC: API for Presigned URLs"},"115":{"body":"To differentiate between the clients that are present in the generated SDK today, the following terms will be used throughout this doc: Smithy Client : A aws_smithy_client::Client struct that is responsible for gluing together the connector, middleware, and retry policy. This is not generated and lives in the aws-smithy-client crate. Fluent Client : A code-generated Client that has methods for each service operation on it. A fluent builder is generated alongside it to make construction easier.","breadcrumbs":"RFCs » RFC-0003: API for Pre-signed URLs » Terminology","id":"115","title":"Terminology"},"116":{"body":"Today, presigned URLs take an expiration time that's not part of the service API. The SDK will make this configurable as a separate struct so that there's no chance of name collisions, and so that additional fields can be added in the future. Fields added later will require defaulting for backwards compatibility. Customers should also be able to set a start time on the presigned URL's expiration so that they can generate URLs that become active in the future. An optional start_time option will be available and default to SystemTime::now(). Construction PresigningConfig can be done with a builder, but a PresigningConfig::expires_in convenience function will be provided to bypass the builder for the most frequent use-case. #[non_exhaustive]\n#[derive(Debug, Clone)]\npub struct PresigningConfig { start_time: SystemTime, expires_in: Duration,\n} #[non_exhaustive]\n#[derive(Debug)]\npub struct Builder { start_time: Option, expires_in: Option,\n} impl Builder { pub fn start_time(self, start_time: SystemTime) -> Self { ... } pub fn set_start_time(&mut self, start_time: Option) { ... } pub fn expires_in(self, expires_in: Duration) -> Self { ... } pub fn set_expires_in(&mut self, expires_in: Option) { ... } // Validates `expires_in` is no greater than one week pub fn build(self) -> Result { ... }\n} impl PresigningConfig { pub fn expires_in(expires_in: Duration) -> PresigningConfig { Self::builder().expires(expires).build().unwrap() } pub fn builder() -> Builder { ... }\n} Construction of PresigningConfig will validate that expires_in is no greater than one week, as this is the longest supported expiration time for SigV4. This validation will result in a panic. It's not inconceivable that PresigningConfig will need additional service-specific parameters as customizations, so it will be code generated with each service rather than living a shared location.","breadcrumbs":"RFCs » RFC-0003: API for Pre-signed URLs » Presigned URL config","id":"116","title":"Presigned URL config"},"117":{"body":"The generated fluent builders for operations that support presigning will have a presigned() method in addition to send() that will return a presigned URL rather than sending the request. For S3's GetObject, the usage of this will look as follows: let config = aws_config::load_config_from_environment().await;\nlet client = s3::Client::new(&config);\nlet presigning_config = PresigningConfig::expires_in(Duration::from_secs(86400));\nlet presigned: PresignedRequest = client.get_object() .bucket(\"example-bucket\") .key(\"example-object\") .presigned(presigning_config) .await?; This API requires a client, and for use-cases where no actual service calls need to be made, customers should be able to create presigned URLs without the overhead of an HTTP client. Once the HTTP Versions RFC is implemented, the underlying HTTP client won't be created until the first service call, so there will be no HTTP client overhead to this approach. In a step away from the general pattern of keeping fluent client capabilities in line with Smithy client capabilities, creating presigned URLs directly from the Smithy client will not be supported. This is for two reasons: The Smithy client is not code generated, so adding a method to do presigning would apply to all operations, but not all operations can be presigned. Presigned URLs are not currently a Smithy concept ( although this may change soon ). The result of calling presigned() is a PresignedRequest, which is a wrapper with delegating functions around http::Request<()> so that the request method and additional signing headers are also made available. This is necessary since there are some presignable POST operations that require the signature to be in the headers rather than the query. Note: Presigning needs to be async because the underlying credentials provider used to sign the request may need to make service calls to acquire the credentials.","breadcrumbs":"RFCs » RFC-0003: API for Pre-signed URLs » Fluent Presigned URL API","id":"117","title":"Fluent Presigned URL API"},"118":{"body":"Even though generating a presigned URL through the fluent client doesn't necessitate an HTTP client, it will be clearer that this is the case by allowing the creation of presigned URLs directly from an input. This would look as follows: let config = aws_config::load_config_from_environment().await;\nlet presigning_config = PresigningConfig::expires_in(Duration::from_secs(86400));\nlet presigned: PresignedRequest = GetObjectInput::builder() .bucket(\"example-bucket\") .key(\"example-bucket\") .presigned(&config, presigning_config) .await?; Creating the URL through the input will exercise the same code path as creating it through the client, but it will be more apparent that the overhead of a client isn't present.","breadcrumbs":"RFCs » RFC-0003: API for Pre-signed URLs » Input Presigned URL API","id":"118","title":"Input Presigned URL API"},"119":{"body":"From an SDK's perspective, the following are required to make a presigned URL: Valid request input Endpoint Credentials to sign with Signing implementation The AWS middleware provides everything except the request, and the request is provided as part of the fluent builder API. The generated code needs to be able to run the middleware to fully populate a request property bag, but not actually dispatch it. The expires_in value from the presigning config needs to be piped all the way through to the signer. Additionally, the SigV4 signing needs to adjusted to do query param signing, which is slightly different than its header signing. Today, request dispatch looks as follows: The customer creates a new fluent builder by calling client.operation_name(), fills in inputs, and then calls send(). send(): Builds the final input struct, and then calls its make_operation() method with the stored config to create a Smithy Operation. Calls the underlying Smithy client with the operation. The Smithy client constructs a Tower Service with AWS middleware and a dispatcher at the bottom, and then executes it. The middleware acquire and add required signing parameters (region, credentials, endpoint, etc) to the request property bag. The SigV4 signing middleware signs the request by adding HTTP headers to it. The dispatcher makes the actual HTTP request and returns the response all the way back up the Tower. Presigning will take advantage of a lot of these same steps, but will cut out the Operation and replace the dispatcher with a presigned URL generator: The customer creates a new fluent builder by calling client.operation_name(), fills in inputs, and then calls presigned(). presigned(): Builds the final input struct, calls the make_operation() method with the stored config, and then extracts the request from the operation (discarding the rest). Mutates the OperationSigningConfig in the property bag to: Change the signature_type to HttpRequestQueryParams so that the signer runs the correct signing logic. Set expires_in to the value given by the customer in the presigning config. Constructs a Tower Service with AwsMiddleware layered in, and a PresignedUrlGeneratorLayer at the bottom. Calls the Tower Service and returns its result The AwsMiddleware will sign the request. The PresignedUrlGeneratorLayer directly returns the request since all of the work is done by the middleware. It should be noted that the presigned() function above is on the generated input struct, so implementing this for the input API is identical to implementing it for the fluent client. All the code for the new make_request() is already in the existing make_operation() and will just need to be split out.","breadcrumbs":"RFCs » RFC-0003: API for Pre-signed URLs » Behind the scenes","id":"119","title":"Behind the scenes"},"12":{"body":"Compilation time: Although it's possible to use cargo features to conditionally compile individual services, we decided that this added significant complexity to the generated code. In Rust the \"unit of compilation\" is a Crate, so by using smaller crates we can get better compilation parallelism. Furthermore, ecosystem services like docs.rs have an upper limit on the maximum amount of time required to build an individual crate—if we packaged the entire SDK as a single crate, we would quickly exceed this limit. Versioning: It is expected that over time we may major-version-bump individual services. New updates will be pushed for some AWS service nearly every day. Maintaining separate crates allows us to only increment versions for the relevant pieces that change. See Independent Crate Versioning for more info.","breadcrumbs":"Design FAQ » Why is there one crate per service?","id":"12","title":"Why is there one crate per service?"},"120":{"body":"AWS models don't currently have any information about which operations can be presigned. To work around this, the Rust SDK will create a synthetic trait to model presigning with, and apply this trait to known presigned operations via customization. The code generator will look for this synthetic trait when creating the fluent builders and inputs to know if a presigned() method should be added.","breadcrumbs":"RFCs » RFC-0003: API for Pre-signed URLs » Modeling Presigning","id":"120","title":"Modeling Presigning"},"121":{"body":"If a presignable operation input has a member named presigned, then there will be a name collision with the function to generate a presigned URL. To mitigate this, RustReservedWords will be updated to rename the presigned member to presigned_value similar to how send is renamed .","breadcrumbs":"RFCs » RFC-0003: API for Pre-signed URLs » Avoiding name collision","id":"121","title":"Avoiding name collision"},"122":{"body":"Update aws-sigv4 to support query param signing Create PresignedOperationSyntheticTrait Customize models for known presigned operations Create PresigningConfig and its builder Implement PresignedUrlGeneratorLayer Create new AWS codegen decorator to: Add new presigned() method to input code generator Add new presigned() method to fluent client generator Update RustReservedWords to reserve presigned() Add integration test to S3 Add integration test to Polly Add examples for using presigning for: S3 GetObject and PutObject Polly SynthesizeSpeech","breadcrumbs":"RFCs » RFC-0003: API for Pre-signed URLs » Changes Checklist","id":"122","title":"Changes Checklist"},"123":{"body":"Status: Implemented For a summarized list of proposed changes, see the Changes Checklist section. It is not currently possible for users of the SDK to configure a client's maximum number of retry attempts. This RFC establishes a method for users to set the number of retries to attempt when calling a service and would allow users to disable retries entirely. This RFC would introduce breaking changes to the retry module of the aws-smithy-client crate.","breadcrumbs":"RFCs » RFC-0004: Retry Behavior » RFC: Retry Behavior","id":"123","title":"RFC: Retry Behavior"},"124":{"body":"Smithy Client : A aws_smithy_client::Client struct that is responsible for gluing together the connector, middleware, and retry policy. This is not generated and lives in the aws-smithy-client crate. Fluent Client : A code-generated Client that has methods for each service operation on it. A fluent builder is generated alongside it to make construction easier. AWS Client : A specialized Fluent Client that defaults to using a DynConnector, AwsMiddleware, and Standard retry policy. Shared Config : An aws_types::Config struct that is responsible for storing shared configuration data that is used across all services. This is not generated and lives in the aws-types crate. Service-specific Config : A code-generated Config that has methods for setting service-specific configuration. Each Config is defined in the config module of its parent service. For example, the S3-specific config struct is useable from aws_sdk_s3::config::Config and re-exported as aws_sdk_s3::Config. Standard retry behavior : The standard set of retry rules across AWS SDKs. This mode includes a standard set of errors that are retried, and support for retry quotas. The default maximum number of attempts with this mode is three, unless max_attempts is explicitly configured. Adaptive retry behavior : Adaptive retry mode dynamically limits the rate of AWS requests to maximize success rate. This may be at the expense of request latency. Adaptive retry mode is not recommended when predictable latency is important. Note: supporting the \"adaptive\" retry behavior is considered outside the scope of this RFC","breadcrumbs":"RFCs » RFC-0004: Retry Behavior » Terminology","id":"124","title":"Terminology"},"125":{"body":"This RFC will demonstrate (with examples) the following ways that Users can set the maximum number of retry attempts: By calling the Config::retry_config(..) or Config::disable_retries() methods when building a service-specific config By calling the Config::retry_config(..) or Config::disable_retries() methods when building a shared config By setting the AWS_MAX_ATTEMPTS environment variable The above list is in order of decreasing precedence e.g. setting maximum retry attempts with the max_attempts builder method will override a value set by AWS_MAX_ATTEMPTS. The default number of retries is 3 as specified in the AWS SDKs and Tools Reference Guide .","breadcrumbs":"RFCs » RFC-0004: Retry Behavior » Configuring the maximum number of retries","id":"125","title":"Configuring the maximum number of retries"},"126":{"body":"Here's an example app that logs your AWS user's identity use aws_sdk_sts as sts; #[tokio::main]\nasync fn main() -> Result<(), sts::Error> { let config = aws_config::load_from_env().await; let sts = sts::Client::new(&config); let resp = sts.get_caller_identity().send().await?; println!(\"your user id: {}\", resp.user_id.unwrap_or_default()); Ok(())\n} Then, in your terminal: # Set the env var before running the example program\nexport AWS_MAX_ATTEMPTS=5\n# Run the example program\ncargo run","breadcrumbs":"RFCs » RFC-0004: Retry Behavior » Setting an environment variable","id":"126","title":"Setting an environment variable"},"127":{"body":"Here's an example app that creates a shared config with custom retry behavior and then logs your AWS user's identity use aws_sdk_sts as sts;\nuse aws_types::retry_config::StandardRetryConfig; #[tokio::main]\nasync fn main() -> Result<(), sts::Error> { let retry_config = StandardRetryConfig::builder().max_attempts(5).build(); let config = aws_config::from_env().retry_config(retry_config).load().await; let sts = sts::Client::new(&config); let resp = sts.get_caller_identity().send().await?; println!(\"your user id: {}\", resp.user_id.unwrap_or_default()); Ok(())\n}","breadcrumbs":"RFCs » RFC-0004: Retry Behavior » Calling a method on an AWS shared config","id":"127","title":"Calling a method on an AWS shared config"},"128":{"body":"Here's an example app that creates a service-specific config with custom retry behavior and then logs your AWS user's identity use aws_sdk_sts as sts;\nuse aws_types::retry_config::StandardRetryConfig; #[tokio::main]\nasync fn main() -> Result<(), sts::Error> { let config = aws_config::load_from_env().await; let retry_config = StandardRetryConfig::builder().max_attempts(5).build(); let sts_config = sts::config::Config::from(&config).retry_config(retry_config).build(); let sts = sts::Client::new(&sts_config); let resp = sts.get_caller_identity().send().await?; println!(\"your user id: {}\", resp.user_id.unwrap_or_default()); Ok(())\n}","breadcrumbs":"RFCs » RFC-0004: Retry Behavior » Calling a method on service-specific config","id":"128","title":"Calling a method on service-specific config"},"129":{"body":"Here's an example app that creates a shared config that disables retries and then logs your AWS user's identity use aws_sdk_sts as sts;\nuse aws_types::config::Config; #[tokio::main]\nasync fn main() -> Result<(), sts::Error> { let config = aws_config::from_env().disable_retries().load().await; let sts_config = sts::config::Config::from(&config).build(); let sts = sts::Client::new(&sts_config); let resp = sts.get_caller_identity().send().await?; println!(\"your user id: {}\", resp.user_id.unwrap_or_default()); Ok(())\n} Retries can also be disabled by explicitly passing the RetryConfig::NoRetries enum variant to the retry_config builder method: use aws_sdk_sts as sts;\nuse aws_types::retry_config::RetryConfig; #[tokio::main]\nasync fn main() -> Result<(), sts::Error> { let config = aws_config::load_from_env().await; let sts_config = sts::config::Config::from(&config).retry_config(RetryConfig::NoRetries).build(); let sts = sts::Client::new(&sts_config); let resp = sts.get_caller_identity().send().await?; println!(\"your user id: {}\", resp.user_id.unwrap_or_default()); Ok(())\n}","breadcrumbs":"RFCs » RFC-0004: Retry Behavior » Disabling retries","id":"129","title":"Disabling retries"},"13":{"body":"Compilation time: serde makes heavy use of several crates (proc-macro2, quote, and syn) that are very expensive to compile. Several service crates are already quite large and adding a serde dependency would increase compile times beyond what we consider acceptable. When we last checked, adding serde derives made compilation 23% slower. Misleading results: We can't use serde for serializing requests to AWS or deserializing responses from AWS because both sides of that process would require too much customization. Adding serialize/deserialize impls for operations has the potential to confuse users when they find it doesn't actually capture all the necessary information (like headers and trailers) sent in a request or received in a response. In the future, we may add serde support behind a feature gate. However, we would only support this for operation Input and Output structs with the aim of making SDK-related tests easier to set up and run.","breadcrumbs":"Design FAQ » Why don't the SDK service crates implement serde::Serialize or serde::Deserialize for any types?","id":"13","title":"Why don't the SDK service crates implement serde::Serialize or serde::Deserialize for any types?"},"130":{"body":"Currently, when users want to send a request, the following occurs: The user creates either a shared config or a service-specific config The user creates a fluent client for the service they want to interact with and passes the config they created. Internally, this creates an AWS client with a default retry policy The user calls an operation builder method on the client which constructs a request The user sends the request by awaiting the send() method The smithy client creates a new Service and attaches a copy of its retry policy The Service is called, sending out the request and retrying it according to the retry policy After this change, the process will work like this: The user creates either a shared config or a service-specific config If AWS_MAX_ATTEMPTS is set to zero, this is invalid and we will log it with tracing::warn. However, this will not error until a request is made If AWS_MAX_ATTEMPTS is 1, retries will be disabled If AWS_MAX_ATTEMPTS is greater than 1, retries will be attempted at most as many times as is specified If the user creates the config with the .disable_retries builder method, retries will be disabled If the user creates the config with the retry_config builder method, retry behavior will be set according to the RetryConfig they passed The user creates a fluent client for the service they want to interact with and passes the config they created Provider precedence will determine what retry behavior is actually set, working like how Region is set The user calls an operation builder method on the client which constructs a request The user sends the request by awaiting the send() method The smithy client creates a new Service and attaches a copy of its retry policy The Service is called, sending out the request and retrying it according to the retry policy These changes will be made in such a way that they enable us to add the \"adaptive\" retry behavior at a later date without introducing a breaking change.","breadcrumbs":"RFCs » RFC-0004: Retry Behavior » Behind the scenes","id":"130","title":"Behind the scenes"},"131":{"body":"Create new Kotlin decorator RetryConfigDecorator Based on RegionDecorator.kt This decorator will live in the codegen project because it has relevance outside the SDK Breaking changes: Rename aws_smithy_client::retry::Config to StandardRetryConfig Rename aws_smithy_client::retry::Config::with_max_retries method to with_max_attempts in order to follow AWS convention Passing 0 to with_max_attempts will panic with a helpful, descriptive error message Create non-exhaustive aws_types::retry_config::RetryConfig enum wrapping structs that represent specific retry behaviors A NoRetry variant that disables retries. Doesn't wrap a struct since it doesn't need to contain any data A Standard variant that enables the standard retry behavior. Wraps a StandardRetryConfig struct. Create aws_config::meta::retry_config::RetryConfigProviderChain Create aws_config::meta::retry_config::ProvideRetryConfig Create EnvironmentVariableMaxAttemptsProvider struct Setting AWS_MAX_ATTEMPTS=0 and trying to load from env will panic with a helpful, descriptive error message Add retry_config method to aws_config::ConfigLoader Update AwsFluentClientDecorator to correctly configure the max retry attempts of its inner aws_hyper::Client based on the passed-in Config Add tests Test that setting retry_config to 1 disables retries Test that setting retry_config to n limits retries to n where n is a non-zero integer Test that correct precedence is respected when overriding retry behavior in a service-specific config Test that correct precedence is respected when overriding retry behavior in a shared config Test that creating a config from env if AWS_MAX_ATTEMPTS=0 will panic with a helpful, descriptive error message Test that setting invalid max_attempts=0 with a StandardRetryConfig will panic with a helpful, descriptive error message","breadcrumbs":"RFCs » RFC-0004: Retry Behavior » Changes checklist","id":"131","title":"Changes checklist"},"132":{"body":"Status: RFC The Rust Smithy Framework is a full-fledged service framework whose main responsibility is to handle request lifecycles from beginning to end. It takes care of input de-serialization, operation execution, output serialization, error handling, and provides facilities to fulfill the requirements below.","breadcrumbs":"RFCs » RFC-0005: Smithy Rust service framework » RFC: Smithy Rust Service Framework","id":"132","title":"RFC: Smithy Rust Service Framework"},"133":{"body":"","breadcrumbs":"RFCs » RFC-0005: Smithy Rust service framework » Requirements","id":"133","title":"Requirements"},"134":{"body":"Server side code is generated from Smithy models and implements operations, input and output structures, and errors defined in the service model.","breadcrumbs":"RFCs » RFC-0005: Smithy Rust service framework » Smithy model-driven code generation","id":"134","title":"Smithy model-driven code generation"},"135":{"body":"This new framework is built with performance in mind. It refrains from allocating memory when not needed and tries to use a majority of borrowed types, handling their memory lifetimes so that a request body can be stored in memory only once and not cloned if possible. The code is implemented on solid and widely used foundations. It uses Hyper to handle the HTTP requests, the Tokio ecosystem for asynchronous (non-blocking) operations and Tower to implement middleware such as timeouts, rate limiting, retries, and more. CPU intensive operations are scheduled on a separated thread-pool to avoid blocking the event loop. It uses Tokio axum , an HTTP framework built on top of the technologies mentioned above which handles routing, request extraction, response building, and workers lifecycle. Axum is a relatively thin layer on top of Hyper and adds very little overhead, so its performance is comparable to Hyper. The framework should allow customers to use the built-in HTTP server or select other transport implementations that can be more performant or better suited than HTTP for their use case.","breadcrumbs":"RFCs » RFC-0005: Smithy Rust service framework » Performance","id":"135","title":"Performance"},"136":{"body":"We want to deliver an extensible framework that can plugin components possibly during code generation and at runtime for specific scenarios that cannot be covered during generation. These components are developed using a standard interface provided by the framework itself.","breadcrumbs":"RFCs » RFC-0005: Smithy Rust service framework » Extensibility","id":"136","title":"Extensibility"},"137":{"body":"Being able to report and trace the status of the service is vital for the success of any product. The framework is integrated with tracing and allows non-blocking I/O through the asynchronous tracing appender . Metrics and logging are built with extensibility in mind, allowing customers to plug their own handlers following a well defined interface provided by the framework.","breadcrumbs":"RFCs » RFC-0005: Smithy Rust service framework » Observability","id":"137","title":"Observability"},"138":{"body":"Client generation is deferred to the various Smithy implementations.","breadcrumbs":"RFCs » RFC-0005: Smithy Rust service framework » Client generation","id":"138","title":"Client generation"},"139":{"body":"Benchmarking the framework is key and customers can't use anything that compromises the fundamental business objectives of latency and performance.","breadcrumbs":"RFCs » RFC-0005: Smithy Rust service framework » Benchmarking","id":"139","title":"Benchmarking"},"14":{"body":"The main question to ask yourself in this case is \"is this new behavior relevant to all services or is it only relevant to some services?\" If the behavior is relevant to all services: Behavior like this should be defined as a middleware. Behavior like this is often AWS-specific and may not be relevant to non-AWS smithy clients. Middlewares are defined outside of codegen. One example of behavior that should be defined as a middleware is request signing because all requests to AWS services must be signed. If the behavior is only relevant to some services/depends on service model specifics: Behavior like this should be defined within make_operation. Avoid defining AWS-specific behavior within make_operation. One example of behavior that should be defined in make_operation is checksum validation because only some AWS services have APIs that support checksum validation. \"Wait a second\" I hear you say, \"checksum validation is part of the AWS smithy spec, not the core smithy spec. Why is that behavior defined in make_operation?\" The answer is that that feature only applies to some operations and we don't want to codegen a middleware that only supports a subset of operations for a service.","breadcrumbs":"Design FAQ » I want to add new request building behavior. Should I add that functionality to the make_operation codegen or write a request-altering middleware?","id":"14","title":"I want to add new request building behavior. Should I add that functionality to the make_operation codegen or write a request-altering middleware?"},"140":{"body":"The generated service code is responsible for validating the model constraints of input structures.","breadcrumbs":"RFCs » RFC-0005: Smithy Rust service framework » Model validation","id":"140","title":"Model validation"},"141":{"body":"Status: Implemented For a summarized list of proposed changes, see the Changes Checklist section. Currently, all services use a centralized AwsMiddleware that is defined in the (poorly named) aws-hyper crate. This poses a number of long term risks and limitations: When creating a Smithy Client directly for a given service, customers are forced to implicitly assume that the service uses stock AwsMiddleware. This prevents us from ever changing the middleware stack for a service in the future. It is impossible / impractical in the current situation to alter the middleware stack for a given service. For services like S3, we will almost certainly want to customize endpoint middleware in a way that is currently impossible. In light of these limitations, this RFC proposes moving middleware into each generated service. aws-inlineable will be used to host and test the middleware stack. Each service will then define a public middleware module containing their middleware stack.","breadcrumbs":"RFCs » RFC-0006: Service-specific middleware » RFC: Service-specific middleware","id":"141","title":"RFC: Service-specific middleware"},"142":{"body":"Middleware : A tower layer that augments operation::Request -> operation::Response for things like signing and endpoint resolution. Aws Middleware : A specific middleware stack that meets the requirements for AWS services. Smithy Client : A aws_smithy_client::Client struct that is responsible for gluing together the connector, middleware, and retry policy. This is not generated and lives in the aws-smithy-client crate. Fluent Client : A code-generated Client that has methods for each service operation on it. A fluent builder is generated alongside it to make construction easier. AWS Client : A specialized Fluent Client that defaults to using a DynConnector, AwsMiddleware, and Standard retry policy. Shared Config : An aws_types::Config struct that is responsible for storing shared configuration data that is used across all services. This is not generated and lives in the aws-types crate. Service-specific Config : A code-generated Config that has methods for setting service-specific configuration. Each Config is defined in the config module of its parent service. For example, the S3-specific config struct is useable from aws_sdk_s3::config::Config and re-exported as aws_sdk_s3::Config.","breadcrumbs":"RFCs » RFC-0006: Service-specific middleware » Terminology","id":"142","title":"Terminology"},"143":{"body":"Currently, AwsMiddleware is defined in aws-hyper. As part of this change, an aws-inlineable dependency will be added containing code that is largely identical. This will be exposed in a public middleware module in all generated services. At some future point, we could even expose a baseline set of default middleware for whitelabel Smithy services to make them easier to use out-of-the-box. The ClientGenerics parameter of the AwsFluentClientGenerator will be updated to become a RuntimeType, enabling loading the type directly. This has the advantage of making it fairly easy to do per-service middleware stacks since we can easily configure AwsFluentClientGenerator to insert different types based on the service id.","breadcrumbs":"RFCs » RFC-0006: Service-specific middleware » Detailed Design","id":"143","title":"Detailed Design"},"144":{"body":"Move aws-hyper into aws-inlineable. Update comments as needed including with a usage example about how customers can augment it. Refactor ClientGenerics to contain a RuntimeType instead of a string and configure. Update AwsFluentClientDecorator. Update all code and examples that use aws-hyper to use service-specific middleware. Push an updated README to aws-hyper deprecating the package, explaining what happened. Do not yank previous versions since those will be relied on by older SDK versions.","breadcrumbs":"RFCs » RFC-0006: Service-specific middleware » Changes Checklist","id":"144","title":"Changes Checklist"},"145":{"body":"Status: Implemented in smithy-rs#986 and aws-sdk-rust#351 At the time of writing, the aws-sdk-rust repository is used exclusively for the entire release process of both the Rust runtime crates from smithy-rs as well as the AWS runtime crates and the AWS SDK. This worked well when smithy-rs was only used for the AWS SDK, but now that it's also used for server codegen, there are issues around publishing the server-specific runtime crates since they don't belong to the SDK. This RFC proposes a new split-release process so that the entire smithy-rs runtime can be published separately before the AWS SDK is published.","breadcrumbs":"RFCs » RFC-0007: Split release process » RFC: Split Release Process","id":"145","title":"RFC: Split Release Process"},"146":{"body":"Smithy Runtime Crate : A crate that gets published to crates.io and supports the code generated by smithy-rs. These crates don't provide any SDK-only functionality. These crates can support client and/or server code, and clients or servers may use only a subset of them. AWS Runtime Crate : A crate of SDK-specific code that supports the code generated by the aws/codegen module in smithy-rs. These also get published to crates.io. Publish-ready Bundle : A build artifact that is ready to publish to crates.io without additional steps (such as running the publisher tool's fix-manifests subcommand). Publishing one group of crates before another is not considered an additional step for this definition. Releaser : A developer, automated process, or combination of the two that performs the actual release.","breadcrumbs":"RFCs » RFC-0007: Split release process » Terminology","id":"146","title":"Terminology"},"147":{"body":"At a high level, the requirements are: publish from both smithy-rs and aws-sdk-rust while preserving our current level of confidence in the quality of the release. This can be enumerated as: All Smithy runtime crates must be published together from smithy-rs AWS runtime crates and the SDK must be published together from aws-sdk-rust CI on smithy-rs must give confidence that the Smithy runtime crates, AWS runtime crates, and SDK are all at the right quality bar for publish. CI on the aws-sdk-rust repository must give confidence that the AWS SDK and its runtime crates are at the right quality bar for publish. To do this successfully, it must run against the exact versions of the Smithy runtime crates the code was generated against both before AND after they have been published to crates.io .","breadcrumbs":"RFCs » RFC-0007: Split release process » Requirements","id":"147","title":"Requirements"},"148":{"body":"The publish process to crates.io relied on copying all the Smithy runtime crates into the final aws-sdk-rust repository. Overall, the process looked as follows: smithy-rs generates a complete aws-sdk-rust source bundle at CI time The releaser copies the generated bundle over to aws-sdk-rust The releaser runs the publisher fix-manifests subcommand to correct the Cargo.toml files generated by smithy-rs The aws-sdk-rust CI performs one last pass on the code to verify it's sound The releaser runs the publisher publish subcommand to push all the crates up to crates.io","breadcrumbs":"RFCs » RFC-0007: Split release process » Background: How Publishing Worked Before","id":"148","title":"Background: How Publishing Worked Before"},"149":{"body":"CI in smithy-rs will be revised to generate two separate build artifacts where it generates just an SDK artifact previously. Now, it will have two build targets that get executed from CI to generate these artifacts: rust-runtime:assemble - Generates a publish-ready bundle of Smithy runtime crates. aws:sdk:assemble - Generates a publish-ready bundle of AWS runtime crates, SDK crates, and just the Smithy runtime crates that are used by the SDK. The aws-sdk-rust repository will have a new next branch that has its own set of CI workflows and branch protection rules. The releaser will take the aws:sdk:assemble artifact and apply it directly to this next branch as would have previously been done against the main branch. The main branch will continue to have the same CI as next. When it's time to cut a release, the releaser will do the following: Tag smithy-rs with the desired version number Wait for CI to build artifacts for the tagged release Pull-request the SDK artifacts over to aws-sdk-rust/next (this will be automated in the future) Pull-request merge aws-sdk-rust/next into aws-sdk-rust/main Wait for successful CI in main Tag release for main Publish SDK with publisher tool The server team can then download the rust-runtime:assemble build artifact for the tagged release in smithy-rs, and publish the aws-smithy-http-server crate from there.","breadcrumbs":"RFCs » RFC-0007: Split release process » Proposed Solution","id":"149","title":"Proposed Solution"},"15":{"body":"The transport layer of smithy-rs and the Rust SDK. Our goal is support customers to bring their own HTTP stack and runtime.","breadcrumbs":"Transport » Transport","id":"15","title":"Transport"},"150":{"body":"It should be difficult to accidentally publish a locally built set of crates. To add friction to this, the smithy-rs build process will look for the existence of the GITHUB_ACTIONS=true environment variable. If this environment variable is not set, then it will pass a flag to the Rust codegen plugin that tells it to emit a publish = false under [package] in the generated Cargo.toml. This could be easily circumvented, but the goal is to reduce the chances of accidentally publishing crates rather than making it impossible.","breadcrumbs":"RFCs » RFC-0007: Split release process » Avoiding mistakes by disallowing creation of publish-ready bundles outside of CI","id":"150","title":"Avoiding mistakes by disallowing creation of publish-ready bundles outside of CI"},"151":{"body":"","breadcrumbs":"RFCs » RFC-0007: Split release process » Alternatives Considered","id":"151","title":"Alternatives Considered"},"152":{"body":"This approach is similar to the proposed solution, except that the SDK would not publish the Smithy runtime crates. The aws-sdk-rust/main branch would have a small tweak to its CI so that the SDK is tested against the Smithy runtime crates that are published to crates.io This CI process would look as follows: Shallow clone aws-sdk-rust with the revision being tested Run a script to remove the path argument for the Smithy runtime crate dependencies for every crate in aws-sdk-rust. For example, aws-smithy-types = { version = \"0.33.0\", path = \"../aws-smithy-types\" } Would become: aws-smithy-types = { version = \"0.33.0\" } Run the tests as usual When it's time to cut a release, the releaser will do the following: Tag smithy-rs with the desired version number Wait for CI to build artifacts for the tagged release Pull-request the SDK artifacts over to aws-sdk-rust/next Wait for successful CI in aws-sdk-rust/next Download the Smithy runtime crates build artifact and publish it to crates.io Pull-request merge aws-sdk-rust/next into aws-sdk-rust/main Wait for successful CI in main (this time actually running against the crates.io Smithy runtime crates) Tag release for main Publish SDK with publisher tool","breadcrumbs":"RFCs » RFC-0007: Split release process » Publish Smithy runtime crates from smithy-rs build artifacts","id":"152","title":"Publish Smithy runtime crates from smithy-rs build artifacts"},"153":{"body":"This approach is similar to the previous alternative, except that the aws-sdk-rust repository won't have a snapshot of the Smithy runtime crates, and an additional step needs to be performed during CI for the next branch so that it looks as follows: Make a shallow clone of aws-sdk-rust/next Retrieve the smithy-rs commit hash that was used to generate the SDK from a file that was generated alongside the rest of the build artifacts from smithy-rs and copied into aws-sdk-rust. Make a shallow clone of smithy-rs at the correct commit hash Use a script to add a [patch] section to all the AWS SDK crates to point to the Smithy runtime crates from the local clone of smithy-rs. For example: # The dependencies section is left alone, but is here for context\n[dependencies]\n# Some version of aws-smithy-types that isn't on crates.io yet, referred to as `` below\naws-smithy-types = \"\" # This patch section gets added by the script\n[patch.crates-io]\naws-smithy-types = { version = \"\", path = \"path/to/local/smithy-rs/rust-runtime/aws-smithy-types\"} Run CI as normal. Note: smithy-rs would need to do the same patching in CI as aws-sdk-rust/next since the generated SDK would not have path dependencies for the Smithy runtime crates (since they are a publish-ready bundle intended for landing in aws-sdk-rust). The script that does this patching could live in smithy-rs and be reused by aws-sdk-rust. The disadvantage of this approach is that a customer having an issue with the current release wouldn't be able to get a fix sooner by patching their own project's crate manifest to use the aws-sdk-rust/next branch before a release is cut since their project wouldn't be able to find the unreleased Smithy runtime crates.","breadcrumbs":"RFCs » RFC-0007: Split release process » Keep Smithy runtime crates in smithy-rs","id":"153","title":"Keep Smithy runtime crates in smithy-rs"},"154":{"body":"In smithy-rs: Move publisher tool from aws-sdk-rust into smithy-rs Modify aws:sdk:assemble target to run the publisher fix-manifests subcommand Add rust-runtime:assemble target that generates publish-ready Smithy runtime crates Add CI step to create Smithy runtime bundle artifact Add GITHUB_ACTIONS=true env var check for setting the publish flag in generated AND runtime manifests Revise publisher tool to publish from an arbitrary directory In aws-sdk-rust: Implement CI for the aws-sdk-rust/next branch Remove the publisher tool Update release process documentation","breadcrumbs":"RFCs » RFC-0007: Split release process » Changes Checklist","id":"154","title":"Changes Checklist"},"155":{"body":"Status: Implemented Smithy models paginated responses . Customers of Smithy generated code & the Rust SDK will have an improved user experience if code is generated to support this. Fundamentally, paginators are a way to automatically make a series of requests with the SDK, where subsequent requests automatically forward output from the previous responses. There is nothing a paginator does that a user could not do manually, they merely simplify the common task of interacting with paginated APIs. **Specifically, a paginator will resend the orginal request but with inputToken updated to the value of the previous outputToken. In this RFC, we propose modeling paginated data as a Stream of output shapes. When an output is paginated, a paginate() method will be added to the high level builder An Paginator struct will be generated into the paginator module. If items is modeled, paginate().items() will be added to produce the paginated items. PaginatorItems will be generated into the paginator module. The Stream trait enables customers to use a number of abstractions including simple looping, and collect()ing all data in a single call. A paginator will resend the original input, but with the field marked inputToken to the value of outputToken in the previous output. Usage example: let paginator = client .list_tables() .paginate() .items() .page_size(10) .send() .await;\nlet tables: Result, _ > = paginator.collect().await; Paginators are lazy and only retrieve pages when polled by a client.","breadcrumbs":"RFCs » RFC-0008: Paginators » Summary","id":"155","title":"Summary"},"156":{"body":"Paginators will be generated into the paginator module of service crates. Currently, paginators are not feature gated, but this could be considered in the future. A paginator struct captures 2 pieces of data: // dynamodb/src/paginator.rs\nstruct ListTablesPaginator { // holds the low-level client and configuration handle: Arc>, // input builder to construct the actual input on demand input: ListTablesInputBuilder\n} In addition to the basic usage example above, when pageSize is modeled, customers can specify the page size during pagination: let mut tables = vec![];\nlet mut pages = client .list_tables() .paginate() .page_size(20) .send();\nwhile let Some(next_page) = pages.try_next().await? { // pages of 20 items requested from DynamoDb tables.extend(next_page.table_names.unwrap_or_default().into_iter());\n} Paginators define a public method send(). This method returns impl Stream. This uses FnStream defined in the aws-smithy-async crate which enables demand driven execution of a closure. A rendezvous channel is used which will block on send until demand exists. When modeled by Smithy, page_size which automatically sets the appropriate page_size parameter and items() which returns an automatically flattened paginator are also generated. Note : page_size directly sets the modeled parameter on the internal builder. This means that a value set for page size will override any previously set value for that field. // Generated paginator for ListTables\nimpl ListTablesPaginator\n{ /// Set the page size pub fn page_size(mut self, limit: i32) -> Self { self.builder.limit = Some(limit); self } /// Create a flattened paginator /// /// This paginator automatically flattens results using `table_names`. Queries to the underlying service /// are dispatched lazily. pub fn items(self) -> crate::paginator::ListTablesPaginatorItems { crate::paginator::ListTablesPaginatorItems(self) } /// Create the pagination stream /// /// _Note:_ No requests will be dispatched until the stream is used (eg. with [`.next().await`](tokio_stream::StreamExt::next)). pub async fn send( self, ) -> impl tokio_stream::Stream< Item = std::result::Result< crate::output::ListTablesOutput, aws_smithy_http::result::SdkError, >, > + Unpin { // Move individual fields out of self for the borrow checker let builder = self.builder; let handle = self.handle; fn_stream::FnStream::new(move |tx| { Box::pin(async move { // Build the input for the first time. If required fields are missing, this is where we'll produce an early error. let mut input = match builder.build().map_err(|err| { SdkError::ConstructionFailure(err.into()) }) { Ok(input) => input, Err(e) => { let _ = tx.send(Err(e)).await; return; } }; loop { let op = match input.make_operation(&handle.conf).await.map_err(|err| { SdkError::ConstructionFailure(err.into()) }) { Ok(op) => op, Err(e) => { let _ = tx.send(Err(e)).await; return; } }; let resp = handle.client.call(op).await; // If the input member is None or it was an error let done = match resp { Ok(ref resp) => { input.exclusive_start_table_name = crate::lens::reflens_structure_crate_output_list_tables_output_last_evaluated_table_name(resp).cloned(); input.exclusive_start_table_name.is_none() } Err(_) => true, }; if let Err(_) = tx.send(resp).await { // receiving end was dropped return; } if done { return; } } }) }) }\n} On Box::pin : The stream returned by AsyncStream does not implement Unpin. Unfortunately, this makes iteration require an invocation of pin_mut! and generates several hundred lines of compiler errors. Box::pin seems a worthwhile trade off to improve the user experience. On the + Unpin bound : Because auto-traits leak across impl Trait boundaries, + Unpin prevents accidental regressions in the generated code which would break users. On the crate::reflens::... : We use LensGenerator.kt to generate potentially complex accessors to deeply nested fields.","breadcrumbs":"RFCs » RFC-0008: Paginators » Details","id":"156","title":"Details"},"157":{"body":"The builders generated by ergonomic clients will gain the following method, if they represent an operation that implements the Paginated trait: /// Create a paginator for this request\n///\n/// Paginators are used by calling [`send().await`](crate::paginator::ListTablesPaginator::send) which returns a [`Stream`](tokio_stream::Stream).\npub fn paginate(self) -> crate::paginator::ListTablesPaginator { crate::paginator::ListTablesPaginator::new(self.handle, self.inner)\n}","breadcrumbs":"RFCs » RFC-0008: Paginators » Updates to ergonomic clients","id":"157","title":"Updates to ergonomic clients"},"158":{"body":"","breadcrumbs":"RFCs » RFC-0008: Paginators » Discussion Areas","id":"158","title":"Discussion Areas"},"159":{"body":"Calling send().await is not necessary from an API perspective—we could have the paginators impl-stream directly. However, it enables using impl Trait syntax and also makes the API consistent with other SDK APIs.","breadcrumbs":"RFCs » RFC-0008: Paginators » On send().await","id":"159","title":"On send().await"},"16":{"body":"aws-hyper assembles a middleware stack with tower. It provides a way to use an HTTP client other than Hyper, however, it currently has a hard dependency on Hyper & Tokio. hyper::Body is being used directly as the body implementation for responses.","breadcrumbs":"Transport » Where we are today","id":"16","title":"Where we are today"},"160":{"body":"Currently, the core trait we use is tokio_stream::Stream. This is a re-export from futures-util. There are a few other choices: Re-export Stream from tokio_stream. Use futures_util directly","breadcrumbs":"RFCs » RFC-0008: Paginators » On tokio_stream::Stream","id":"160","title":"On tokio_stream::Stream"},"161":{"body":"Currently, the paginators forward the generics from the client (C, M, R) along with their fairly annoying bounds. However, if we wanted to we could simplify this and erase all the generics when the paginator was created. Since everything is code generated, there isn't actually much duplicated code in the generator, just in the generated code.","breadcrumbs":"RFCs » RFC-0008: Paginators » On Generics","id":"161","title":"On Generics"},"162":{"body":"Create and test FnStream abstraction Generate page-level paginators Generate .items() paginators Generate doc hints pointing people to paginators Integration test using mocked HTTP traffic against a generated paginator for a real service Integration test using real traffic","breadcrumbs":"RFCs » RFC-0008: Paginators » Changes Checklist","id":"162","title":"Changes Checklist"},"163":{"body":"Status: Implemented Currently, the AWS Rust SDK's examples are duplicated across awslabs/aws-sdk-rust , smithy-lang/smithy-rs , and awsdocs/aws-doc-sdk-examples . The smithy-rs repository was formerly the source of truth for examples, with the examples being copied over to aws-sdk-rust as part of the release process, and examples were manually copied over to aws-doc-sdk-examples so that they could be included in the developer guide. Now that the SDK is more stable with less frequent breaking changes, the aws-doc-sdk-examples repository can become the source of truth so long as the examples are tested against smithy-rs and continue to be copied into aws-sdk-rust.","breadcrumbs":"RFCs » RFC-0009: Example Consolidation » RFC: Examples Consolidation","id":"163","title":"RFC: Examples Consolidation"},"164":{"body":"Examples are authored and maintained in aws-doc-sdk-examples Examples are no longer present in smithy-rs CI in smithy-rs checks out examples from aws-doc-sdk-examples and builds them against the generated SDK. Success for this CI job is optional for merging since there can be a time lag between identifying that examples are broken and fixing them. Examples must be copied into aws-sdk-rust so that the examples for a specific version of the SDK can be easily referenced. Examples must be verified in aws-sdk-rust prior to merging into the main branch.","breadcrumbs":"RFCs » RFC-0009: Example Consolidation » Requirements","id":"164","title":"Requirements"},"165":{"body":"A CI job will be added to smithy-rs that: Depends on the CI job that generates the full AWS SDK Checks out the aws-doc-sdk-examples repository Modifies example Cargo.toml files to point to the newly generated AWS SDK crates Runs cargo check on each example This job will not be required to pass for branch protection, but will let us know that examples need to be updated before the next release.","breadcrumbs":"RFCs » RFC-0009: Example Consolidation » Example CI in smithy-rs","id":"165","title":"Example CI in smithy-rs"},"166":{"body":"The auto-sync job that copies generated code from smithy-rs into the aws-sdk-rust/next branch will be updated to check out the aws-doc-sdk-examples repository and copy the examples into aws-sdk-rust. The example Cargo.toml files will also be updated to point to the local crate paths as part of this process. The aws-sdk-rust CI already requires examples to compile, so merging next into main, the step required to perform a release, will be blocked until the examples are fixed. In the event the examples don't work on the next branch, developers and example writers will need to be able to point the examples in aws-doc-sdk-examples to the generated SDK in next so that they can verify their fixes. This can be done by hand, or a tool can be written to automate it if a significant number of examples need to be fixed.","breadcrumbs":"RFCs » RFC-0009: Example Consolidation » Auto-sync to aws-sdk-rust from smithy-rs changes","id":"166","title":"Auto-sync to aws-sdk-rust from smithy-rs changes"},"167":{"body":"There are a couple of risks with this approach: Risk: Examples are broken and an urgent fix needs to be released. Possible mitigations: Revert the change that broke the examples and then add the urgent fix Create a patch branch in aws-sdk-rust, apply the fix to that based off an older version of smithy-rs with the fix applied, and merge that into main. Risk: A larger project requires changes to examples prior to GA, but multiple releases need to occur before the project completion. Possible mitigations: If the required changes compile against the older SDK, then just make the changes to the examples. Feature gate any incremental new functionality in smithy-rs, and work on example changes on a branch in aws-doc-sdk-examples. When wrapping up the project, remove the feature gating and merge the examples into the main branch.","breadcrumbs":"RFCs » RFC-0009: Example Consolidation » Process Risks","id":"167","title":"Process Risks"},"168":{"body":"","breadcrumbs":"RFCs » RFC-0009: Example Consolidation » Alternatives","id":"168","title":"Alternatives"},"169":{"body":"Alternatively, the examples could reside in aws-sdk-rust, be referenced from smithy-rs CI, and get copied into aws-doc-sdk-examples for inclusion in the user guide. Pros: Prior to GA, fixing examples after making breaking changes to the SDK would be easier. Otherwise, Cargo.toml files have to be temporarily modified to point to the aws-sdk-rust/next branch in order to make fixes. If a customer discovers examples via the aws-sdk-rust repository rather than via the SDK user guide, then it would be more obvious how to make changes to examples. At time of writing, the examples in the user guide link to the aws-doc-sdk-examples repository, so if the examples are discovered that way, then updating them should already be clear. Cons: Tooling would need to be built to sync examples from aws-sdk-rust into aws-doc-sdk-examples so that they could be incorporated into the user guide. Creates a circular dependency between the aws-sdk-rust and smithy-rs repositories. CI in smithy-rs needs to exercise examples, which would be in aws-sdk-rust, and aws-sdk-rust has its code generated by smithy-rs. This is workable, but may lead to problems later on. The tooling to auto-sync from aws-sdk-rust into aws-doc-sdk-examples will likely cost more than tooling to temporarily update Cargo.toml files to make example fixes (if that tooling is even necessary).","breadcrumbs":"RFCs » RFC-0009: Example Consolidation » aws-sdk-rust as the source of truth","id":"169","title":"aws-sdk-rust as the source of truth"},"17":{"body":"Extend HttpService to add a sleep method. This is required to enable runtimes other than Tokio to define how they should sleep. Replace hyper::Body in responses with SDK Body. For now, SDKBody will probably privately wrap hyper::Body. Merge aws-hyper into aws-http. Tokio becomes an optional feature—When the Tokio feature is opted out the \"fast path\" variants for the connection variants are cfg'd out. By default, customers get a fully baked HTTP stack, but they can opt out of certain features and BYO implementation of HttpService.","breadcrumbs":"Transport » Where we want to go","id":"17","title":"Where we want to go"},"170":{"body":"Add example CI job to smithy-rs Diff examples in smithy-rs and aws-doc-sdk-examples and move desired differences into aws-doc-sdk-examples Apply example fix PRs from aws-sdk-rust into aws-doc-sdk-examples Update smithy-rs CI to copy examples from aws-doc-sdk-examples rather than from smithy-rs Delete examples from smithy-rs","breadcrumbs":"RFCs » RFC-0009: Example Consolidation » Changes Checklist","id":"170","title":"Changes Checklist"},"171":{"body":"Status: Accepted Waiters are a convenient polling mechanism to wait for a resource to become available or to be deleted. For example, a waiter could be used to wait for a S3 bucket to be created after a call to the CreateBucket API, and this would only require a small amount of code rather than building out an entire polling mechanism manually. At the highest level, a waiter is a simple polling loop (pseudo-Rust): // Track state that contains the number of attempts made and the previous delay\nlet mut state = initial_state(); loop { // Poll the service let result = poll_service().await; // Classify the action that needs to be taken based on the Smithy model match classify(result) { // If max attempts hasn't been exceeded, then retry after a delay. Otherwise, error. Retry => if state.should_retry() { let delay = state.next_retry(); sleep(delay).await; } else { return error_max_attempts(); } // Otherwise, if the termination condition was met, return the output Terminate(result) => return result, }\n} In the AWS SDK for Rust, waiters can be added without making any backwards breaking changes to the current API. This doc outlines the approach to add them in this fashion, but does NOT examine code generating response classification from JMESPath expressions, which can be left to the implementer without concern for the overall API.","breadcrumbs":"RFCs » RFC-0010: Waiters » RFC: Waiters","id":"171","title":"RFC: Waiters"},"172":{"body":"Today, there are three layers of Client that are easy to confuse, so to make the following easier to follow, the following terms will be used: Connector : An implementor of Tower's Service trait that converts a request into a response. This is typically a thin wrapper around a Hyper client. Smithy Client : A aws_smithy_client::Client struct that is responsible for gluing together the connector, middleware, and retry policy. This isn't intended to be used directly. Fluent Client : A code generated Client that has methods for each service operation on it. A fluent builder is generated alongside it to make construction easier. AWS Client : A specialized Fluent Client that uses a DynConnector, DefaultMiddleware, and Standard retry policy. All of these are just called Client in code today. This is something that could be clarified in a separate refactor.","breadcrumbs":"RFCs » RFC-0010: Waiters » Terminology","id":"172","title":"Terminology"},"173":{"body":"Waiters must adhere to the Smithy waiter specification . To summarize: Waiters are specified by the Smithy @waitable trait Retry during polling must be exponential backoff with jitter, with the min/max delay times and max attempts configured by the @waitable trait The SDK's built-in retry needs to be replaced by the waiter's retry since the Smithy model can specify retry conditions that are contrary to the defaults. For example, an error that would otherwise be retried by default might be the termination condition for the waiter. Classification of the response must be code generated based on the JMESPath expression in the model.","breadcrumbs":"RFCs » RFC-0010: Waiters » Requirements","id":"173","title":"Requirements"},"174":{"body":"To invoke a waiter, customers will only need to invoke a single function on the AWS Client. For example, if waiting for a S3 bucket to exist, it would look like the following: // Request bucket creation\nclient.create_bucket() .bucket_name(\"my-bucket\") .send() .await()?; // Wait for it to be created\nclient.wait_until_bucket_exists() .bucket_name(\"my-bucket\") .send() .await?; The call to wait_until_bucket_exists() will return a waiter-specific fluent builder with a send() function that will start the polling and return a future. To avoid name conflicts with other API methods, the waiter functions can be added to the client via trait: pub trait WaitUntilBucketExists { fn wait_until_bucket_exists(&self) -> crate::waiter::bucket_exists::Builder;\n} This trait would be implemented for the service's fluent client (which will necessitate making the fluent client's handle field pub(crate)).","breadcrumbs":"RFCs » RFC-0010: Waiters » Waiter API","id":"174","title":"Waiter API"},"175":{"body":"A waiter trait implementation will merely return a fluent builder: impl WaitUntilBucketExists for Client { fn wait_until_bucket_exists(&self) -> crate::waiter::bucket_exists::Builder { crate::waiter::bucket_exists::Builder::new() }\n} This builder will have a short send() function to kick off the actual waiter implementation: impl Builder { // ... existing fluent builder codegen can be reused to create all the setters and constructor pub async fn send(self) -> Result> { // Builds an input from this builder let input = self.inner.build().map_err(|err| aws_smithy_http::result::SdkError::ConstructionFailure(err.into()))?; // Passes in the client's handle, which contains a Smithy client and client config crate::waiter::bucket_exists::wait(self.handle, input).await }\n} This wait function needs to, in a loop similar to the pseudo-code in the beginning, convert the given input into an operation, replace the default response classifier on it with a no-retry classifier, and then determine what to do next based on that classification: pub async fn wait( handle: Arc, retry::Standard>>, input: HeadBucketInput,\n) -> Result> { loop { let operation = input .make_operation(&handle.conf) .await .map_err(|err| { aws_smithy_http::result::SdkError::ConstructionFailure(err.into()) })?; // Assume `ClassifyRetry` trait is implemented for `NeverRetry` to always return `RetryKind::Unnecessary` let operation = operation.with_retry_classifier(NeverRetry::new()); let result = handle.client.call(operation).await; match classify_result(&input, result) { AcceptorState::Retry => { // The sleep implementation is available here from `handle.conf.sleep_impl` unimplemented!(\"Check if another attempt should be made and calculate delay time if so\") } AcceptorState::Terminate(output) => return output, } }\n} fn classify_result( input: &HeadBucketInput, result: Result>,\n) -> AcceptorState> { unimplemented!( \"The Smithy model would dictate conditions to check here to produce an `AcceptorState`\" )\n} The retry delay time should be calculated by the same exponential backoff with jitter code that the default RetryHandler uses in aws-smithy-client . This function will need to be split up and made available to the waiter implementations so that just the delay can be calculated.","breadcrumbs":"RFCs » RFC-0010: Waiters » Waiter Implementation","id":"175","title":"Waiter Implementation"},"176":{"body":"Codegen fluent builders for waiter input and their send() functions Codegen waiter invocation traits Commonize exponential backoff with jitter delay calculation Codegen wait() functions with delay and max attempts configuration from Smithy model Codegen classify_result() functions based on JMESPath expressions in Smithy model","breadcrumbs":"RFCs » RFC-0010: Waiters » Changes Checklist","id":"176","title":"Changes Checklist"},"177":{"body":"Status: Implemented The AWS SDK for Rust and its supporting Smithy crates need to be published to crates.io so that customers can include them in their projects and also publish crates of their own that depend on them. This doc proposes a short-term solution for publishing to crates.io. This approach is intended to be executed manually by a developer using scripts and an SOP no more than once per week, and should require less than a dev week to implement.","breadcrumbs":"RFCs » RFC-0011: Publishing Alpha to Crates.io » RFC: Publishing the Alpha SDK to Crates.io","id":"177","title":"RFC: Publishing the Alpha SDK to Crates.io"},"178":{"body":"AWS SDK Crate : A crate that provides a client for calling a given AWS service, such as aws-sdk-s3 for calling S3. AWS Runtime Crate : Any runtime crate that the AWS SDK generated code relies on, such as aws-types. Smithy Runtime Crate : Any runtime crate that the smithy-rs generated code relies on, such as smithy-types.","breadcrumbs":"RFCs » RFC-0011: Publishing Alpha to Crates.io » Terminology","id":"178","title":"Terminology"},"179":{"body":"","breadcrumbs":"RFCs » RFC-0011: Publishing Alpha to Crates.io » Requirements","id":"179","title":"Requirements"},"18":{"body":"The Smithy code generator for Rust (and by extension), the AWS SDK use an Operation abstraction to provide a unified interface for dispatching requests. Operations contain: A base HTTP request (with a potentially streaming body) A typed property bag of configuration options A fully generic response handler In the typical case, these configuration options include things like a CredentialsProvider, however, they can also be full middleware layers that will get added by the dispatch stack.","breadcrumbs":"Transport » HTTP Operations » HTTP-based Operations","id":"18","title":"HTTP-based Operations"},"180":{"body":"Cargo uses semver for versioning, with a major.minor.patch-pre format: major: Incompatible API changes minor: Added functionality in backwards compatible manner patch: Backwards compatible bug fixes pre: Pre-release version tag (omitted for normal releases) For now, AWS SDK crates (including aws-config) will maintain a consistent major and minor version number across all services. The latest version of aws-sdk-s3 will always have the same major.minor version as the latest aws-sdk-dynamodb, for example. The patch version is allowed to be different between service crates, but it is unlikely that we will make use of patch versions throughout alpha and dev preview. Smithy runtime crates will have different version numbers from the AWS SDK crates, but will also maintain a consistent major.minor. The pre version tag will be alpha during the Rust SDK alpha, and will be removed once the SDK is in dev preview. During alpha, the major version will always be 0, and the minor will be bumped for all published crates for every release. A later RFC may change the process during dev preview.","breadcrumbs":"RFCs » RFC-0011: Publishing Alpha to Crates.io » Versioning","id":"180","title":"Versioning"},"181":{"body":"Mistakes will inevitably be made, and a mechanism is needed to yank packages while keeping the latest version of the SDK successfully consumable from crates.io. To keep this simple, the entire published batch of crates will be yanked if any crate in that batch needs to be yanked. For example, if 260 crates were published in a batch, and it turns out there's a problem that requires yanking one of them, then all 260 will be yanked. Attempting to do partial yanking will require a lot of effort and be difficult to get right. Yanking should be a last resort.","breadcrumbs":"RFCs » RFC-0011: Publishing Alpha to Crates.io » Yanking","id":"181","title":"Yanking"},"182":{"body":"The following changes will be bundled together as a minor version bump during weekly releases: AWS model updates New features Bug fixes in runtime crates or codegen In exceptional circumstances, a patch version will be issued if the fix doesn't require API breaking changes: CVE discovered in a runtime crate Buggy update to a runtime crate In the event of a CVE being discovered in an external dependency, if the external dependency is internal to a crate, then a patch revision can be issued for that crate to correct it. Otherwise if the CVE is in a dependency that is part of the public API, a minor revision will be issued with an expedited release. For a CVE in generated code, a minor revision will be issued with an expedited release.","breadcrumbs":"RFCs » RFC-0011: Publishing Alpha to Crates.io » Concrete Scenarios","id":"182","title":"Concrete Scenarios"},"183":{"body":"The short-term approach builds off our pre-crates.io weekly release process. That process was the following: Run script to update AWS models Manually update AWS SDK version in aws/sdk/gradle.properties in smithy-rs Tag smithy-rs Wait for GitHub actions to generate AWS SDK using newly released smithy-rs Check out aws-sdk-rust, delete existing SDK code, unzip generated SDK in place, and update readme Tag aws-sdk-rust To keep things simple: The Smithy runtime crates will have the same smithy-rs version All AWS crates will have the same AWS SDK version patch revisions are exceptional and will be one-off manually published by a developer All runtime crate version numbers in smithy-rs will be locked at 0.0.0-smithy-rs-head. This is a fake version number that gets replaced when generating the SDK. The SDK generator script in smithy-rs will be updated to: Replace Smithy runtime crate versions with the smithy-rs version from aws/sdk/gradle.properties Replace AWS runtime crate versions with AWS SDK version from aws/sdk/gradle.properties Add correct version numbers to all path dependencies in all the final crates that end up in the build artifacts This will result in all the crates having the correct version and manifests when imported into aws-sdk-rust. From there, a script needs to be written to determine crate dependency order, and publish crates (preferably with throttling and retry) in the correct order. This script needs to be able to recover from an interruption part way through publishing all the crates, and it also needs to output a list of all crate versions published together. This crate list will be commented on the release issue so that yanking the batch can be done if necessary. The new release process would be: Run script to update AWS models Manually update both the AWS SDK version and the smithy-rs version in aws/sdk/gradle.properties in smithy-rs Tag smithy-rs Wait for automation to sync changes to aws-sdk-rust/next Cut a PR to merge aws-sdk-rust/next into aws-sdk-rust/main Tag aws-sdk-rust Run publish script","breadcrumbs":"RFCs » RFC-0011: Publishing Alpha to Crates.io » Proposal","id":"183","title":"Proposal"},"184":{"body":"Prepare runtime crate manifests for publication to crates.io (https://github.com/smithy-lang/smithy-rs/pull/755) Update SDK generator to set correct crate versions (https://github.com/smithy-lang/smithy-rs/pull/755) Write bulk publish script Write bulk yank script Write automation to sync smithy-rs to aws-sdk-rust","breadcrumbs":"RFCs » RFC-0011: Publishing Alpha to Crates.io » Short-term Changes Checklist","id":"184","title":"Short-term Changes Checklist"},"185":{"body":"Status: RFC During its alpha and dev preview releases, the AWS SDK for Rust adopted a short-term solution for versioning and publishing to crates.io . This doc proposes a long-term versioning strategy that will carry the SDK from dev preview into general availability. This strategy will be implemented in two phases: Dev Preview : The SDK will break with its current version strategy of maintaining consistent major.minor version numbers. Stability and 1.x : This phase begins when the SDK becomes generally available. The major version will be bumped to 1, and backwards breaking changes will no longer be allowed without a major version bump to all crates in the SDK.","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » RFC: Independent Crate Versioning","id":"185","title":"RFC: Independent Crate Versioning"},"186":{"body":"AWS SDK Crate : A crate that provides a client for calling a given AWS service, such as aws-sdk-s3 for calling S3. AWS Runtime Crate : Any runtime crate that the AWS SDK generated code relies on, such as aws-types. Smithy Runtime Crate : Any runtime crate that the smithy-rs generated code relies on, such as smithy-types.","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » Terminology","id":"186","title":"Terminology"},"187":{"body":"","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » Requirements","id":"187","title":"Requirements"},"188":{"body":"Cargo uses semver for versioning, with a major.minor.patch-pre format: major: Incompatible API changes minor: Added functionality in backwards compatible manner patch: Backwards compatible bug fixes pre: Pre-release version tag (omitted for normal releases) In the new versioning strategy, the minor version number will no longer be coordinated across all SDK and Smithy runtime crates. During phases 1 and 2, the major version will always be 0, and the following scheme will be used: minor: New features Breaking changes Dependency updates for dependencies that are part of the public API Model updates with API changes For code-generated crates: when a newer version of smithy-rs is used to generate the crate patch: Bug fixes that do not break backwards compatibility Model updates that only have documentation changes During phase 3: major: Breaking changes minor: Changes that aren't breaking Dependency updates for dependencies that are part of the public API Model updates with API changes For code-generated crates: when a newer version of smithy-rs is used to generate the crate patch: Bug fixes that do not break backwards compatibility Model updates that only have documentation changes During phase 3, bumps to the major version must be coordinated across all SDK and runtime crates.","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » Versioning","id":"188","title":"Versioning"},"189":{"body":"Since there will no longer be one SDK \"version\", release tags will be dates in YYYY-MM-DD format rather than version numbers. Additionally, the SDK's user agent string will need to include a separate service version number (this requirement has already been implemented).","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » Release Identification","id":"189","title":"Release Identification"},"19":{"body":"This section details the flow of a request through the SDK until a response is returned to the user.","breadcrumbs":"Transport » HTTP Operations » Operation Phases","id":"19","title":"Operation Phases"},"190":{"body":"It must be possible to yank an entire release with a single action. The publisher tool must be updated to understand which crate versions were released with a given release tag, and be able to yank all the crates published from that tag.","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » Yanking","id":"190","title":"Yanking"},"191":{"body":"Phase 1 will address the following challenges introduced by uncoordinating the major.minor versions: Tracking of versions associated with a release tag Creation of version bump process for code generated crates Enforcement of version bump process in runtime crates Yanking of versions associated with a release tag","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » Phase 1: Dev Preview","id":"191","title":"Phase 1: Dev Preview"},"192":{"body":"A new manifest file will be introduced in the root of aws-sdk-rust named versions.toml that describes all versioning information for any given commit in the repository. In the main branch, the versions.toml in tagged commits will become the source of truth for which crate versions belong to that release, as well as additional metadata that's required for maintaining version process in the future. The special 0.0.0-smithy-rs-head version that is used prior to Phase 1 for maintaining the runtime crate versions will no longer be used (as detailed in Versioning for Runtime Crates ). This format will look as follows: smithy_rs_version = \"\" [aws-smithy-types]\nversion = \"0.50.1\" [aws-config]\nversion = \"0.40.0\" [aws-sdk-s3]\nversion = \"0.89.0\"\nmodel_hash = \"\" # ... The auto-sync tool is responsible for maintaining this file. When it generates a new SDK, it will take the version numbers from runtime crates directly, and it will use the rules from the next section to determine the version numbers for the generated crates.","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » Version Tracking","id":"192","title":"Version Tracking"},"193":{"body":"Code generated crates will have their minor version bumped when the version of smithy-rs used to generate them changes, or when model updates with API changes are made. Three pieces of information are required to handle this process: the previously released version number, the smithy-rs version used to generate the code, and the level of model updates being applied. For this last one, if there are multiple model updates that affect only documentation, but then one model update that affects an API, then as a whole they will be considered as affecting an API and require a minor version bump. The previously released version number will be retrieved from crates.io using its API. The smithy-rs version used during code generation will become a build artifact that is saved to versions.toml in aws-sdk-rust . During phase 1, the tooling required to know if a model is a documentation-only change will not be available, so all model changes will result in a minor version bump during this phase. Overall, determining a generated crate's version number looks as follows: flowchart TD start[Generate crate version] --> smithyrschanged{A. smithy-rs changed?} smithyrschanged -- Yes --> minor1[Minor version bump] smithyrschanged -- No --> modelchanged{B. model changed?} modelchanged -- Yes --> minor2[Minor version bump] modelchanged -- No --> keep[Keep current version] A: smithy-rs changed? : Compare the smithy_rs_version in the previous versions.toml with the next versions.toml file, and if the values are different, consider smithy-rs to have changed. B: model changed? : Similarly, compare the model_hash for the crate in versions.toml.","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » Versioning for Code Generated (SDK Service) Crates","id":"193","title":"Versioning for Code Generated (SDK Service) Crates"},"194":{"body":"The old scheme of all runtime crates in smithy-rs having a fake 0.0.0-smithy-rs-head version number with a build step to replace those with a consistent major.minor will be removed. These runtime crates will begin having their actual next version number in the Cargo.toml file in smithy-rs. This introduces a new problem where a developer can forget to bump a runtime crate version, so a method of process enforcement needs to be introduced. This will be done through CI when merging into smithy-rs/main and repeated when merging into aws-sdk-rust/main. The following checks need to be run for runtime crates: flowchart TD A[Check runtime crate] --> B{A. Crate has changed?} B -- Yes --> C{B. Minor bumped?} B -- No --> H{C. Version changed?} C -- Yes --> K[Pass] C -- No --> E{D. Patch bumped?} E -- Yes --> F{E. Semverver passes?} E -- No --> L[Fail] F -- Yes --> D[Pass] F -- No --> G[Fail] H -- Yes --> I[Fail] H -- No --> J[Pass] A: Crate has changed? The crate's source files and manifest will be hashed for the previous version and the next version. If these hashes match, then the crate is considered unchanged. B: Minor bumped? The previous version is compared against the next version to see if the minor version number was bumped. C: Version changed? The previous version is compared against the next version to see if it changed. D: Patch bumped? The previous version is compared against the next version to see if the patch version number was bumped. E: Semverver passes? Runs rust-semverver against the old and new versions of the crate. If semverver fails to run (for example, if it needs to be updated to the latest nightly to succeed), then fail CI saying that either semverver needs maintenance, or that a minor version bump is required. If semverver results in errors, fail CI indicating a minor version bump is required. If semverver passes, then pass CI. When running semverver, the path dependencies of the crate under examination should be updated to be crates.io references if there were no changes in those crates since the last public to crates.io. Otherwise, the types referenced from those crates in the public API will always result in breaking changes since, as far as the Rust compiler is concerned, they are different types originating from separate path-dependency crates. For CI, the aws-sdk-rust/main branch's versions.toml file is the source of truth for the previous release's crate versions and source code.","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » Versioning for Runtime Crates","id":"194","title":"Versioning for Runtime Crates"},"195":{"body":"The publisher tool will be updated to read the versions.toml to yank all versions published in a release. This process will look as follows: Take a path to a local clone of the aws-sdk-rust repository Confirm the working tree is currently unmodified and on a release tag. Read versions.toml and print out summary of crates to yank Confirm with user before proceeding Yank crates","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » Yanking","id":"195","title":"Yanking"},"196":{"body":"Update rust-semverver to a newer nightly that can compile aws-smithy-client Establish initial versions.toml in aws-sdk-rust/main Set version numbers in runtime crates in smithy-rs Update the auto-sync tool to generate versions.toml Create CI tool to check runtime crate version Integrate with smithy-rs/main CI Integrate with aws-sdk-rust/main CI Update CI to verify no older runtime crates are used. For example, if aws-smithy-client is bumped to 0.50.0, then verify no crates (generated or runtime) depend on 0.49.0 or lower. Estimate: 2-4 dev weeks","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » Changes Checklist","id":"196","title":"Changes Checklist"},"197":{"body":"When stabilizing to 1.x, the version process will stay the same, but the minor version bumps caused by version bumping runtime crates, updating models, or changing the code generator will be candidate for automatic upgrade per semver. At that point, no further API breaking changes can be made without a major version bump.","breadcrumbs":"RFCs » RFC-0012: Independent Crate Versioning » Phase 2: Stability and 1.x","id":"197","title":"Phase 2: Stability and 1.x"},"198":{"body":"Status: RFC Adding a callback API to ByteStream and SdkBody will enable developers using the SDK to implement things like checksum validations and 'read progress' callbacks.","breadcrumbs":"RFCs » RFC-0013: Body Callback APIs » RFC: Callback APIs for ByteStream and SdkBody","id":"198","title":"RFC: Callback APIs for ByteStream and SdkBody"},"199":{"body":"Note that comments starting with '//' are not necessarily going to be included in the actual implementation and are intended as clarifying comments for the purposes of this RFC. // in aws_smithy_http::callbacks... /// A callback that, when inserted into a request body, will be called for corresponding lifecycle events.\ntrait BodyCallback: Send { /// This lifecycle function is called for each chunk **successfully** read. If an error occurs while reading a chunk, /// this method will not be called. This method takes `&mut self` so that implementors may modify an implementing /// struct/enum's internal state. Implementors may return an error. fn update(&mut self, #[allow(unused_variables)] bytes: &[u8]) -> Result<(), BoxError> { Ok(()) } /// This callback is called once all chunks have been read. If the callback encountered one or more errors /// while running `update`s, this is how those errors are raised. Implementors may return a [`HeaderMap`][HeaderMap] /// that will be appended to the HTTP body as a trailer. This is only useful to do for streaming requests. fn trailers(&self) -> Result>, BoxError> { Ok(None) } /// Create a new `BodyCallback` from an existing one. This is called when a `BodyCallback` needs to be /// re-initialized with default state. For example: when a request has a body that needs to be /// rebuilt, all callbacks for that body need to be run again but with a fresh internal state. fn make_new(&self) -> Box;\n} impl BodyCallback for Box { fn update(&mut self, bytes: &[u8]) -> Result<(), BoxError> { BodyCallback::update(self, bytes) } fn trailers(&self) -> Result>, BoxError> { BodyCallback::trailers(self) } fn make_new(&self) -> Box { BodyCallback::make_new(self) }\n} The changes we need to make to ByteStream: (The current version of ByteStream and Inner can be seen here .) // in `aws_smithy_http::byte_stream`... // We add a new method to `ByteStream` for inserting callbacks\nimpl ByteStream { // ...other impls omitted // A \"builder-style\" method for setting callbacks pub fn with_body_callback(&mut self, body_callback: Box) -> &mut Self { self.inner.with_body_callback(body_callback); self }\n} impl Inner { // `Inner` wraps an `SdkBody` which has a \"builder-style\" function for adding callbacks. pub fn with_body_callback(&mut self, body_callback: Box) -> &mut Self { self.body.with_body_callback(body_callback); self }\n} The changes we need to make to SdkBody: (The current version of SdkBody can be seen here .) // In aws_smithy_http::body... #[pin_project]\npub struct SdkBody { #[pin] inner: Inner, rebuild: Option Inner) + Send + Sync>>, // We add a `Vec` to store the callbacks #[pin] callbacks: Vec>,\n} impl SdkBody { // We update the various fns that create `SdkBody`s to create an empty `Vec` to store callbacks. // Those updates are very simple so I've omitted them from this code example. fn poll_inner( self: Pin<&mut Self>, cx: &mut Context<'_>, ) -> Poll>> { let mut this = self.project(); // This block is old. I've included for context. let polling_result = match this.inner.project() { InnerProj::Once(ref mut opt) => { let data = opt.take(); match data { Some(bytes) if bytes.is_empty() => Poll::Ready(None), Some(bytes) => Poll::Ready(Some(Ok(bytes))), None => Poll::Ready(None), } } InnerProj::Streaming(body) => body.poll_data(cx).map_err(|e| e.into()), InnerProj::Dyn(box_body) => box_body.poll_data(cx), InnerProj::Taken => { Poll::Ready(Some(Err(\"A `Taken` body should never be polled\".into()))) } }; // This block is new. match &polling_result { // When we get some bytes back from polling, pass those bytes to each callback in turn Poll::Ready(Some(Ok(bytes))) => { for callback in this.callbacks.iter_mut() { // Callbacks can run into errors when reading bytes. They'll be surfaced here callback.update(bytes)?; } } // When we're done polling for bytes, run each callback's `trailers()` method. If any calls to // `trailers()` return an error, propagate that error up. Otherwise, continue. Poll::Ready(None) => { for callback_result in this.callbacks.iter().map(BodyCallback::trailers) { if let Err(e) = callback_result { return Poll::Ready(Some(Err(e))); } } } _ => (), } // Now that we've inspected the polling result, all that's left to do is to return it. polling_result } // This function now has the added responsibility of cloning callback functions (but with fresh state) // in the case that the `SdkBody` needs to be rebuilt. pub fn try_clone(&self) -> Option { self.rebuild.as_ref().map(|rebuild| { let next = rebuild(); let callbacks = self .callbacks .iter() .map(Callback::make_new) .collect(); Self { inner: next, rebuild: self.rebuild.clone(), callbacks, } }) } pub fn with_callback(&mut self, callback: BodyCallback) -> &mut Self { self.callbacks.push(callback); self }\n} /// Given two [`HeaderMap`][HeaderMap]s, merge them together and return the merged `HeaderMap`. If the\n/// two `HeaderMap`s share any keys, values from the right `HeaderMap` be appended to the left `HeaderMap`.\n///\n/// # Example\n///\n/// ```rust\n/// let header_name = HeaderName::from_static(\"some_key\");\n///\n/// let mut left_hand_side_headers = HeaderMap::new();\n/// left_hand_side_headers.insert(\n/// header_name.clone(),\n/// HeaderValue::from_str(\"lhs value\").unwrap(),\n/// );\n///\n/// let mut right_hand_side_headers = HeaderMap::new();\n/// right_hand_side_headers.insert(\n/// header_name.clone(),\n/// HeaderValue::from_str(\"rhs value\").unwrap(),\n/// );\n///\n/// let merged_header_map =\n/// append_merge_header_maps(left_hand_side_headers, right_hand_side_headers);\n/// let merged_values: Vec<_> = merged_header_map\n/// .get_all(header_name.clone())\n/// .into_iter()\n/// .collect();\n///\n/// // Will print 'some_key: [\"lhs value\", \"rhs value\"]'\n/// println!(\"{}: {:?}\", header_name.as_str(), merged_values);\n/// ```\nfn append_merge_header_maps( mut lhs: HeaderMap, rhs: HeaderMap,\n) -> HeaderMap { let mut last_header_name_seen = None; for (header_name, header_value) in rhs.into_iter() { // For each yielded item that has None provided for the `HeaderName`, // then the associated header name is the same as that of the previously // yielded item. The first yielded item will have `HeaderName` set. // https://docs.rs/http/latest/http/header/struct.HeaderMap.html#method.into_iter-2 match (&mut last_header_name_seen, header_name) { (_, Some(header_name)) => { lhs.append(header_name.clone(), header_value); last_header_name_seen = Some(header_name); } (Some(header_name), None) => { lhs.append(header_name.clone(), header_value); } (None, None) => unreachable!(), }; } lhs\n} impl http_body::Body for SdkBody { // The other methods have been omitted because they haven't changed fn poll_trailers( self: Pin<&mut Self>, _cx: &mut Context<'_>, ) -> Poll>, Self::Error>> { let header_map = self .callbacks .iter() .filter_map(|callback| { match callback.trailers() { Ok(optional_header_map) => optional_header_map, // early return if a callback encountered an error Err(e) => { return e }, } }) // Merge any `HeaderMap`s from the last step together, one by one. .reduce(append_merge_header_maps); Poll::Ready(Ok(header_map)) }\n}","breadcrumbs":"RFCs » RFC-0013: Body Callback APIs » The Implementation","id":"199","title":"The Implementation"},"2":{"body":"The Rust SDK is \"modular\" meaning that each AWS service is its own crate. Each crate provides two layers to access the service: The \"fluent\" API. For most use cases, a high level API that ties together connection management and serialization will be the quickest path to success. #[tokio::main]\nasync fn main() { let client = dynamodb::Client::from_env(); let tables = client .list_tables() .limit(10) .send() .await.expect(\"failed to load tables\");\n} The \"low-level\" API: It is also possible for customers to assemble the pieces themselves. This offers more control over operation construction & dispatch semantics: #[tokio::main]\nasync fn main() { let conf = dynamodb::Config::builder().build(); let conn = aws_hyper::Client::https(); let operation = dynamodb::ListTables::builder() .limit(10) .build(&conf) .expect(\"invalid operation\"); let tables = conn.call(operation).await.expect(\"failed to list tables\");\n} The Fluent API is implemented as a thin wrapper around the core API to improve ergonomics.","breadcrumbs":"Design Overview » External API Overview","id":"2","title":"External API Overview"},"20":{"body":"A customer interacts with the SDK builders to construct an input. The build() method on an input returns an Operation. This codifies the base HTTP request & all the configuration and middleware layers required to modify and dispatch the request. pub struct Operation { request: Request, response_handler: H, _retry_policy: R,\n} pub struct Request { inner: http::Request, properties: PropertyBag,\n} For most requests, .build() will NOT consume the input. A user can call .build() multiple times to produce multiple operations from the same input. By using a property bag, we can define the Operation in Smithy core. AWS specific configuration can be added later in the stack.","breadcrumbs":"Transport » HTTP Operations » Input Construction","id":"20","title":"Input Construction"},"200":{"body":"What follows is a simplified example of how this API could be used to introduce checksum validation for outgoing request payloads. In this example, the checksum calculation is fallible and no validation takes place. All it does it calculate the checksum of some data and then returns the checksum of that data when trailers is called. This is fine because it's being used to calculate the checksum of a streaming body for a request. #[derive(Default)]\nstruct Crc32cChecksumCallback { state: Option,\n} impl ReadCallback for Crc32cChecksumCallback { fn update(&mut self, bytes: &[u8]) -> Result<(), BoxError> { self.state = match self.state { Some(crc) => { self.state = Some(crc32c_append(crc, bytes)) } None => { Some(crc32c(&bytes)) } }; Ok(()) } fn trailers(&self) -> Result>, Box> { let mut header_map = HeaderMap::new(); // This checksum name is an Amazon standard and would be a `const` in the real implementation let key = HeaderName::from_static(\"x-amz-checksum-crc32c\"); // If no data was provided to this callback and no CRC was ever calculated, we return zero as the checksum. let crc = self.state.unwrap_or_default(); // Convert the CRC to a string, base 64 encode it, and then convert it into a `HeaderValue`. let value = HeaderValue::from_str(&base64::encode(crc.to_string())).expect(\"base64 will always produce valid header values\"); header_map.insert(key, value); Some(header_map) } fn make_new(&self) -> Box { Box::new(Crc32cChecksumCallback::default()) }\n} NOTE: If Crc32cChecksumCallback needed to validate a response, then we could modify it to check its internal state against a target checksum value and calling trailers would produce an error if the values didn't match. In order to use this in a request, we'd modify codegen for that request's service. We'd check if the user had requested validation and also check if they'd pre-calculated a checksum. If validation was requested but no pre-calculated checksum was given, we'd create a callback similar to the one above Then, we'd create a new checksum callback and: (if streaming) we'd set the checksum callback on the request body object (if non-streaming) we'd immediately read the body and call BodyCallback::update manually. Once all data was read, we'd get the checksum by calling trailers and insert that data as a request header.","breadcrumbs":"RFCs » RFC-0013: Body Callback APIs » Implementing Checksums","id":"200","title":"Implementing Checksums"},"201":{"body":"Status: Implemented For a summarized list of proposed changes, see the Changes Checklist section. While it is currently possible for users to implement request timeouts by racing operation send futures against timeout futures, this RFC proposes a more ergonomic solution that would also enable users to set timeouts for things like TLS negotiation and \"time to first byte\".","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » RFC: Fine-grained timeout configuration","id":"201","title":"RFC: Fine-grained timeout configuration"},"202":{"body":"There's a lot of terminology to define, so I've broken it up into three sections.","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » Terminology","id":"202","title":"Terminology"},"203":{"body":"Smithy Client : A aws_smithy_client::Client struct that is responsible for gluing together the connector, middleware, and retry policy. This is not generated and lives in the aws-smithy-client crate. Fluent Client : A code-generated Client that has methods for each service operation on it. A fluent builder is generated alongside it to make construction easier. AWS Client : A specialized Fluent Client that defaults to using a DynConnector, AwsMiddleware, and Standard retry policy. Shared Config : An aws_types::Config struct that is responsible for storing shared configuration data that is used across all services. This is not generated and lives in the aws-types crate. Service-specific Config : A code-generated Config that has methods for setting service-specific configuration. Each Config is defined in the config module of its parent service. For example, the S3-specific config struct is useable from aws_sdk_s3::config::Config and re-exported as aws_sdk_s3::Config. In this case, \"service\" refers to an AWS offering like S3.","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » General terms","id":"203","title":"General terms"},"204":{"body":"Service : A trait defined in the tower-service crate . The lowest level of abstraction we deal with when making HTTP requests. Services act directly on data to transform and modify that data. A Service is what eventually turns a request into a response. Layer : Layers are a higher-order abstraction over services that is used to compose multiple services together, creating a new service from that combination. Nothing prevents us from manually wrapping services within services, but Layers allow us to do it in a flexible and generic manner. Layers don't directly act on data but instead can wrap an existing service with additional functionality, creating a new service. Layers can be thought of as middleware. NOTE: The use of Layers can produce compiler errors that are difficult to interpret and defining a layer requires a large amount of boilerplate code. Middleware : a term with several meanings, Generically speaking, middleware are similar to Services and Layers in that they modify requests and responses. In the SDK, \"Middleware\" refers to a layer that can be wrapped around a DispatchService. In practice, this means that the resulting Service (and the inner service) must meet the bound T: where T: Service. Note: This doesn't apply to the middlewares we use when generating presigned request because those don't wrap a DispatchService. The most notable example of a Middleware is the AwsMiddleware . Other notable examples include MapRequest , AsyncMapRequest , and ParseResponse . DispatchService : The innermost part of a group of nested services. The Service that actually makes an HTTP call on behalf of a request. Responsible for parsing success and error responses. Connector : a term with several meanings, DynConnectors (a struct that implements DynConnect ) are Services with their specific type erased so that we can do dynamic dispatch. A term from hyper for any object that implements the Connect trait. Really just an alias for tower_service::Service . Sometimes referred to as a Connection. Stage : A form of middleware that's not related to tower. These currently function as a way of transforming requests and don't have the ability to transform responses. Stack : higher order abstraction over Layers defined in the tower crate e.g. Layers wrap services in one another and Stacks wrap layers within one another.","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » HTTP stack terms","id":"204","title":"HTTP stack terms"},"205":{"body":"Connect Timeout : A limit on the amount of time after making an initial connect attempt on a socket to complete the connect-handshake. TODO: the runtime is based on Hyper which reuses connection and doesn't currently have a way of guaranteeing that a fresh connection will be use for a given request. TLS Negotiation Timeout : A limit on the amount of time a TLS handshake takes from when the CLIENT HELLO message is sent to the time the client and server have fully negotiated ciphers and exchanged keys. Time to First Byte Timeout : Sometimes referred to as a \"read timeout.\" A limit on the amount of time an application takes to attempt to read the first byte over an established, open connection after write request. HTTP Request Timeout For A Single Attempt : A limit on the amount of time it takes for the first byte to be sent over an established, open connection and when the last byte is received from the service. HTTP Request Timeout For Multiple Attempts : This timeout acts like the previous timeout but constrains the total time it takes to make a request plus any retries. NOTE: In a way, this is already possible in that users are free to race requests against timer futures with the futures::future::select macro or to use tokio::time::timeout . See relevant discussion in hyper#1097","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » Timeout terms","id":"205","title":"Timeout terms"},"206":{"body":"Just like with Retry Behavior Configuration , these settings can be configured in several places and have the same precedence rules (paraphrased here for clarity) . Service-specific config builders Shared config builders Environment variables Profile config file (e.g., ~/.aws/credentials) The above list is in order of decreasing precedence e.g. configuration set in an app will override values from environment variables.","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » Configuring timeouts","id":"206","title":"Configuring timeouts"},"207":{"body":"The table below details the specific ways each timeout can be configured. In all cases, valid values are non-negative floats representing the number of seconds before a timeout is triggered. Timeout Environment Variable AWS Config Variable Builder Method Connect AWS_CONNECT_TIMEOUT connect_timeout connect_timeout TLS Negotiation AWS_TLS_NEGOTIATION_TIMEOUT tls_negotiation_timeout tls_negotiation_timeout Time To First Byte AWS_READ_TIMEOUT read_timeout read_timeout HTTP Request - single attempt AWS_API_CALL_ATTEMPT_TIMEOUT api_call_attempt_timeout api_call_attempt_timeout HTTP Request - all attempts AWS_API_CALL_TIMEOUT api_call_timeout api_call_timeout","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » Configuration options","id":"207","title":"Configuration options"},"208":{"body":"QUESTION: How does the SDK currently handle these defaults?","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » SDK-specific defaults set by AWS service teams","id":"208","title":"SDK-specific defaults set by AWS service teams"},"209":{"body":"hjr3/hyper-timeout is a Connector for hyper that enables setting connect, read, and write timeouts sfackler/tokio-io-timeout provides timeouts for tokio IO operations. Used within hyper-timeout. [tokio::time::sleep_until] creates a Future that completes after some time has elapsed. Used within tokio-io-timeout.","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » Prior Art","id":"209","title":"Prior Art"},"21":{"body":"In order to construct an operation, the generated code injects appropriate middleware & configuration via the configuration property bag. It does this by reading the configuration properties out of the service config, copying them as necessary, and loading them into the Request: // This is approximately the generated code, I've cleaned a few things up for readability.\npub fn build(self, config: &dynamodb::config::Config) -> Operation { let op = BatchExecuteStatement::new(BatchExecuteStatementInput { statements: self.statements, }); let req = op.build_http_request().map(SdkBody::from); let mut req = operation::Request::new(req); let mut props = req.properties_mut(); props.insert_signing_config(config.signing_service()); props.insert_endpoint_resolver(config.endpoint_resolver.clone()); Operation::new(req)\n}","breadcrumbs":"Transport » HTTP Operations » Operation Construction","id":"21","title":"Operation Construction"},"210":{"body":"Timeouts are achieved by racing a future against a tokio::time::Sleep future. The question, then, is \"how can I create a future that represents a condition I want to watch for?\". For example, in the case of a ConnectTimeout, how do we watch an ongoing request to see if it's completed the connect-handshake? Our current stack of Middleware acts on requests at different levels of granularity. The timeout Middlewares will be no different.","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » Behind the scenes","id":"210","title":"Behind the scenes"},"211":{"body":"View AwsMiddleware in GitHub #[derive(Debug, Default)]\n#[non_exhaustive]\npub struct AwsMiddleware;\nimpl tower::Layer for AwsMiddleware { type Service = >::Service; fn layer(&self, inner: S) -> Self::Service { let credential_provider = AsyncMapRequestLayer::for_mapper(CredentialsStage::new()); let signer = MapRequestLayer::for_mapper(SigV4SigningStage::new(SigV4Signer::new())); let endpoint_resolver = MapRequestLayer::for_mapper(AwsAuthStage); let user_agent = MapRequestLayer::for_mapper(UserAgentStage::new()); ServiceBuilder::new() .layer(endpoint_resolver) .layer(user_agent) .layer(credential_provider) .layer(signer) .service(inner) }\n} The above code is only included for context. This RFC doesn't define any timeouts specific to AWS so AwsMiddleware won't require any changes.","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » Middlewares for AWS Client requests","id":"211","title":"Middlewares for AWS Client requests"},"212":{"body":"View aws_smithy_client::Client::call_raw in GitHub impl Client where C: bounds::SmithyConnector, M: bounds::SmithyMiddleware, R: retry::NewRequestPolicy,\n{ // ...other methods omitted pub async fn call_raw( &self, input: Operation, ) -> Result, SdkError> where R::Policy: bounds::SmithyRetryPolicy, bounds::Parsed<>::Service, O, Retry>: Service, Response=SdkSuccess, Error=SdkError> + Clone, { let connector = self.connector.clone(); let mut svc = ServiceBuilder::new() // Create a new request-scoped policy .retry(self.retry_policy.new_request_policy()) .layer(ParseResponseLayer::::new()) // These layers can be considered as occurring in order. That is, first invoke the // customer-provided middleware, then dispatch dispatch over the wire. .layer(&self.middleware) .layer(DispatchLayer::new()) .service(connector); svc.ready().await?.call(input).await }\n} The Smithy Client creates a new Stack of services to handle each request it sends. Specifically: A method retry is used set the retry handler. The configuration for this was set during creation of the Client. ParseResponseLayer inserts a service for transforming responses into operation-specific outputs or errors. The O generic parameter of input is what decides exactly how the transformation is implemented. A middleware stack that was included during Client creation is inserted into the stack. In the case of the AWS SDK, this would be AwsMiddleware. DispatchLayer inserts a service for transforming an http::Request into an operation::Request. It's also responsible for re-attaching the property bag from the Operation that triggered the request. The innermost Service is a DynConnector wrapping a hyper client (which one depends on the TLS implementation was enabled by cargo features.) The HTTP Request Timeout For A Single Attempt and HTTP Request Timeout For Multiple Attempts can be implemented at this level. The same Layer can be used to create both TimeoutServices. The TimeoutLayer would require two inputs: sleep_fn: A runtime-specific implementation of sleep. The SDK is currently tokio-based and would default to tokio::time::sleep (this default is set in the aws_smithy_async::rt::sleep module.) The duration of the timeout as a std::time::Duration The resulting code would look like this: impl Client where C: bounds::SmithyConnector, M: bounds::SmithyMiddleware, R: retry::NewRequestPolicy,\n{ // ...other methods omitted pub async fn call_raw( &self, input: Operation, ) -> Result, SdkError> where R::Policy: bounds::SmithyRetryPolicy, bounds::Parsed<>::Service, O, Retry>: Service, Response=SdkSuccess, Error=SdkError> + Clone, { let connector = self.connector.clone(); let sleep_fn = aws_smithy_async::rt::sleep::default_async_sleep(); let mut svc = ServiceBuilder::new() .layer(TimeoutLayer::new( sleep_fn, self.timeout_config.api_call_timeout(), )) // Create a new request-scoped policy .retry(self.retry_policy.new_request_policy()) .layer(TimeoutLayer::new( sleep_fn, self.timeout_config.api_call_attempt_timeout(), )) .layer(ParseResponseLayer::::new()) // These layers can be considered as occurring in order. That is, first invoke the // customer-provided middleware, then dispatch dispatch over the wire. .layer(&self.middleware) .layer(DispatchLayer::new()) .service(connector); svc.ready().await?.call(input).await }\n} Note: Our HTTP client supports multiple TLS implementations. We'll likely have to implement this feature once per library. Timeouts will be implemented in the following places: HTTP request timeout for multiple requests will be implemented as the outermost Layer in Client::call_raw. HTTP request timeout for a single request will be implemented within RetryHandler::retry. Time to first byte, TLS negotiation, and connect timeouts will be implemented within the central hyper connector.","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » Middlewares for Smithy Client requests","id":"212","title":"Middlewares for Smithy Client requests"},"213":{"body":"Changes are broken into to sections: HTTP requests (single or multiple) are implementable as layers within our current stack Other timeouts will require changes to our dependencies and may be slower to implement","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » Changes checklist","id":"213","title":"Changes checklist"},"214":{"body":"Add TimeoutConfig to smithy-types Add TimeoutConfigProvider to aws-config Add provider that fetches config from environment variables Add provider that fetches config from profile Add timeout method to aws_types::Config for setting timeout configuration Add timeout method to generated Configs too Create a generic TimeoutService and accompanying Layer TimeoutLayer should accept a sleep function so that it doesn't have a hard dependency on tokio insert a TimeoutLayer before the RetryPolicy to handle timeouts for multiple-attempt requests insert a TimeoutLayer after the RetryPolicy to handle timeouts for single-attempt requests Add tests for timeout behavior test multi-request timeout triggers after 3 slow retries test single-request timeout triggers correctly test single-request timeout doesn't trigger if request completes in time","breadcrumbs":"RFCs » RFC-0014: Fine-grained timeout configuration » Implementing HTTP request timeouts","id":"214","title":"Implementing HTTP request timeouts"},"215":{"body":"Status: Accepted","breadcrumbs":"RFCs » RFC-0015: How Cargo \"features\" should be used in the SDK and runtime crates » RFC: How Cargo \"features\" should be used in the SDK and runtime crates","id":"215","title":"RFC: How Cargo \"features\" should be used in the SDK and runtime crates"},"216":{"body":"What is a feature? Here's a definition from the Cargo Book section on features : Cargo \"features\" provide a mechanism to express conditional compilation and optional dependencies. A package defines a set of named features in the [features] table of Cargo.toml, and each feature can either be enabled or disabled. Features for the package being built can be enabled on the command-line with flags such as --features. Features for dependencies can be enabled in the dependency declaration in Cargo.toml. We use features in a majority of our runtime crates and in all of our SDK crates. For example, aws-sigv4 uses them to enable event streams. Another common use case is exhibited by aws-sdk-s3 which uses them to enable the tokio runtime and the TLS implementation used when making requests.","breadcrumbs":"RFCs » RFC-0015: How Cargo \"features\" should be used in the SDK and runtime crates » Some background on features","id":"216","title":"Some background on features"},"217":{"body":"The Cargo book has this to say: When a dependency is used by multiple packages, Cargo will use the union of all features enabled on that dependency when building it. This helps ensure that only a single copy of the dependency is used. A consequence of this is that features should be additive . That is, enabling a feature should not disable functionality, and it should usually be safe to enable any combination of features. A feature should not introduce a SemVer-incompatible change .","breadcrumbs":"RFCs » RFC-0015: How Cargo \"features\" should be used in the SDK and runtime crates » Features should be additive","id":"217","title":"Features should be additive"},"218":{"body":"Despite the constraints outlined above, we should use features in the SDKs because of the benefits they bring: Features enable users to avoid compiling code that they won't be using. Additionally, features allow both general and specific control of compiled code, serving the needs of both novice and expert users. A single feature in a crate can activate or deactivate multiple features exposed by that crate's dependencies, freeing the user from having to specifically activate or deactivate them. Features can help users understand what a crate is capable of in the same way that looking at a graph of a crate's modules can. When using features, we should adhere to the guidelines outlined below.","breadcrumbs":"RFCs » RFC-0015: How Cargo \"features\" should be used in the SDK and runtime crates » What does this mean for the SDK?","id":"218","title":"What does this mean for the SDK?"},"219":{"body":"As noted earlier in an excerpt from the Cargo book: enabling a feature should not disable functionality, and it should usually be safe to enable any combination of features. A feature should not introduce a SemVer-incompatible change . #[cfg(feature = \"rustls\")]\nimpl ClientBuilder<(), M, R> { /// Connect to the service over HTTPS using Rustls. pub fn tls_adapter(self) -> ClientBuilder, M, R> { self.connector(Adapter::builder().build(crate::conns::https())) }\n} #[cfg(feature = \"native-tls\")]\nimpl ClientBuilder<(), M, R> { /// Connect to the service over HTTPS using the native TLS library on your platform. pub fn tls_adapter( self, ) -> ClientBuilder>, M, R> { self.connector(Adapter::builder().build(crate::conns::native_tls())) }\n} When the example code above is compiled with both features enabled, compilation will fail with a \"duplicate definitions with name tls_adapter\" error. Also, note that the return type of the function differs between the two versions. This is a SemVer-incompatible change. Here's an updated version of the example that fixes these issues: #[cfg(feature = \"rustls\")]\nimpl ClientBuilder<(), M, R> { /// Connect to the service over HTTPS using Rustls. pub fn rustls(self) -> ClientBuilder, M, R> { self.connector(Adapter::builder().build(crate::conns::https())) }\n} #[cfg(feature = \"native-tls\")]\nimpl ClientBuilder<(), M, R> { /// Connect to the service over HTTPS using the native TLS library on your platform. pub fn native_tls( self, ) -> ClientBuilder>, M, R> { self.connector(Adapter::builder().build(crate::conns::native_tls())) }\n} Both features can now be enabled at once without creating a conflict. Since both methods have different names, it's now Ok for them to have different return types. This is real code, see it in context","breadcrumbs":"RFCs » RFC-0015: How Cargo \"features\" should be used in the SDK and runtime crates » Avoid writing code that relies on only activating one feature from a set of mutually exclusive features.","id":"219","title":"Avoid writing code that relies on only activating one feature from a set of mutually exclusive features."},"22":{"body":"The Rust SDK endeavors to behave as predictably as possible. This means that if at all possible we will not dispatch extra HTTP requests during the dispatch of normal operation. Making this work is covered in more detail in the design of credentials providers & endpoint resolution. The upshot is that we will always prefer a design where the user has explicit control of when credentials are loaded and endpoints are resolved. This doesn't mean that users can't use easy-to-use options (We will provide an automatically refreshing credentials provider), however, the credential provider won't load requests during the dispatch of an individual request.","breadcrumbs":"Transport » HTTP Operations » Operation Dispatch and Middleware","id":"22","title":"Operation Dispatch and Middleware"},"220":{"body":"At the risk of seeming repetitive, the Cargo book says: enabling a feature should not disable functionality, and it should usually be safe to enable any combination of features Conditionally compiling code when a feature is not activated can make it hard for users and maintainers to reason about what will happen when they activate a feature. This is also a sign that a feature may not be \"additive\". NOTE : It's ok to use #[cfg(not())] to conditionally compile code based on a user's OS. It's also useful when controlling what code gets rendered when testing or when generating docs. One case where using not is acceptable is when providing a fallback when no features are set: #[cfg(feature = \"rt-tokio\")]\npub fn default_async_sleep() -> Option> { Some(sleep_tokio())\n} #[cfg(not(feature = \"rt-tokio\"))]\npub fn default_async_sleep() -> Option> { None\n}","breadcrumbs":"RFCs » RFC-0015: How Cargo \"features\" should be used in the SDK and runtime crates » We should avoid using #[cfg(not(feature = \"some-feature\"))]","id":"220","title":"We should avoid using #[cfg(not(feature = \"some-feature\"))]"},"221":{"body":"Because Cargo will use the union of all features enabled on a dependency when building it, we should be wary of marking features as default. Once we do mark features as default, users that want to exclude code and dependencies brought in by those features will have a difficult time doing so. One need look no further than this issue submitted by a user that wanted to use Native TLS and struggled to make sure that Rustls was actually disabled (This issue was resolved in this PR which removed default features from our runtime crates.) This is not to say that we should never use them, as having defaults for the most common use cases means less work for those users. When a default feature providing some functionality is disabled, active features must not automatically replace that functionality As the SDK is currently designed, the TLS implementation in use can change depending on what features are pulled in. Currently, if a user disables default-features (which include rustls) and activates the native-tls feature, then we automatically use native-tls when making requests. For an example of what this looks like from the user's perspective, see this example . This RFC proposes that we should have a single default for any configurable functionality and that that functionality depends on a corresponding default feature being active. If default-features are disabled, then so is the corresponding default functionality. In its place would be functionality that fails fast with a message describing why it failed (a default was deactivated but the user didn't set a replacement) , and what the user should do to fix it (with links to documentation and examples where necessary) . We should use compile-time errors to communicate failures with users, or panics for cases that can't be evaluated at compile-time. For an example: Say you have a crate with features a, b, c that all provide some version of functionality foo. Feature a is part of default-features. When no-default-features = true but features b and c are active, don't automatically fall back to b or c. Instead, emit an error with a message like this: \"When default features are disabled, you must manually set foo. Features b and c active; You can use one of those. See an example of setting a custom foo here: link-to-docs.amazon.com/setting-foo \"","breadcrumbs":"RFCs » RFC-0015: How Cargo \"features\" should be used in the SDK and runtime crates » Don't default to defining \"default features\"","id":"221","title":"Don't default to defining \"default features\""},"222":{"body":"How to tell what \"features\" are available per crate? How do I 'pass down' feature flags to subdependencies in Cargo? A small selection of feature-related GitHub issues submitted for popular crates The feature preserve_order is not \"purely additive,\" which makes it impossible to use serde_yaml 0.5.0 and clap in the same program cargo features (verbose-errors may be other?) should be additive Mutually exclusive features are present in profiling-procmacros Clang-sys features not additive","breadcrumbs":"RFCs » RFC-0015: How Cargo \"features\" should be used in the SDK and runtime crates » Further reading","id":"222","title":"Further reading"},"223":{"body":"Status: Implemented We can't currently update the S3 SDK because we don't support the new \"Flexible Checksums\" feature. This RFC describes this new feature and details how we should implement it in smithy-rs.","breadcrumbs":"RFCs » RFC-0016: Supporting Flexible Checksums » RFC: Supporting Flexible Checksums","id":"223","title":"RFC: Supporting Flexible Checksums"},"224":{"body":"S3 has previously supported MD5 checksum validation of data. Now, it supports more checksum algorithms like CRC32, CRC32C, SHA-1, and SHA-256. This validation is available when putting objects to S3 and when getting them from S3. For more information, see this AWS News Blog post .","breadcrumbs":"RFCs » RFC-0016: Supporting Flexible Checksums » What is the \"Flexible Checksums\" feature?","id":"224","title":"What is the \"Flexible Checksums\" feature?"},"225":{"body":"Checksum callbacks were introduced as a result of the acceptance of RFC0013 and this RFC proposes a refactor to those callbacks, as well as several new wrappers for SdkBody that will provide new functionality.","breadcrumbs":"RFCs » RFC-0016: Supporting Flexible Checksums » Implementing Checksums","id":"225","title":"Implementing Checksums"},"226":{"body":"TLDR; This refactor of aws-smithy-checksums: Removes the \"callback\" terminology: As a word, \"callback\" doesn't carry any useful information, and doesn't aid in understanding. Removes support for the BodyCallback API: Instead of adding checksum callbacks to a body, we're going to use a \"body wrapping\" instead. \"Body wrapping\" is demonstrated in the ChecksumBody , AwsChunkedBody , and ChecksumValidatedBody sections. NOTE: This doesn't remove the BodyCallback trait. That will still exist, we just won't use it. Updates terminology to focus on \"headers\" instead of \"trailers\": Because the types we deal with in this module are named for HTTP headers, I chose to use that terminology instead. My hope is that this will be less strange to people reading this code. Adds fn checksum_algorithm_to_checksum_header_name: a function that's used in generated code to set a checksum request header. Adds fn checksum_header_name_to_checksum_algorithm: a function that's used in generated code when creating a checksum-validating response body. Add new checksum-related \"body wrapping\" HTTP body types : These are defined in the body module and will be shown later in this RFC. // In aws-smithy-checksums/src/lib.rs\n//! Checksum calculation and verification callbacks use aws_smithy_types::base64; use bytes::Bytes;\nuse http::header::{HeaderMap, HeaderName, HeaderValue};\nuse sha1::Digest;\nuse std::io::Write; pub mod body; // Valid checksum algorithm names\npub const CRC_32_NAME: &str = \"crc32\";\npub const CRC_32_C_NAME: &str = \"crc32c\";\npub const SHA_1_NAME: &str = \"sha1\";\npub const SHA_256_NAME: &str = \"sha256\"; pub const CRC_32_HEADER_NAME: HeaderName = HeaderName::from_static(\"x-amz-checksum-crc32\");\npub const CRC_32_C_HEADER_NAME: HeaderName = HeaderName::from_static(\"x-amz-checksum-crc32c\");\npub const SHA_1_HEADER_NAME: HeaderName = HeaderName::from_static(\"x-amz-checksum-sha1\");\npub const SHA_256_HEADER_NAME: HeaderName = HeaderName::from_static(\"x-amz-checksum-sha256\"); // Preserved for compatibility purposes. This should never be used by users, only within smithy-rs\nconst MD5_NAME: &str = \"md5\";\nconst MD5_HEADER_NAME: HeaderName = HeaderName::from_static(\"content-md5\"); /// Given a `&str` representing a checksum algorithm, return the corresponding `HeaderName`\n/// for that checksum algorithm.\npub fn checksum_algorithm_to_checksum_header_name(checksum_algorithm: &str) -> HeaderName { if checksum_algorithm.eq_ignore_ascii_case(CRC_32_NAME) { CRC_32_HEADER_NAME } else if checksum_algorithm.eq_ignore_ascii_case(CRC_32_C_NAME) { CRC_32_C_HEADER_NAME } else if checksum_algorithm.eq_ignore_ascii_case(SHA_1_NAME) { SHA_1_HEADER_NAME } else if checksum_algorithm.eq_ignore_ascii_case(SHA_256_NAME) { SHA_256_HEADER_NAME } else if checksum_algorithm.eq_ignore_ascii_case(MD5_NAME) { MD5_HEADER_NAME } else { // TODO what's the best way to handle this case? HeaderName::from_static(\"x-amz-checksum-unknown\") }\n} /// Given a `HeaderName` representing a checksum algorithm, return the name of that algorithm\n/// as a `&'static str`.\npub fn checksum_header_name_to_checksum_algorithm( checksum_header_name: &HeaderName,\n) -> &'static str { if checksum_header_name == CRC_32_HEADER_NAME { CRC_32_NAME } else if checksum_header_name == CRC_32_C_HEADER_NAME { CRC_32_C_NAME } else if checksum_header_name == SHA_1_HEADER_NAME { SHA_1_NAME } else if checksum_header_name == SHA_256_HEADER_NAME { SHA_256_NAME } else if checksum_header_name == MD5_HEADER_NAME { MD5_NAME } else { // TODO what's the best way to handle this case? \"unknown-checksum-algorithm\" }\n} /// When a response has to be checksum-verified, we have to check possible headers until we find the\n/// header with the precalculated checksum. Because a service may send back multiple headers, we have\n/// to check them in order based on how fast each checksum is to calculate.\npub const CHECKSUM_HEADERS_IN_PRIORITY_ORDER: [HeaderName; 4] = [ CRC_32_C_HEADER_NAME, CRC_32_HEADER_NAME, SHA_1_HEADER_NAME, SHA_256_HEADER_NAME,\n]; type BoxError = Box; /// Checksum algorithms are use to validate the integrity of data. Structs that implement this trait\n/// can be used as checksum calculators. This trait requires Send + Sync because these checksums are\n/// often used in a threaded context.\npub trait Checksum: Send + Sync { /// Given a slice of bytes, update this checksum's internal state. fn update(&mut self, bytes: &[u8]) -> Result<(), BoxError>; /// Either return this checksum as a `HeaderMap` containing one HTTP header, or return an error /// describing why checksum calculation failed. fn headers(&self) -> Result>, BoxError>; /// Return the `HeaderName` used to represent this checksum algorithm fn header_name(&self) -> HeaderName; /// \"Finalize\" this checksum, returning the calculated value as `Bytes` or an error that /// occurred during checksum calculation. To print this value in a human-readable hexadecimal /// format, you can print it using Rust's builtin [formatter]. /// /// _**NOTE:** typically, \"finalizing\" a checksum in Rust will take ownership of the checksum /// struct. In this method, we clone the checksum's state before finalizing because checksums /// may be used in a situation where taking ownership is not possible._ /// /// [formatter]: https://doc.rust-lang.org/std/fmt/trait.UpperHex.html fn finalize(&self) -> Result; /// Return the size of this checksum algorithms resulting checksum, in bytes. For example, the /// CRC32 checksum algorithm calculates a 32 bit checksum, so a CRC32 checksum struct /// implementing this trait method would return 4. fn size(&self) -> u64;\n} /// Create a new `Box` from an algorithm name. Valid algorithm names are defined as\n/// `const`s in this module.\npub fn new_checksum(checksum_algorithm: &str) -> Box { if checksum_algorithm.eq_ignore_ascii_case(CRC_32_NAME) { Box::new(Crc32::default()) } else if checksum_algorithm.eq_ignore_ascii_case(CRC_32_C_NAME) { Box::new(Crc32c::default()) } else if checksum_algorithm.eq_ignore_ascii_case(SHA_1_NAME) { Box::new(Sha1::default()) } else if checksum_algorithm.eq_ignore_ascii_case(SHA_256_NAME) { Box::new(Sha256::default()) } else if checksum_algorithm.eq_ignore_ascii_case(MD5_NAME) { // It's possible to create an MD5 and we do this in some situations for compatibility. // We deliberately hide this from users so that they don't go using it. Box::new(Md5::default()) } else { panic!(\"unsupported checksum algorithm '{}'\", checksum_algorithm) }\n} #[derive(Debug, Default)]\nstruct Crc32 { hasher: crc32fast::Hasher,\n} impl Crc32 { fn update(&mut self, bytes: &[u8]) -> Result<(), BoxError> { self.hasher.update(bytes); Ok(()) } fn headers(&self) -> Result>, BoxError> { let mut header_map = HeaderMap::new(); header_map.insert(Self::header_name(), self.header_value()); Ok(Some(header_map)) } fn finalize(&self) -> Result { Ok(Bytes::copy_from_slice( &self.hasher.clone().finalize().to_be_bytes(), )) } // Size of the checksum in bytes fn size() -> u64 { 4 } fn header_name() -> HeaderName { CRC_32_HEADER_NAME } fn header_value(&self) -> HeaderValue { // We clone the hasher because `Hasher::finalize` consumes `self` let hash = self.hasher.clone().finalize(); HeaderValue::from_str(&base64::encode(u32::to_be_bytes(hash))) .expect(\"will always produce a valid header value from a CRC32 checksum\") }\n} impl Checksum for Crc32 { fn update( &mut self, bytes: &[u8], ) -> Result<(), Box<(dyn std::error::Error + Send + Sync + 'static)>> { Self::update(self, bytes) } fn headers( &self, ) -> Result, Box<(dyn std::error::Error + Send + Sync + 'static)>> { Self::headers(self) } fn header_name(&self) -> HeaderName { Self::header_name() } fn finalize(&self) -> Result { Self::finalize(self) } fn size(&self) -> u64 { Self::size() }\n} #[derive(Debug, Default)]\nstruct Crc32c { state: Option,\n} impl Crc32c { fn update(&mut self, bytes: &[u8]) -> Result<(), BoxError> { self.state = match self.state { Some(crc) => Some(crc32c::crc32c_append(crc, bytes)), None => Some(crc32c::crc32c(bytes)), }; Ok(()) } fn headers(&self) -> Result>, BoxError> { let mut header_map = HeaderMap::new(); header_map.insert(Self::header_name(), self.header_value()); Ok(Some(header_map)) } fn finalize(&self) -> Result { Ok(Bytes::copy_from_slice( &self.state.unwrap_or_default().to_be_bytes(), )) } // Size of the checksum in bytes fn size() -> u64 { 4 } fn header_name() -> HeaderName { CRC_32_C_HEADER_NAME } fn header_value(&self) -> HeaderValue { // If no data was provided to this callback and no CRC was ever calculated, return zero as the checksum. let hash = self.state.unwrap_or_default(); HeaderValue::from_str(&base64::encode(u32::to_be_bytes(hash))) .expect(\"will always produce a valid header value from a CRC32C checksum\") }\n} impl Checksum for Crc32c { fn update( &mut self, bytes: &[u8], ) -> Result<(), Box<(dyn std::error::Error + Send + Sync + 'static)>> { Self::update(self, bytes) } fn headers( &self, ) -> Result, Box<(dyn std::error::Error + Send + Sync + 'static)>> { Self::headers(self) } fn header_name(&self) -> HeaderName { Self::header_name() } fn finalize(&self) -> Result { Self::finalize(self) } fn size(&self) -> u64 { Self::size() }\n} #[derive(Debug, Default)]\nstruct Sha1 { hasher: sha1::Sha1,\n} impl Sha1 { fn update(&mut self, bytes: &[u8]) -> Result<(), BoxError> { self.hasher.write_all(bytes)?; Ok(()) } fn headers(&self) -> Result>, BoxError> { let mut header_map = HeaderMap::new(); header_map.insert(Self::header_name(), self.header_value()); Ok(Some(header_map)) } fn finalize(&self) -> Result { Ok(Bytes::copy_from_slice( self.hasher.clone().finalize().as_slice(), )) } // Size of the checksum in bytes fn size() -> u64 { 20 } fn header_name() -> HeaderName { SHA_1_HEADER_NAME } fn header_value(&self) -> HeaderValue { // We clone the hasher because `Hasher::finalize` consumes `self` let hash = self.hasher.clone().finalize(); HeaderValue::from_str(&base64::encode(&hash[..])) .expect(\"will always produce a valid header value from a SHA-1 checksum\") }\n} impl Checksum for Sha1 { fn update( &mut self, bytes: &[u8], ) -> Result<(), Box<(dyn std::error::Error + Send + Sync + 'static)>> { Self::update(self, bytes) } fn headers( &self, ) -> Result
+Status: RFC +Applies to: client and server +
Status: RFC
Applies to: client and server
For a summarized list of proposed changes, see the Changes Checklist section.
Historically, the smithy-rs and AWS SDK for Rust's changelogs and release notes have been +generated from the changelogger tool in tools/ci-build/changelogger. This is a tool built +specifically for development and release of smithy-rs, and it requires developers to add +changelog entries to a root CHANGELOG.next.toml file. Upon release, the [[smithy-rs]] entries +in this file go into the smithy-rs release notes, and the [[aws-sdk-rust]] entries are associated +with a smithy-rs release commit hash, and added to the aws/SDK_CHANGELOG.next.json for +incorporation into the AWS SDK's changelog when it releases.
changelogger
tools/ci-build/changelogger
CHANGELOG.next.toml
[[smithy-rs]]
[[aws-sdk-rust]]
aws/SDK_CHANGELOG.next.json
This system has gotten us far, but it has always made merging PRs into main more difficult +since the central CHANGELOG.next.toml file is almost always a merge conflict for two PRs +with changelog entries.
This RFC proposes a new approach to change logging that will remedy the merge conflict issue, +and explains how this can be done without disrupting the current release process.
There will be a changelog/ directory in the smithy-rs root where +developers can add changelog entry Markdown files. Any file name can be picked +for these entries. Suggestions are the development branch name for the +change, or the PR number.
changelog/
The changelog entry format will change to make it easier to duplicate entries +across both smithy-rs and aws-sdk-rust, a common use-case.
This new format will make use of Markdown front matter in the YAML format. +This change in format has a couple benefits:
While it would be preferable to use TOML for the front matter (and there are libraries +that support that), it will use YAML so that GitHub's Markdown renderer will recognize it.
A changelog entry file will look as follows:
--- +# Adding `aws-sdk-rust` here duplicates this entry into the SDK changelog. +applies_to: ["client", "server", "aws-sdk-rust"] +authors: ["author1", "author2"] +references: ["smithy-rs#1234", "aws-sdk-rust#1234"] +# The previous `meta` section is broken up into its constituents: +breaking: false +# This replaces "tada": +new_feature: false +bug_fix: false +--- + +Some message for the change. +
When a release is performed, the release script will generate the release notes, +update the CHANGELOG.md file, copy SDK changelog entries into the SDK, +and delete all the files in changelog/.
CHANGELOG.md
The SDK changelog entries currently end up in aws/SDK_CHANGELOG.next.json, and each entry +is given age and since_commit entries. The age is a number that starts at zero, and gets +incremented with every smithy-rs release. When it reaches a hardcoded threshold, that entry +is removed from aws/SDK_CHANGELOG.next.json. The SDK release process uses the since_commit +to determine which changelog entries go into the next SDK release's changelog.
age
since_commit
The SDK release process doesn't write back to smithy-rs, and history has shown that it +can't since this leads to all sorts of release issues as PRs get merged into smithy-rs +while the release is in progress. Thus, this age/since_commit dichotomy needs to +stay in place.
The aws/SDK_CHANGELOG.next.json will stay in place in its current format without changes. +Its JSON format is capable of escaping characters in the message string, so it will be +compatible with the transition from TOML to Markdown with YAML front matter.
The SDK_CHANGELOG.next.json file has had merge conflicts in the past, but this only +happened when the release process wasn't followed correctly. If we're consistent with +our release process, it should never have conflicts.
SDK_CHANGELOG.next.json
Implementation will be tricky since it needs to be done without disrupting the existing +release process. The biggest area of risk is the SDK sync job that generates individual +commits in the aws-sdk-rust repo for each commit in the smithy-rs release. Fortunately, +the changelogger is invoked a single time at the very end of that process, and only +the latest changelogger version that is included in the build image. Thus, we can safely +refactor the changelogger tool so long as the command-line interface for it remains +backwards compatible. (We could change the CLI interface as well, but it will +require synchronizing the smithy-rs changes with changes to the SDK release scripts.)
At a high level, these requirements must be observed to do this refactor safely:
changelogger render
After the initial migration, additional niceties could be added such as pulling authors +from git history rather than needing to explicitly state them (at least by default; there +should always be an option to override the author in case a maintainer adds a changelog +entry on behalf of a contributor).
changelogger split
sdk-lints
This is a collection of written resources for smithy-rs and SDK contributors.