JSON API content type about wuzz HOT 20 CLOSED

Perhaps we should be using https://golang.org/pkg/mime/#ParseMediaType to parse the Content-Type header?

from wuzz.

@nwidger yap, definitely that would be the proper solution.

from wuzz.

@asciimoo I'll try and send a PR for that in a few.

from wuzz.

@nwidger awesome! thank you.

from wuzz.

@asciimoo thank you 👍

from wuzz.

I have tried the new code, I just find out that my endpoint return Content-Type: application/vnd.api+json; charset=utf-8 and wuzz failed to recognize it as JSON. Perhaps because of the charset? What do you think?

from wuzz.

@williamn I'm pretty sure mime.ParseMediaType handles parameters correctly. Here's a Playground link showing it's behavior with application/vnd.api+json; charset=utf-8:

https://play.golang.org/p/F1H0FnDFgg

Are you sure the formatJSON config option is enabled and that the JSON body being returned is properly formatted? Either of those would prevent wuzz from colorizing a JSON response despite successfully detecting it as JSON from the Content-Type.

from wuzz.

@nwidger yes, I got formatJSON = true in my ~/.wuzz/config.toml and my JSON response is valid. Is there any other way to test?

from wuzz.

@williamn Is there a wuzz incantation for a public API endpoint that you can provide that exhibits the bad behavior you're seeing?

from wuzz.

@nwidger I create a mock of my endpoint here http://www.mocky.io/v2/58b404b3110000c7191c4371

from wuzz.

@williamn this works well for me. wuzz http://www.mocky.io/v2/58b404b3110000c7191c4371 displays the highlighted and formatted json.

from wuzz.

@asciimoo hmm. That's strange. Here is my result

from wuzz.

Strange...
Here is my output of running wuzz -c /dev/null http://www.mocky.io/v2/58b404b3110000c7191c4371 (default config):

from wuzz.

@asciimoo I tried to use wuzz -c /dev/null http://www.mocky.io/v2/58b404b3110000c7191c4371 but in my side the result is the same 😁

from wuzz.

@williamn what is your go version? i'm using go version go1.8 linux/amd64

from wuzz.

@asciimoo here is mine go version go1.7 linux/amd64

from wuzz.

@williamn Perhaps try building in a fresh GOPATH to rule out any stale dependencies?

mkdir ~/gotmp
GOPATH=$(realpath ~/gotmp) go get -u github.com/asciimoo/wuzz
~/gotmp/bin/wuzz -c /dev/null http://www.mocky.io/v2/58b404b3110000c7191c4371

from wuzz.

@nwidger it works! what seems to be the problem?

from wuzz.

@williamn If that worked then it could be a couple of things:

What does which wuzz return? If it doesn't return $GOPATH/bin/wuzz, then you've been running some other wuzz binary from an entry in your PATH environment variable. You should either delete those versions of wuzz or reorder PATH such that $GOPATH/bin is searched sooner.

It's also possible you have been running $GOPATH/bin/wuzz this entire time and simply have out of date versions of wuzz or some of its dependencies. The simplest thing would probably be to run:

rm -rf $GOPATH/src/github.com/asciimoo/wuzz
go get -u github.com/asciimoo/wuzz

and then see if $GOPATH/bin/wuzz -c /dev/null http://www.mocky.io/v2/58b404b3110000c7191c4371 works correctly.

from wuzz.

@nwidger thanks. I reinstall the package and it's fine now.

from wuzz.