[tink_http] Client: how to gracefully deal with an invalid but successful response?

With tink_http v0.9.1, I use the Client.fetch() method to query a remote endpoint.
This endpoint is accessible through a GET request and just returns a HTTP status code indicating the outcome: the response has no body, and its headers are not meaningful.

My issue: I get the following response when the request is successful.

HTTP/1.1 200 OK
Server: nginx
Date: Sat, 12 Dec 2020 13:58:02 GMT
Transfer-Encoding: chunked
Connection: close

If the compilation target is Node.js (the underlying client is SecureNodeClient), everything is fine.

But if the compilation target is a sys one (i.e. HashLink, JVM or PHP: the underlying client is SecureSocketClient), I’m starting to have errors.

With the JVM, the code does not compile! I encounter this issue: Typing issue · Issue #14 · haxetink/tink_chunk · GitHub.
(fixed: must use the latest Git version of tink_chunk instead of v0.3.1)

With other sys targets, the Tink HTTP client raises the following error:

Error#500: Chunked encoding is not supported and the content-length header is required.

I’m using this kind of code to fix the error… but it’s very ugly:

return
	try Client.fetch(url).map(outcome -> switch outcome {
		case Success(_):
			Success(Noise);

		case Failure(error):
			error.code == InternalError && ~/content-length header is required/i.match(error.message)
				? Success(Noise)
				: Failure(error);
	})
	catch (e) new Error(e.message);

So, is it possible to stop the HTTP client from parsing the response headers to avoid this error? I only need to check if the HTTP status is 200, and nothing else.

Also: with sys targets (i.e. it’s not required with Node.js), I must wrap the call with a try/catch because, contrary to my expectations, if a network error occurs an exception is raised instead of having a Failure outcome.

  • HashLink: Uncaught exception: SysError(Failed to connect)
  • PHP: Fatal error: Uncaught ErrorException: socket_connect(): unable to connect [10061]

Another issue: because of this behavior, my code fails to handle remote errors. When the remote service returns a 403 status (the response body is identical to a success one), the Failure is still the same: 500 Chunked encoding is not supported and the content-length header is required. :sob:

@kevinresol @back2dos Any idea?

Please report on the appropriate issue tracker, ideally with a reproducible example :wink:

Too bad: usually you always have the right answer for me :smile:

I will do… when I have a little more free time. I still have to look closely to the tink_http code and think about how to better formulate this problem (I’m old and slow :pensive:).