Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for custom request and response labels #25

Open
chris-wood opened this issue Aug 4, 2022 · 2 comments
Open

Add support for custom request and response labels #25

chris-wood opened this issue Aug 4, 2022 · 2 comments

Comments

@chris-wood
Copy link
Contributor

For folks that want to reuse the encapsulation format it would be useful to be able to compile this crate with custom request and response labels. Right now, the crate mandates BHTTP as the underlying content. As a proof-of-concept, I implemented a protobuf-based encoding for HTTP messages and plumbed it into this crate in this change. It's not great... I basically want the equivalent of compile-time strings, but I don't know the best way to do that in Rust.

@martinthomson
Copy link
Owner

martinthomson commented Aug 5, 2022

So the way to do this is to define a new trait on which you have a const, call it const INFO_BASE: &str. You implement that trait for OHTTP as follows:

pub trait InfoStr {
  const BASE: &'static str;
}
pub struct Bhttp();
impl InfoStr for Bhttp {
  const BASE: &'static str = "message/bhttp"
}

Then you make all of the implementation pieces generic over T: InfoStr.

The usage turns from new Client(...) to new Client<Bhttp>, which isn't a big change. The performance cost is manageable (I think that concatenating &'static str instances can be done by the compiler), so there is only a tiny compile time cost involved for monomorphism and no runtime cost.

Caveat: I haven't tested any of this by writing it. If you want to give it a spin, I am happy to review. Otherwise, I'll probably try this out at some later time.

@chris-wood
Copy link
Contributor Author

Thanks @martinthomson. This sounds like a reasonable approach to me. If I get some time, I'll give it a shot.

agokarn added a commit to microsoft/ohttp that referenced this issue Oct 29, 2024
* Change to new KMS endpoitn

Error handling

	modified:   Makefile
	modified:   bhttp/Cargo.toml
	modified:   bhttp/src/err.rs
	modified:   bhttp/src/lib.rs
	modified:   bhttp/src/rw.rs
	modified:   ohttp-client/src/main.rs
	modified:   ohttp-server/src/main.rs
	modified:   ohttp/src/config.rs
	modified:   ohttp/src/err.rs
	modified:   ohttp/src/lib.rs
	modified:   ohttp/src/nss/aead.rs
	modified:   ohttp/src/nss/hpke.rs
	modified:   ohttp/src/nss/p11.rs

Address PR comments

remove key logging

Add backtrace

Make more changes

* format changes

	modified:   bhttp/Cargo.toml
	modified:   bhttp/src/err.rs
	modified:   bhttp/src/lib.rs
	modified:   bhttp/src/rw.rs
	modified:   ohttp/Cargo.toml
	modified:   ohttp/src/config.rs
	modified:   ohttp/src/err.rs
	modified:   ohttp/src/lib.rs
	modified:   ohttp/src/nss/aead.rs
	modified:   ohttp/src/nss/hpke.rs
	modified:   ohttp/src/nss/p11.rs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants