fix: escape HTML in error response body

[lidel]

This is a basic "better safe than sorry" cleanup of unexpected error responses.

• To avoid situation where someone uses this as a vector for HTML injection, response is escaped via template.HTMLEscapeString
• To avoid noisy line endings and make it more clear where values start and end, payload is printed with %q which adds quotes and replaces line breaks them with \n

[aschmahmann]

This seems reasonable, although is it worth doing this? i.e. we could just return "unknown error" and log this info out (e.g. in the go-ipfs daemon).

[lidel]

@aschmahmann Yeah, this is just a quick fix to unblock RC1. We need to clean up error handling before final 0.8:

I played a bit with the API and printing entire httpbody into console or returning it from /api/v0/pin/remote is pretty bad (noisy console is useful for debug but bad UX, and returning http body with error details in HTTP API is very risky security-wise, could leak some details about the backend service).

Ideally, httpbody should not be returned to the user, go-ipfs should log it as %q in "debug/trace" level instead.

[aschmahmann]

Ideally, httpbody should not be returned to the user, go-ipfs should log it as %q in "debug/trace" level instead.

We already have a logger so seems like a few line fix to just use logger.Debug and return something like unknown pinning service error, right?

[lidel]

Yes, if we can tell between errors returned by the pinning service (error object with "reason" and "details") and unexpected ones, that would be the best way of handling it. We also need the ability to enable debug log only for remote pin operations.

[aschmahmann]

fixed in #3