right now a relative url maps to the hostname without the port
200: (response) ->
I don't see anything in Shred currently that supports use of a request url like /content/hello-world.json. The http object in your example would need to have been initialized with scheme, host, and port; this does not appear to be possible in Shred.
See #51 :)
Based on my digging in source code, relative url requests are not meant to be supported, but they kinda work.
One evidence that they are not supported is that in request.url get and set, parsing will be done such that scheme will be null/empty. So a set of a relative url request will not come back thru a get (get will return null).
This appears to end up working because in createRequest function, scheme is compared to "http", without a check for whether it is null/empty. Thus HTTPS ends up being chosen. In the end it does not appear to matter because the browser will pick whatever protocol the webpage is using for a request that starts with a "/".
My preference would be to make relative URL requests work, even without #51 as it can be useful. For my specific purpose, we have REST APIs, their documentation (swagger-ui), and a simple web application on the same server; our end users can configure the IP of the server. It would be easier for us to specify relative urls for all the APIs relative rather than modify code to attach the host name everywhere.
issue #36, maybe issue #51? adding support for relative urls based on…
… source url