Skip to content

GitLab

Switch branch/tag
  1. 06 Oct, 2016 1 commit
  3. 09 Sep, 2016 1 commit
  5. 07 Sep, 2016 1 commit
  7. 26 Aug, 2016 1 commit
  9. 10 Jul, 2016 1 commit
  11. 24 Jun, 2016 1 commit
  13. 15 Jun, 2016 1 commit
  15. 09 Jun, 2016 1 commit
  17. 04 May, 2016 1 commit
  19. 13 Apr, 2016 1 commit
  21. 04 Mar, 2016 1 commit
  23. 01 Mar, 2016 3 commits
  25. 13 Feb, 2016 1 commit
  27. 30 Jan, 2016 2 commits
  29. 25 Jan, 2016 1 commit
  31. 21 Jan, 2016 1 commit
  33. 16 Jan, 2016 1 commit
  35. 12 Jan, 2016 2 commits
  37. 05 Nov, 2015 1 commit
  39. 28 Oct, 2015 1 commit
  41. 27 Oct, 2015 1 commit
  43. 03 Oct, 2015 1 commit
  45. 15 Sep, 2015 1 commit
  47. 23 Aug, 2015 2 commits
  49. 14 Aug, 2015 1 commit
  51. 14 Jul, 2015 2 commits
  53. 03 Jul, 2015 1 commit
  55. 01 Jun, 2015 1 commit
  57. 22 May, 2015 1 commit
  59. 20 May, 2015 1 commit
    • W. Trevor King's avatar
      namesys: Add recursive resolution · 3ead2443
      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.
      3ead2443
  61. 09 May, 2015 1 commit
    • W. Trevor King's avatar
      path/resolver_test: Test recursive Link resolution · 19823c67
      W. Trevor King authored 
      Setup a three-level graph:

  a -(child)-> b -(grandchild)-> c

and then try and resolve:

  /ipfs/<hash-of-a>/child/grandchild

Before 10669e8b (path/resolver: Fix recursive path resolution,
2015-05-08) this failed with:

  resolver_test.go:71: no link named "grandchild" under QmSomeRandomHash

The boilerplate for this test is from pin/pin_test.go, and I make no
claims that it's the best way to setup the test graph ;).
      19823c67
  63. 08 May, 2015 2 commits
    • W. Trevor King's avatar
      path/resolver: Fix recursive path resolution · 10669e8b
      W. Trevor King authored 
      I'm not entirely clear on Go's scoping (there's some text I can't
quite parse here [1]), but it seems like the := version (because this
is the first time we use 'err') was masking the function-level 'nd'
just for this if block.  That means that after we get out of the if
block and return to the start of the for-loop for the next pass,
nd.Links would still be pointing at the original object's links.

This commit drops the :=, which fixes the earlier:

  $ ipfs ls QmXX7YRpU7nNBKfw75VG7Y1c3GwpSAGHRev67XVPgZFv9R/static/css
  Error: no link named "css" under QmXX7YRpU7nNBKfw75VG7Y1c3GwpSAGHRev67XVPgZFv9R

so we get the intended:

  $ ipfs ls QmXX7YRpU7nNBKfw75VG7Y1c3GwpSAGHRev67XVPgZFv9R/static/css
  Qme4r3eA4h1revFBgCEv1HF1U7sLL4vvAyzRLWJhCFhwg2 7051 style.css

It also means we're probably missing (or are unreliably using) a
multi-level-path-resolving test.

[1]: https://golang.org/ref/spec#Declarations_and_scope
      10669e8b
    • Henry's avatar
      core: add context.Context param to core.Resolve() · f640ba00
      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
      f640ba00
  65. 27 Apr, 2015 1 commit