search

azavea / tilegarden

Serverless raster and vector map tile generation using Mapnik and AWS Lambda
https://azavea.github.io/tilegarden/
Other
98 stars 7 forks source link

Consider switching error handling to returning relevant HTTP response codes #75

Closed mattdelsordo closed 6 years ago

mattdelsordo commented 6 years ago

Currently, endpoints that throw errors return the errors as a json or image message to the user in order to aid debugging and make it very visible that something went wrong. However, after some thought (and not being able to print error messages to vector tiles) I'm less confident in this design choice. My reasons for this are:

  1. Messages can't be returned for all endpoints, which disrupts your expectation of how the tool in general is going to behave. Ideally, if there's an error, all endpoints should fail in the same, expected way.
  2. Returning human-readable messages is great for human debuggers but might lead to unnecessary debugging complications if a library used to fetch tiles has its own ways to gracefully handle HTTP status codes.

It might be a good idea to revisit error handling in the api module and convert thrown errors into meaningful status codes, instead of returning the error content with a 200.

mattdelsordo commented 6 years ago

Another consideration here is that displaying all errors to the client in a human-readable way could lead to SQLI problems, since database errors get returned verbatim.

mattdelsordo commented 6 years ago

One more thing (that is only an issue without the log abbreviating claudia-local-api patch), printing logs to an image makes the console spit out the base-64 encoded image, which is incomprehensible and obscures the actual error messages.