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

ipfsconn/ipfshttp: handle cid args passed in url path correctly #392

Merged
merged 2 commits into from May 1, 2018

Conversation

lanzafame
Copy link
Contributor

@lanzafame lanzafame commented Apr 25, 2018

The extractCid function was added to enable the extraction of
a cid argument from either the url path or query string.
This puts the proxy behaviour on par with the current IPFS API.
The function does rely on the fact that ipfs-cluster doesn't
intercept any command that has more than one subcommand.
If that changes, this function will have to be updated.

License: MIT
Signed-off-by: Adrian Lanzafame adrianlanzafame92@gmail.com

@lanzafame lanzafame requested a review from hsanjuan April 25, 2018 03:01
@ghost ghost assigned lanzafame Apr 25, 2018
@ghost ghost added the status/in-progress In progress label Apr 25, 2018
Copy link
Collaborator

@hsanjuan hsanjuan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests fail. I am not sure that the handle is selecting the right thing from ipfs.handlers anymore. We might have to make more clever route matching..


// extractCid extracts the cid argument from a url.URL, either via
// the query string parameters or from the url path itself.
func extractCid(u *url.URL) (string, bool) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rename to extractArgument, since the argument doesn't have to be a Cid in all cases (even if now it's always one).


if len(segs) > 2 {
return segs[len(segs)-1], true
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'm starting to get what you were saying yesterday..

In general, we have things like:

pin/ls/<arg>

cat/<arg>

but from here we have no way of distinguishing which commands are valid in order to know what part of the url is the argument.

Let's print a warning "You are using an undocumented form of the IPFS API. Consider passing your command arguments with the '?arg=' query parameter".

For the moment it works like this I guess...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, and after our conversation, I had another look at https://github.com/ipfs/go-ipfs-cmds/blob/master/http/parse.go#L42 and realised that it has access to all the possible subcommands and hence why it is able to distinguish between commands and arguments.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll we do know which subcommands we are handling, so that's our list if we want to be strict.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's print a warning "You are using an undocumented form of the IPFS API. Consider passing your command arguments with the '?arg=' query parameter".

@hsanjuan should I be returning that in the json response, as it is the client that needs to change?

Also, the way that we have the IPFS-Cluster api documented in the README suggests that pin/ls/<arg> is the more appropriate way to interact with the api, so that should probably get changed as well.

Copy link
Collaborator

@hsanjuan hsanjuan Apr 27, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hsanjuan should I be returning that in the json response, as it is the client that needs to change?

No, just spam the logs

/pin/ls/<arg> that refers to the cluster API.

This is different from the IPFS API.

@lanzafame lanzafame assigned lanzafame and unassigned lanzafame Apr 29, 2018
@lanzafame lanzafame force-pushed the fix/ipfsconn/api-compat branch 4 times, most recently from e6f0d58 to d596361 Compare April 30, 2018 00:55
ipfsErrorResponder(w, "Error: bad argument")
return
}
arg := argA[0]
_, err := cid.Decode(arg)
if err != nil {
ipfsErrorResponder(w, "Error parsing CID: "+err.Error())
Copy link
Contributor Author

@lanzafame lanzafame Apr 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hsanjuan So for some reason, the tests that attempt to pin/unpin a bad cid are failing on travis/jenkins (they aren't failing locally and I have tried on two separate computers/OSes). It would appear that on travis/jenkins, this cid.Decode operation is returning an error when passed the test.ErrorCid. Or the extractArgument function is failing...

@lanzafame
Copy link
Contributor Author

@hsanjuan so I haven't gotten to the bottom of this but it appears to be due to travis/jenkins running go1.9 whereas I have been deving with go1.10.1, just trying to figure out which part of is to blame.

@coveralls
Copy link

coveralls commented Apr 30, 2018

Coverage Status

Coverage increased (+0.1%) to 67.44% when pulling b50a05f on fix/ipfsconn/api-compat into dbcc5c2 on master.

The extractCid function was added to enable the extraction of
a cid argument from either the url path or query string.
This puts the proxy behaviour on par with the current IPFS API.
The function does rely on the fact that ipfs-cluster doesn't
intercept any command that has more than one subcommand.
If that changes, this function will have to be updated.

License: MIT
Signed-off-by: Adrian Lanzafame <adrianlanzafame92@gmail.com>
query args correctly, requiring both a trailing slash and
non-trailing slash handle pattern to be defined for the
pin and unpin handlers.

License: MIT
Signed-off-by: Adrian Lanzafame <adrianlanzafame92@gmail.com>
@hsanjuan
Copy link
Collaborator

@lanzafame this is ready on your side right?

@hsanjuan hsanjuan added the RFM Ready for Merge label Apr 30, 2018
@lanzafame
Copy link
Contributor Author

lanzafame commented Apr 30, 2018 via email

@lanzafame
Copy link
Contributor Author

lanzafame commented Apr 30, 2018 via email

@lanzafame
Copy link
Contributor Author

@hsanjuan Sorry, this PR is fine regarding commits. I was thinking of the pintracker revamp PR.
This one is good to go.

@hsanjuan hsanjuan merged commit b01ac8f into master May 1, 2018
@ghost ghost removed the status/in-progress In progress label May 1, 2018
@hsanjuan hsanjuan deleted the fix/ipfsconn/api-compat branch May 1, 2018 08:37
@hsanjuan
Copy link
Collaborator

hsanjuan commented May 1, 2018

Hehe yeah I was thinking so :)

@hsanjuan hsanjuan mentioned this pull request May 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFM Ready for Merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants