-
Notifications
You must be signed in to change notification settings - Fork 172
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
http POST support #499
http POST support #499
Conversation
…nt (n0-computer#317) use store exported path in iroh-one closes #255, closes #309
* feat(gateway): fetch a DAG recursively as CAR. * test(gateway): add test for recursive car fetch also fixes clippy and code style issues * refactor(resolver): use mapper in recursive resolve * style(resolver): fix comment * style(resolver): clippy fix * style(gateway): clippy fix and test fix
* fix(unixfs): ensure links get persisted in store This had to be merged with some other changes related to the size info. Introduce a Block struct that has data, hash and links for DRY. * test(unixfs): validate blocks in all roundtrip tests Validate blocks in all roundtrip tests to make sure that the blocks that are returned from file.encode or dir.encode are internally consistent. * fix(store): only create new id when needed The old code was creating new ids even if we already knew the cid, which caused some havoc.
This allows adding large files without getting an error. It is a stopgap until we have a persistent kad store.
## move RPC client construction into `iroh` (read: `iroh-api`) I've moved creation of the RpcClient away from the CLI into `iroh` (to be `iroh-api`). This means that the API gains a bunch of dependencies and the CLI loses them. Doing this made me realize that the api should own the rpc client, so changed from a reference (with a lifetime) to ownership. ## `iroh get` start of implementation Start of implementation of `iroh get` with a few mocked CLI tests ## `iroh` -> `iroh-api` crate The plan is to have an `iroh` crate that contains the CLI and an `iroh-api` crate that contains the Rust API. Here we've done half of that renaming: `iroh` is renamed to `iroh-api`. I haven't done the second half, renaming `iroh-ctl` to `iroh`, as that would make this commit too different to read.
* Rename the iroh-ctl crate to the iroh crate * test: test --version flag does what it should now
Acknowledges that a `raw` node is a valid `UnixfsNode` and therefore can be resolved as a file in the gateway
- implements rabin based chunking (following kubo & dagger) -expose chunker selection on the api & cli - improve the builder api for files
crates.io release prep
fixes for issues found during the 0.1.2 release
4ee55b4
to
8469b5e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed this mostly to keep the conversation going.
@b5 what's our roadmap/product stance on the writable gateway story?
// If this gateway is not writable, return a 400 error. | ||
if !state.config.writeable_gateway() { | ||
return Err(GatewayError::new( | ||
StatusCode::BAD_REQUEST, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of 400 Bad Request
we should do 405 Method Not Allowed
#[tracing::instrument(skip(state))] | ||
pub async fn post_handler<T: ContentLoader + std::marker::Unpin>( | ||
Extension(state): Extension<Arc<State<T>>>, | ||
// Path(params): Path<HashMap<String, String>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's drop unused code.
)); | ||
} | ||
|
||
// TODO: check path & headers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should check for valid scheme, all the headers. We should also check for bad_bits
in the denylist, but given the logistics we would probably first need to add it and then based on the CID respond and remove it if its in the list.
&self, | ||
_content: T, | ||
) -> Result<cid::Cid, anyhow::Error> { | ||
unimplemented!() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still unimplemented. Should we allow this?
On a separate note, feels wrong to be placed in the content loader. Unsure if the content loader is evolving to be more (and whether it should) or if we should move this out and have it be handled by the gateway client and not the resolver (my preference).
@@ -168,6 +170,8 @@ pub struct File { | |||
chunker: Chunker, | |||
} | |||
|
|||
unsafe impl Send for File {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not thrilled about unsafe code. @dignifiedquire what's our general policy on that front?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is not safe to do. Each piece of the struct needs to be made Send
@@ -35,6 +35,8 @@ pub enum ChunkerStream<'a> { | |||
Rabin(LocalBoxStream<'a, io::Result<Bytes>>), | |||
} | |||
|
|||
unsafe impl<'a> Send for ChunkerStream<'a> {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is not safe to do. The streams need to change to BoxStream
to make this work
Path(PathBuf), | ||
} | ||
|
||
unsafe impl Send for Content {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should not be needed, otherwise something is going wrong
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None of the unsafe
usages are actually safe to use, these need reworking
@dignifiedquire I'm not surprised the unsafe parts need to be re-done, it was mostly "compiler error" based implementation. I'm not convinced by the overall design anyway. Like @Arqu comments in https://github.com/n0-computer/iroh/pull/499/files#r1035765976 we should settle on that question first. |
@Arqu I could get some help with something in the http handler: the new
put_handler
itself compiles fine but anytime I use the unixfs builder in that function (uncommenting any of thelet file = create_file_from_xxx
line) I get a trait bound error from the route setup that I don't understand:Thanks!