- 01 Jun, 2015 2 commits
-
-
Jeromy authored
-
Juan Batiz-Benet authored
-
- 31 May, 2015 2 commits
- 28 May, 2015 2 commits
- 26 May, 2015 3 commits
-
-
rht authored
-
rht authored
Side effect: this makes 'tour' accessible through the HTTP API
-
David Dias authored
-
- 22 May, 2015 5 commits
-
-
Travis Person authored
Update the previous `invalid path` error to match the error returned from `SplitAbsPath`.
-
Travis Person authored
Cleaned the tests, and actually test for the error.
-
Travis Person authored
Added the original logic to check for a invalid path and a simple test.
-
Travis Person authored
If no path after `/ipfs/` or `/ipns/` is given, then the daemon will panic with a slice bounds out of range error. This checks to see if we have anything after `ipfs` or `ipns`.
-
Jeromy authored
-
- 21 May, 2015 4 commits
-
-
Jeromy authored
-
Knut Ahlers authored
-
Knut Ahlers authored
fixes #1234 fixes #1267
-
Jeromy authored
-
- 20 May, 2015 8 commits
-
-
Knut Ahlers authored
fixes #1233
-
Jeromy authored
-
W. Trevor King authored
So we can attach a mock lookup function for testing.
-
W. Trevor King authored
Previously we had a confusing situation, with: * single-arg doc: published name <name> to <value> * double-arg doc: published name <value> to <name> * implementation: Published name <name> to <value> Now we have the uniform: Published to <name>: <value> With the following goals: 1. It's clear that we're writing <value> to <name>'s IPNS slot in the DHT. 2. We preserve the order of arguments from the command-line invocation: $ ipfs name publish <name> <value> Published to <name>: <value>
-
W. Trevor King authored
And add a generic 'ipfs resolve' to handle cross-protocol name resolution.
-
W. Trevor King authored
This lets users resolve (recursively or not) DNS links without pulling in the other protocols. That makes an easier, more isolated target for alternative implemenations, since they don't need to understand IPNS, proquint, etc. to handle these resolutions.
-
W. Trevor King authored
For explicitly enabling recursive behaviour (it was previously always enabled). That allows folks who are interested in understanding layered indirection to step through the chain one link at a time.
-
W. Trevor King authored
This allows direct access to the earlier protocol-specific Resolve implementations. The guts of each protocol-specific resolver are in the internal resolveOnce method, and we've added a new: ResolveN(ctx, name, depth) method to the public interface. There's also: Resolve(ctx, name) which wraps ResolveN using DefaultDepthLimit. The extra API endpoint is intended to reduce the likelyhood of clients accidentally calling the more dangerous ResolveN with a nonsensically high or infinite depth. On IRC on 2015-05-17, Juan said: 15:34 <jbenet> If 90% of uses is the reduced API with no chance to screw it up, that's a huge win. 15:34 <wking> Why would those 90% not just set depth=0 or depth=1, depending on which they need? 15:34 <jbenet> Because people will start writing `r.Resolve(ctx, name, d)` where d is a variable. 15:35 <wking> And then accidentally set that variable to some huge number? 15:35 <jbenet> Grom experience, i've seen this happen _dozens_ of times. people screw trivial things up. 15:35 <wking> Why won't those same people be using ResolveN? 15:36 <jbenet> Because almost every example they see will tell them to use Resolve(), and they will mostly stay away from ResolveN. The per-prodocol versions also resolve recursively within their protocol. For example: DNSResolver.Resolve(ctx, "ipfs.io", 0) will recursively resolve DNS links until the referenced value is no longer a DNS link. I also renamed the multi-protocol ipfs NameSystem (defined in namesys/namesys.go) to 'mpns' (for Multi-Protocol Name System), because I wasn't clear on whether IPNS applied to the whole system or just to to the DHT-based system. The new name is unambiguously multi-protocol, which is good. It would be nice to have a distinct name for the DHT-based link system. Now that resolver output is always prefixed with a namespace and unprefixed mpns resolver input is interpreted as /ipfs/, core/corehttp/ipns_hostname.go can dispense with it's old manual /ipfs/ injection. Now that the Resolver interface handles recursion, we don't need the resolveRecurse helper in core/pathresolver.go. The pathresolver cleanup also called for an adjustment to FromSegments to more easily get slash-prefixed paths. Now that recursive resolution with the namesys/namesys.go composite resolver always gets you to an /ipfs/... path, there's no need for the /ipns/ special case in fuse/ipns/ipns_unix.go. Now that DNS links can be things other than /ipfs/ or DHT-link references (e.g. they could be /ipns/<domain-name> references) I've also loosened the ParsePath logic to only attempt multihash validation on IPFS paths. It checks to ensure that other paths have a known-protocol prefix, but otherwise leaves them alone. I also changed some key-stringification from .Pretty() to .String() following the potential deprecation mentioned in util/key.go.
-
- 18 May, 2015 3 commits
-
-
rht authored
-
Jeromy authored
-
Vijayee Kulkaa authored
-
- 12 May, 2015 1 commit
-
-
Tim Groeneveld authored
-
- 10 May, 2015 3 commits
-
-
Henry authored
-
Juan Batiz-Benet authored
This commit allows arbitrary json input to set. It also tests this with sharness.
-
Henry authored
some golinting along the way
-
- 09 May, 2015 4 commits
- 08 May, 2015 1 commit
-
-
Henry authored
commands/object: remove objectData() and objectLinks() helpers resolver: added context parameters sharness: $HASH carried the \r from the http protocol with sharness: write curl output to individual files http gw: break PUT handler until PR#1191
-
- 04 May, 2015 1 commit
-
-
Jeromy authored
-
- 02 May, 2015 1 commit
-
-
W. Trevor King authored
Currently garbage collection is triggered manually and there are no age-restrictions on the removal. I expect we'll eventually follow Git and auto-launch garbage collection when we hit some threshold of disk consumption (gc.auto). I expect we'll also follow Git and keep unpinned or unreachable objects (gc.pruneexpire, etc.). But we don't seem to do either of those yet.
-