Improve signalling of gateway errors

[mchlrch]

In order to facilitate debugging of configuration and infrastructure issues, the current handling of errors and status codes != HTTP 2xx received from the Triplestores SPARQL-Endpoint could be improved.

(sparqlProxy only) HTTP 502 expected instead of HTTP 200:

• if triplestore replies with HTTP 404 or HTTP 500, then sparqlProxy currently returns HTTP 200

(hydraBox only) HTTP 502 expected instead of HTTP 204:

• if triplestore replies with HTTP 404 or HTTP 500, then hydraBox currently returns HTTP 204

(sparqlProxy, hydraBox) HTTP 504 expected instead of empty reply:

• if triplestore takes more than 120 seconds to reply, then the default timeout on node causes trifid to hang-up and the client only sees an empty reply

(sparqlProxy, hydraBox) HTTP 502 instead of HTTP 500 would be more specific:

• if triplestore is not reachable (ECONNREFUSED), then trifid currently returns HTTP 500
• if socket hangs-up from triplestore, then trifid currently returns HTTP 500

[mchlrch]

To simulate HTTP replies and errors of the SPARQL-Endpoint, I used the following code: https://github.com/mchlrch/playground_nodejs/tree/master/http_simstub

[tpluscode]

To sum up my thoughts on the discussion yesterday:

I agree that the gateway status codes seem appropriate for sparqlProxy. Trifid is indeed acting as a gateway or proxy. It's even in the name.

For hydra-box I'm less convinced. Even if it call external services, it's more than a proxy. The fact that it can be used standalone suggests that hydra box should be solely responsible for its status codes.

And circling back, maybe so should be sparqlProxy? I admit I don't understand the relation between Trifid and the other elements...

[bergos]

This issue describes how the problem can be reproduced: https://github.com/zazuko/sparql-proxy/issues/10