Commit Graph

9 Commits (96321ff8bd9a8c63ad7efb4278bbc442e654bb33)

Author SHA1 Message Date
Johnny Steenbergen 2b0b32abe8 chore(http): pull out eror handler into kit pkg for portability 2020-02-03 12:39:47 -08:00
Jonathan A. Sternberg cbd04f2884
refactor: http error serialization matches the new error schema (#15196)
The http error schema has been changed to simplify the outward facing
API. The `op` and `error` attributes have been dropped because they
confused people. The `error` attribute will likely be readded in some
form in the future, but only as additional context and will not be
required or even suggested for the UI to use.

Errors are now output differently both when they are serialized to JSON
and when they are output as strings. The `op` is no longer used if it is
present. It will only appear as an optional attribute if at all. The
`message` attribute for an error is always output and it will be the
prefix for any nested error. When this is serialized to JSON, the
message is automatically flattened so a nested error such as:

    influxdb.Error{
        Msg: errors.New("something bad happened"),
        Err: io.EOF,
    }

This would be written to the message as:

    something bad happened: EOF

This matches a developers expectations much more easily as most
programmers assume that wrapping an error will act as a prefix for the
inner error.

This is flattened when written out to HTTP in order to make this logic
immaterial to a frontend developer.

The code is still present and plays an important role in categorizing
the error type. On the other hand, the code will not be output as part
of the message as it commonly plays a redundant and confusing role when
humans read it. The human readable message usually gives more context
and a message like with the code acting as a prefix is generally not
desired. But, the code plays a very important role in helping to
identify categories of errors and so it is very important as part of the
return response.
2019-09-19 10:06:47 -05:00
Jonathan A. Sternberg cb9d8eafe7
fix(http): use the content type header to determine how to parse http errors (#14596)
This will only attempt to parse an error as JSON if it has the content
type `application/json` so that it stops trying to parse the result as
JSON when it isn't JSON.

While the real error message is included, the addition of the "could not
parse json" makes it very confusing to read and distracts from the real
issue.
2019-08-08 14:23:43 -05:00
Kelvin Wang 9ecada4dce feat(http): convert errorEncode to use interface 2019-06-26 21:41:01 -04:00
Kelvin Wang f99f4759fa fix(http): fix task errors 2019-01-25 10:31:24 -08:00
Kelvin Wang 79ce30691e update(http): remove kerrors, change the default to be influxdb error 2019-01-25 10:29:26 -08:00
Mark Rushakoff d73d73c0d4 chore: rename imports from platform to influxdb
I did this with a dumb editor macro, so some comments changed too.

Also rename root package from platform to influxdb.

In interest of minimizing risk, anyone importing the root package has
now aliased it to "platform" so that no changes beyond imports were
necessary in those files.

Lastly, replace the old platform module to local path /dev/null so that
nobody can accidentally reintroduce a platform dependency while
migrating platform code to influxdb.
2019-01-09 20:51:47 -08:00
Mark Rushakoff faf5408a7b fix(http): increase errorHeaderMaxLength
The limit was introduced in 510325ea5c but
it didn't specify why 64 was chosen.

According to https://stackoverflow.com/a/6160643, we should be able to
assume at least 8kb of space for HTTP headers, so I'm assuming 256 bytes
should be sufficient to avoid truncating most error messages, without
being likely to hit the total HTTP header limit.

Fixes #530.
2018-08-01 16:04:36 -07:00
Nathaniel Cook b63394da0a fix(errors): Update Fluxd errors
This PR also completes some TODOs about kit/errors and http/errors.
2018-06-28 16:56:35 -06:00