Thanks for your report. Am I understanding correctly that you're talking to ot-recorder with an HTTP/1.0 client and that you cannot make it speak 1.1?

That surprises me a bit as neither Apache nor nginx seem to have that problem, but I have not tried with lighttpd.

That's correct; until very recently (lighttpd/lighttpd1.4@f7919c1) lighttpd always sent HTTP/1.0 requests to its proxy backends and couldn't parse Transfer-Encoding: chunked replies.

After noticing that patch, tho', and jumping up to HEAD on my webserver, I now observe that ot-recorder is emitting both Transfer-Encoding: chunked and Content-Length response headers (itself a kind of bogus outcome) and the Content-Length is wrong (much more bogus; it is, in particular, much too short) when replying from the last api endpoint. I had to teach lighttpd to squash that header from responses, and then magically things worked.

I believe we fixed the too short Content-Length header in 31f453c (the commit message inaccurately says "Safari only")

Thank you for your report and help, @nwf. We're replacing the illegal Content-Length header by X-Content-Length where it might be used by our Frontend.

Before:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 469
Transfer-Encoding: chunked

After:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-Content-Length: 469
Transfer-Encoding: chunked

Thank you for the heads up, but I believe that the initial bug -- that the server speaks HTTP/1.1 in response to a HTTP/1.0 request -- still stands?

Yes, that's part of the embedded mongoose server, and we cannot easily change that.