## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
Because the build pipeline is checking for these.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Extracted from #3308, this adds doc example scraping. This won't make
much of a difference yet but it will help if we're able to move example
repos directly under the SDKs themselves when appropriate.
## Description
https://doc.rust-lang.org/rustdoc/scraped-examples.html
## Testing
verified that examples appear in docs when expected
## Checklist
no changelog
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Showcase how to pass TLS derived information to server operation
handlers, like the certificate chain presented by the client.
To test, run `RUST_LOG=pokemon_service_tls=DEBUG cargo run` and `curl -v
--insecure https://localhost:13734/do-nothing`. Alternatively, run the
tests using `RUST_LOG=pokemon_service_tls=DEBUG cargo test`, which have
been updated to hit the operation that logs the TLS connection derived
information.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: ysaito1001 <awsaito@amazon.com>
Fix broken links as a result of repo movement
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Without this, we will have http = 0.2 permanently in-tree.
## Description
- Add feature gate for http 02x.
- ~Add http 1x as an experiment.~
## Testing
CI
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
For the same reason that the request wrapper types were created in
#3059, this PR establishes the response wrapper types and refactors
existing code to use them.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This PR fixes issues introduced by moving the repository from
awslabs/smithy-rs to smithy-lang/smithy-rs.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
PR #3095 added a code-generated `${serviceName}Config` object on which
users can register layers and plugins. For example:
```rust
let config = PokemonServiceConfig::builder()
.layer(layers)
.http_plugin(authn_plugin)
.model_plugin(authz_plugin)
.build();
```
This PR makes it so that server decorators can inject methods on this
config builder object. These methods can apply arbitrary layers, HTTP
plugins, and/or model plugins. Moreover, the decorator can configure
whether invoking such method is required or not.
For example, a decorator can inject an `aws_auth` method that configures
some plugins using its input arguments. Missing invocation of this
method
will result in the config failing to build:
```rust
let _: SimpleServiceConfig<
// No layers have been applied.
tower::layer::util::Identity,
// One HTTP plugin has been applied.
PluginStack<IdentityPlugin, IdentityPlugin>,
// One model plugin has been applied.
PluginStack<IdentityPlugin, IdentityPlugin>,
> = SimpleServiceConfig::builder()
// This method has been injected in the config builder!
.aws_auth("a".repeat(69).to_owned(), 69)
// The method will apply one HTTP plugin and one model plugin,
// configuring them with the input arguments. Configuration can be
// declared to be fallible, in which case we get a `Result` we unwrap
// here.
.expect("failed to configure aws_auth")
.build()
// Since `aws_auth` has been marked as required, if the user misses
// invoking it, this would panic here.
.unwrap();
```
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This is a pared-down version of #2809.
This is the code-generated version of the
david-perez/smithy-rs-service-config#2 POC.
This introduces a code-generated `PokemonServiceConfig` object which is
provided to the service builder constructor via
`PokemonService::builder(config: PokemonServiceConfig)`. This will
displace the
current `builder_without_plugins` and `builder_with_plugins`,
deprecating them.
We will eventually remove them.
The motivation is to have a single place where to register plugins and
layers.
Smithy traits can leverage this object to inject methods that can apply
plugins
and layers. For example, an `@authorization` trait implementer could
vend a
smithy-rs decorator that pre-applied an authorization plugin inside the
`${serviceName}Config` object, possibly exposing a method to pass in any
runtime arguments needed to configure the middleware.
## Checklist
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Implements https://github.com/awslabs/smithy-rs/issues/3033
## Description
This PR hides behind cargo features the third-party types from
`http-body` and `hyper` crates that are used in`aws-smithy-types`'
public API. Customers need to opt-in by enabling a cargo feature
`http-body-0-4-x` in `aws-smithy-types` to create an `SdkBody` or
`ByteStream` using those third-party types. For more details, please see
[the upgrade
guide](https://github.com/awslabs/smithy-rs/discussions/3089).
As can been seen from code changes, to reduce the surface area where we
need to feature-gate things, we have fused the
`aws_smithy_types::body::Inner::Streaming` enum variant into
`aws_smithy_types::body::Inner::Dyn` variant, thereby removing
`SdkBody::from_dyn`.
## Testing
Relied on existing tests in CI
## Checklist
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Zelda Hessler <zhessler@amazon.com>
## Motivation and Context
Completes #3054 (a follow-up on #3032)
## Description
#3032 moved `BuildError` from `aws_smithy_http::operation::error` to
`aws_smithy_types::error::operation`. That PR also left "breadcrumbs",
so that customers could still consume `BuldError` from `aws_smithy_http`
after the move.
This PR turns breadcrumbs into deprecation messages (via
`#[deprecated(...)]`) and updates existing places that used to use moved
types from `aws_smithy_http` to `aws_smithy_types`.
## Testing
Relied on tests in CI.
## Checklist
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Russell Cohen <rcoh@amazon.com>
Agnostic in that it's generic over the operation it's applied to.
Figuring out how to write such a plugin can be fun but is not trivial.
I'm mostly adding this as a reference to refresh my memory the next time
I have to implement one of these.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
The current module location is misleading, since you never want to run
the layer as a plugin: plugins always run after routing, and the health
check should be enacted before routing. Examples have been corrected,
and a test has been added.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
So far, servers have tacitly worked with the notion that plugins come in
two flavors: "HTTP plugins" and "model plugins":
- A HTTP plugin acts on the HTTP request before it is deserialized, and
acts on the HTTP response after it is serialized.
- A model plugin acts on the modeled operation input after it is
deserialized, and acts on the modeled operation output or the modeled
operation error before it is serialized.
However, this notion was never reified in the type system. Thus, users
who pass in a model plugin where a HTTP plugin is expected or
viceversa in several APIs:
```rust
let pipeline = PluginPipeline::new().push(http_plugin).push(model_plugin);
let app = SimpleService::builder_with_plugins(http_plugins, IdentityPlugin)
.post_operation(handler)
/* ... */
.build()
.unwrap();
```
would get the typical Tower service compilation errors, which can get
very confusing:
```
error[E0631]: type mismatch in function arguments
--> simple/rust-server-codegen/src/main.rs:47:6
|
15 | fn new_svc<S, Ext>(inner: S) -> model_plugin::PostOperationService<S, Ext> {
| -------------------------------------------------------------------------- found signature defined here
...
47 | .post_operation(post_operation)
| ^^^^^^^^^^^^^^ expected due to this
|
= note: expected function signature `fn(Upgrade<RestJson1, (PostOperationInput, _), PostOperationService<aws_smithy_http_server::operation::IntoService<simple::operation_shape::PostOperation, _>, _>>) -> _`
found function signature `fn(aws_smithy_http_server::operation::IntoService<simple::operation_shape::PostOperation, _>) -> _`
= note: required for `LayerFn<fn(aws_smithy_http_server::operation::IntoService<..., ...>) -> ... {new_svc::<..., ...>}>` to implement `Layer<Upgrade<RestJson1, (PostOperationInput, _), PostOperationService<aws_smithy_http_server::operation::IntoService<simple::operation_shape::PostOperation, _>, _>>>`
= note: the full type name has been written to '/local/home/davidpz/workplace/smithy-ws/src/SmithyRsSource/target/debug/deps/simple-6577f9f79749ceb9.long-type-4938700695428041031.txt'
```
This commit introduces the `HttpPlugin` and `ModelPlugin` marker traits,
allowing plugins to be marked as an HTTP plugin, a model plugin, or
both. It also removes the primary way of concatenating plugins,
`PluginPipeline`, in favor of `HttpPlugins` and `ModelPlugins`, which
eagerly check that whenever a plugin is `push`ed, it is of the expected
type. The generated service type in the server SDKs'
`builder_with_plugins` constructor now takes an `HttpPlugin` as its
first parameter, and a `ModelPlugin` as its second parameter.
I think this change perhaps goes counter to the generally accepted
wisdom that trait bounds in Rust should be enforced "at the latest
possible moment", that is, only when the behavior encoded in the trait
implementation is relied upon in the code (citation needed).
However, the result is that exposing the concepts of HTTP plugin and
model plugin in the type system makes for code that is easier to reason
about, and produces more helpful compiler error messages.
Documentation about the plugin system has been expanded, particularly on
how to implement model plugins.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Closes https://github.com/awslabs/smithy-rs/issues/1839
Currently, `Plugin` is parameterized by protocol and operation. To
improve symmetry, extensibility and uniformity we switch this to be
parameterized by service instead. The protocol can still be recovered
via the `type Protocol` associated type on `ServiceShape`.
## Description
- Add `ServiceShape` trait, encoding the properties of a Smithy service.
- Change `Plugin<Protocol, Operation, S>` to `Plugin<Service, Operation,
S>`.
- Add `FilterByOperation` and `filter_by_operation` `Plugin`s.
## Motivation and Context
This PR upgrades the MSRV to 1.68.2.
## Checklist
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: Zelda Hessler <zhessler@amazon.com>
Co-authored-by: 82marbag <69267416+82marbag@users.noreply.github.com>
Also, sort `Cargo.toml` dependencies if they were disordered.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
See https://github.com/awslabs/smithy-rs/issues/2634
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
Co-authored-by: Harry Barber <106155934+hlbarber@users.noreply.github.com>
## Motivation and Context
15th operation was being dropped when iterator was being read into a
TinyMap
## Description
The 15th operation was being dropped when the if statement was caught
because the operation had been popped of the iterator but hadn't been
added to the vec of operations before the two iterators were being
chained and collected into a
## Testing
Added unit tests that reproduced the issue and verified that the issue
is fixed
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: david-perez <d@vidp.dev>
Co-authored-by: Fahad Zubair <fahadzubair@gmail.com>
This reverts https://github.com/awslabs/smithy-rs/pull/2678.
It is a breaking change and it will be included in the next release.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
See https://github.com/awslabs/smithy-rs/issues/2634
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
This reverts commit 04db5e3572.
This is a breaking change that needs to wait to be merged in until the
next breaking release.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This patch also removes the unneeded dependency on `lambda_runtime` by
`aws-smithy-http-server-python`.
This patch also refactors `LambdaHandler`'s `convert_event` to avoid
cloning the URI path when not needed.
This is a breaking change. See #2676 why.
This patch also bumps `aws-smithy-http-server` dependency on `mime` to
0.3.4.
`cargo +nightly-2022-11-16 minimal-versions check --all-features`
otherwise
fails when using 0.3.0, because we require `impl fmt::Display for
mime::FromStrError`, which was first introduced in 0.3.4.
As to why `minimal-versions` is now picking `mime` 0.3.0 with this
patch, it's
because in `lambda_http` 0.7.3, they had [`mime =
"0.3.16"`](99dba64472/lambda-http/Cargo.toml (L35-L35)),
and in `lambda_http` 0.8.0, they've now relaxed that to [`mime =
"0.3"`](393d6447be/lambda-http/Cargo.toml (L36)).
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
See #2676.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Description
Do not parse and initialize the mime, known at compile time, on every
request.
See
https://github.com/awslabs/smithy-rs/pull/2607#discussion_r1172607704
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the AWS
SDK, generated SDK code, or SDK runtime crates
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
## Motivation and Context
Services often need the ability to report health status via health
checks (see [ALB Health
Checks](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html)).
This PR adds a simple layer that allows configuring your service to
respond to these health check requests.
## Description
Adds `AlbHealthCheckLayer`, and `AlbHealthCheckService`.
## Testing
Added this layer to the `pokemon-service` binary, and added an
integration test for it.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
These functions were mistakenly deprecated when deprecating the old
service builder API in #1886.
However, they're fine, and they're internally used by the generated
server SDKs.
The module they reside in is `#[doc(hidden)]`.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This commit logs server request rejections at the `DEBUG` level in an
operation's `FromRequest` implementation.
This commit is analogous to the one in PR #2524 for response rejections.
However, request rejections are _not_ errors, so they shouldn't be
logged at the `ERROR` level. Indeed, they happen every time the server
rejects a malformed request.
Prior to this commit, the `RuntimeError::NotAcceptable` variant was the
only `RuntimeError` variant that was manually constructed. This commit
makes it so that it now results from a conversion from a new
`RequestRejection::NotAcceptable` variant.
We now leverage `futures_util::future::TryFutureExt::map` to map a
future
that uses `RequestRejection` as its error into a future that uses
`RuntimeError`, and centrally log the rejection there. `futures_util` is
already a transitive dependency of server SDKs (via e.g. `hyper` and
`tower`), so adding it is a direct dependency is not worse.
This helps with #2521.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Rejection types used to be loose, but now that they are
protocol-specific (see #2517), they can be tightened up to be more
useful.
Where possible, variants now no longer take in the dynamic
`crate::Error`, instead taking in concrete error types arising from
particular fallible invocations in the generated SDKs.This makes it
easier to see how errors arise, and allows for more specific and helpful
error messages that can be logged.
We `#[derive(thiserror::Error)]` on rejection types to cut down on
boilerplate code.
This commit removes the dependency on `strum_macros`.
If the model only uses the `@http` trait to define the response code,
Smithy already checks that this is a valid status code, so the
conversion cannot fail, and we can avoid rejecting with
`ResponseRejection::InvalidHttpStatusCode`.
This commit also removes this variant from RPC protocols, where HTTP
binding traits are not allowed, and so this failure mode can never
happen.
* Add request ID to response headers
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Add parsing test
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Style
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* CHANGELOG
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Fix import
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Panic if ServerRequestIdProviderLayer is not present
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Own value
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Correct docs
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Add order of layer to expect() message
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Remove Box
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Require order of request ID layers
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Revert "Require order of request ID layers"
This reverts commit 147eef26d5f8972b810dc5994e57865a872e44b0.
* One layer to generate and inject the header
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* HeaderName for header name
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* CHANGELOG
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Remove additional layer
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Remove to_owned
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Add tests, remove unnecessary clone
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* take() ResponsePackage instead
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Update docs
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Update docs
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* cargo fmt
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
* Update CHANGELOG
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
---------
Signed-off-by: Daniele Ahmed <ahmeddan@amazon.de>
Co-authored-by: Daniele Ahmed <ahmeddan@amazon.de>
* Add generic parameter to the handler setter
* Constrain Pl::Service in Upgrade rather than S
---------
Co-authored-by: Matteo Bigoi <1781140+crisidev@users.noreply.github.com>
Zelda Hessler