Add SSZ to PBS #372
Add SSZ to PBS #372
Conversation
|
|
||
| /// Parse CONSENSUS_VERSION header | ||
| pub fn get_consensus_version_header(req_headers: &HeaderMap) -> Option<ForkName> { | ||
| ForkName::from_str( |
There was a problem hiding this comment.
woth double checking this is not case sensitive
There was a problem hiding this comment.
just realized we have our own ForkName, we could also import it from lighthouse
There was a problem hiding this comment.
For case sensitivity, it's defined the way the spec defines it (https://github.com/ethereum/beacon-APIs/blob/672e03e25ace85a3bacaea553fbf374f4f844435/apis/beacon/blocks/blocks.yaml#L21) but Rust will convert everything to lower case regardless.
For ForkName, done in 86fa858.
crates/common/src/utils.rs
Outdated
| } | ||
| } | ||
|
|
||
| impl FromStr for Accept { |
There was a problem hiding this comment.
would it be easier to use crate for this for easier maintainability? eg https://github.com/bltavares/axum-content-negotiation or https://docs.rs/headers-accept/latest/headers_accept/
crates/common/src/utils.rs
Outdated
|
|
||
| #[must_use] | ||
| #[derive(Debug, Clone, Copy, Default)] | ||
| pub struct JsonOrSsz<T>(pub T); |
There was a problem hiding this comment.
thinking about what we'll have to do with: #326, i 'd rather just do this in a function and use a simple "Bytes" extractor on the axum body. Can just pass headers and body and get back T
There was a problem hiding this comment.
Ok, refactored a bunch of the setup in e7335f6 to provide exactly this.
crates/pbs/src/routes/get_header.rs
Outdated
|
|
||
| BEACON_NODE_STATUS.with_label_values(&["200", GET_HEADER_ENDPOINT_TAG]).inc(); | ||
| Ok((StatusCode::OK, axum::Json(max_bid)).into_response()) | ||
| let response = match accept_header { |
There was a problem hiding this comment.
here we just asssume the relay just support both? probably fine but ok double checking
There was a problem hiding this comment.
We do, if we want to add support for relays that only allow JSON for example, we'll have to probably figure that out on startup and flag them accordingly so we don't ping them to negotiate encoding with every request (assuming they never change it down the line). Do we have stats on how many support SSZ and how many don't?
This is a modernization of #252 since that's been dormant for a while, but was re-raised in #364. Just about everything was ported over cleanly.