[dmitrizagidulin]

Fixes issue #422.

Currently, if you POST to / with a slug of http://csarven.ca/foo (to create a directory with that name), it succeeds with a response Location header of /http%3A%2F%2Fcsarven.ca%2Ffoo.
But what is physically created on the system is directory http: with subdirectory csarven.ca with file foo. Even if you uri-encode the slug before POSTing, the same thing happens, because the current behavior is to url-decode the slug for some reason, on the server.

The fixed behavior is now:

      let containerName = 'https://example.com/page'
      let expectedDirName = '/post-tests/https%3A%2F%2Fexample.com%2Fpage/'
      server.post('/post-tests/')
        .set('slug', containerName)
        .set('content-type', 'text/turtle')
        .set('link', '<http://www.w3.org/ns/ldp#BasicContainer>; rel="type"')
        .expect(201)
      // Now response.headers.location === expectedDirName, and that directory is created.

Similarly, retrieval of the created container works:

      let containerUrl = '/post-tests/https%3A%2F%2Fexample.com%2Fpage/'
      server.get(containerUrl)
        .expect('content-type', /text\/turtle/)
        .expect(200, done)

[dmitrizagidulin]

Tagging @dan-f / @nicola for review.

[nicola]

good with me

[dan-f]

Do we not clean up after every single test? I would have expected these two tests to be the same test, and for the resource /post-tests/https%3A%2F%2Fexample.com%2Fpage/ not to exist in the scope of other tests in this describe block.

[dmitrizagidulin]

Sounds like we clean up after each describe() block.

[dmitrizagidulin]

Heads up, @csarven - PR #471 is going to change the policy of URLs as container names, when it gets merged. New procedure: uri-encode the Slug header before creating your inbox container.