Add a test for a relative link and add a comment

The comment explains how this is a pragmatic fix that could be done
in a more robust way by changing data structures to distinguish
between server and gabbi test generated urls.

gabbi/tests/gabbits_intercept/prefix.yaml

@@ -1,16 +1,20 @@
 
 tests:
 
-- name: provide a link in response
+- name: provide a link
   POST: /
   request_headers:
       content-type: application/json
   data:
       link: $ENVIRON['GABBI_PREFIX']/barnabas
+      relative: link
 
 - name: get that link
   GET: $RESPONSE['$.link']
-  response_headers: 
+  response_headers:
       x-gabbi-url: "///[a-f0-9:-]+$ENVIRON['GABBI_PREFIX']/barnabas/"
 
-
+- name: get relative link
+  GET: $HISTORY['provide a link'].$RESPONSE['$.relative']
+  response_headers:
+      x-gabbi-url: "///[a-f0-9:-]+$ENVIRON['GABBI_PREFIX']/link/"

gabbi/utils.py

@@ -52,8 +52,16 @@ def create_url(base_url, host, port=None, prefix='', ssl=False):
     query_string = parsed_url.query
     path = parsed_url.path
 
-    # Guard against a prefix of None
-    # Without the startswith check, the tests in prefix.yaml fail.
+    # Guard against a prefix of None or the url already having the
+    # prefix. Without the startswith check, the tests in prefix.yaml
+    # fail. This is a pragmatic fix which does this for any URL in a
+    # test request that does not have a scheme and does not
+    # distinguish between URLs in a gabbi test file and those
+    # generated by the server. Idealy we would not mutate nor need
+    # to check URLs returned from the server. Doing that, however,
+    # would require more complex data handling than we have now and
+    # this covers most common cases and will be okay until someone
+    # reports a bug.
     if prefix and not path.startswith(prefix):
         path = '%s%s' % (prefix, path)