Closed ghard closed 8 years ago
Silly me was missing the stack traces on this.
It is caused by Clack v1 compat's handling of the request. Ti HTTP Client always automatically sets a content-type, even for GET!
This triggers instance initialization method for clack.
I am running into a rather curious problem while using this particular client with a backend API I wrote using Lucerne.
What happens on the TCP side of things is the reply seems to be sent back to the client, but the ACK to the reply is never received and the client times out. With bare Clack everything works just fine. I am using SBCL 1.3.5 at the moment.
Other clients, such as the iOS client used by the Titanium app compiled for iOS, work just fine with Lucerne.
The Android Ti client works just fine with node.js, Clack, plain Hunchentoot, Nginx, and Apache. Of all the combinations I’ve tried so far, only with the combination Lucerne on top of Clack using Hunchentoot, causes problems, on this particular client.
When Lucerne-app is proxied through nginx we get a 499 error indicating the client has disconnected prematurely.
This is a barebones client that exhibits the problem:
The Lucerne app is just the generator skeleton app with a simplified / route:
Clack was tested with the very minimal:
(clackup (lambda (env) '(200 (:content-type “text/plain”) (“Hello, Clack!”))))
I've attached the packet captures from the above tests, showing the normal and anomalous behaviour in tihttclient-test-pcapng.tar.gz