Communicate streamed response errors to clients which don't support HTTP Trailers

[alxndrsn]

When there is an error in a streamed response, an HTTP trailer is added at:

central-backend/lib/http/endpoint.js

Lines 191 to 195 in 7c75951

	const streamErrorHandler = (response, next) => (err) => {
	response.addTrailers({ Status: 'Error' }); // TODO: improve response content.
	response.end();
	next(err);
	};

From node docs:

Trailers will only be emitted if chunked encoding is used for the response; if it is not (e.g. if the request was HTTP/1.0), they will be silently discarded.

HTTP requires the Trailer header to be sent in order to emit trailers,...
-https://nodejs.org/docs/latest-v16.x/api/http.html#responseaddtrailersheaders

There is a unit test covering the error handler:

central-backend/test/unit/http/endpoint.js

Line 503 in 7c75951

trailers.should.eql({ Status: 'Error' });

It's unclear if the trailers are actually written in practice:

• the test is just checking that response.addTrailers() was called
• currently "69%" of browsers support trailers (https://caniuse.com/?search=trailer)
• the Trailer header is not being explicitly added to the response
• "chunked encoding" is not being explicitly used for the response (maybe chunked is enabled by default?)

Are the trailers written in normal use? How do they affects e.g. interactive CSV download in a browser?

If the trailers are not written, or a failure is not communicated clearly to users, there might be alternative/additional ways to communicate an error to a user. These might include:

• .csv: e.g. write a final line --- ERROR DOWNLOADING CSV DATA ---
• .zip: e.g. deliberately corrupt the file