Reading Extensions value from Response wrapper

[declanvk]

Describe the feature

I would like to be able to access the extension field of the Response wrapper.

The issue is that in an interceptor hook, I cannot use the try_into_http02x method because it requires an owned value and the context will only return a shared reference to the Response. Additionally, Response does not implement clone, so I wouldn't be able to response.clone().try_into_http02x().

Use Case

I need this access so that I can read information like the HttpInfo as part of an Intercept implementation that uses the read_after_attempt hook.

Proposed Solution

I realize that directly exposing the http::Extension doesn't make sense for a wrapper type where you are attempting to hide the http dependency.

Other options might be:

• Implement Clone for the Response wrapper in a way that preserves the extensions value
• Implement your own Extensions type that is compatible with http's and then expose that type in a public interface

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

A note for the community

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue, please leave a comment

[jdisanti]

What problem are you trying to solve with the extensions? Maybe there's an alternative we can propose.

[rcoh]

We actually capture http_info in a generic way (and we use this internally).

We write CaptureSmithyConnection into the property bag:

aws-sdk-rust/sdk/aws-smithy-runtime/src/client/http/connection_poisoning.rs

Line 76 in 51f987b

let captured_connection = cfg.load::<CaptureSmithyConnection>().cloned();

ConnectionMetadata currently only exposes a narrow amount of information, but we could consider exposing more fields of HttpInfo

[declanvk]

What problem are you trying to solve with the extensions? Maybe there's an alternative we can propose.

Mostly I need the HttpInfo data so that I can attempt to uniquely identify the TCP connection (using local + remote addr + port). I'd also like to have the remote addr information generally so that I can record number of unique hosts that I'm connecting to.

---

We actually capture http_info in a generic way (and we use this internally).

Thanks for the example! Apply that to my own case, would I also need to write a new CaptureSmithyConnection to both the request extensions and the interceptor cfg? Like in

aws-sdk-rust/sdk/aws-smithy-runtime/src/client/http/connection_poisoning.rs

Lines 57 to 61 in 51f987b

	let capture_smithy_connection = CaptureSmithyConnection::new();
	context
	.request_mut()
	.add_extension(capture_smithy_connection.clone());
	cfg.interceptor_state().store_put(capture_smithy_connection);

Or can I assume (with some tests) that a built-in smithy Intercept implementation will write this to the configuration for me?

If yes, then I would only need the local_addr information recorded into the ConnectionMetadata struct. Around

aws-sdk-rust/sdk/aws-smithy-runtime/src/client/http/hyper_014.rs

Lines 325 to 332 in 51f987b

	let smithy_connection = ConnectionMetadata::new(
	conn.is_proxied(),
	http_info.map(|info| info.remote_addr()),
	move || match capture_conn.connection_metadata().as_ref() {
	Some(conn) => conn.poison(),
	None => tracing::trace!("no connection existed to poison"),
	},
	);

would need to pull out the local_addr from the HttpInfo.

[declanvk]

I do think that you might still want to implement Clone for Response, otherwise the try_into_http02x will not be useful for any Intercept hooks. Maybe something similar to the Request::try_clone and keep the warning on it that says that it will clear the extensions field?

It wouldn't be useful for my case, but it might make the interface more flexible for someone else.

[jdisanti]

@declanvk contributed a change to smithy-rs that will solve their problem in smithy-lang/smithy-rs#3286

Accessing http extensions is not something we would like to support unless there is a very compelling reason for it, so I'm going to close this for now.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.