alm-cli does not properly parse urls

[dustymabe]

Seems like this works fine using curl:

[vagrant@f24 almighty-core]$ curl -X POST 'http://core-dustytest.e8ca.engint.openshiftapps.com/api/workitems' -d '{"type": "system.userstory" ,"fields": { "system.creator": "dustymabe", "system.state": "new", "system.title": "My special story", "system.description": "description" }}'
{"fields":{"system.assignee":null,"system.creator":"dustymabe","system.description":"description","system.state":"new","system.title":"My special story"},"id":"2","type":"system.userstory","version":0}
[vagrant@f24 almighty-core]$ 

but going through alm-cli I get complaints of invalid URL escape:

[vagrant@f24 almighty-core]$ ./bin/alm-cli create workitem --payload '{"type": "system.userstory" ,"fields": { "system.creator": "foobar", "system.state": "new", "system.title": "My special story", "system.description": "description" }}' -H 'http://core-dustytest.e8ca.engint.openshiftapps.com'
2016/09/06 22:54:46 [EROR] failed err=parse http://http:%2F%2Fcore-dustytest.e8ca.engint.openshiftapps.com/api/workitems: invalid URL escape "%2F"
Error: parse http://http:%2F%2Fcore-dustytest.e8ca.engint.openshiftapps.com/api/workitems: invalid URL escape "%2F"
Usage:
  alm-cli create workitem ["/api/workitems"] [flags]

Flags:
      --content string   Request content type override, e.g. 'application/x-www-form-urlencoded'
      --payload string   Request body encoded in JSON
      --pp               Pretty print response body

Global Flags:
      --dump               Dump HTTP request and response.
      --format string      Format used to create auth header or query from key (default "Bearer %s")
  -H, --host string        API hostname (default "almighty.io")
      --key string         API key used for authentication
  -s, --scheme string      Set the requests scheme
  -t, --timeout duration   Set the request timeout (default 20s)

parse http://http:%!F(MISSING)%!F(MISSING)core-dustytest.e8ca.engint.openshiftapps.com/api/workitems: invalid URL escape "%!F(MISSING)"

[dustymabe]

looks like it blindly tacks on http:// to the front of whatever host is provided. We should probably make the code a little smarter.

[tsmaeder]

I don't think this is a bug at all: the doc clearly says:

-H, --host string API hostname (default "almighty.io")

Garbage in-garbage out.

[aslakknutsen]

@tsmaeder Doc or no doc, doesn't mean we can't handle it.

[maxandersen]

@tsmaeder so you have to do -h blah.io -s https ? that seems overly tedious knowing most humans and computers by now like to use urls too :)

[aslakknutsen]

@maxandersen but.. the client knows the 'base' of the URL.. scheme:host/base.. we could infer scheme via the malformatted 'host' http://xxx, but do we override 'base' as well? or do we always append base?

[aslakknutsen]

Normally, a user wouldn't have to provide --host at all, as it will default point to production This is technically a 'dev' problem.

[maxandersen]

maybe just add support for --url ?