eudoxia0 / lucerne

A web framework for Common Lisp, built on Clack
http://borretti.me/lucerne/
142 stars 19 forks source link

Strange disconnection on Android, Appcelerator Titanium client #21

Closed ghard closed 8 years ago

ghard commented 8 years ago

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:

function sendRequest(e) {
    console.log('http request started');
    var httpClient = Ti.Network.createHTTPClient({
        onload : function(){
            console.log('Data '+this.responseText);
            alert ('success!');
        },
        onerror: function(error){
            console.log('Error '+ this.responseText+' status '+this.status);
            alert('fail!\n');
        }
    });
    httpClient.setTimeout(4*1000); 
    httpClient.open('GET','http://192.168.69.185:8003/');
    httpClient.send();
}

$.index.open();

The Lucerne app is just the generator skeleton app with a simplified / route:

@route app “/“
(defview index ()
  (respond “Hello, Lucerne!” :type “text/plain”))

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

ghard commented 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. to attempt to read the body of the request, which, of course, will not be coming on the wire any time soon... Other servers I've tried apparently do not expect to see a body on a GET request, even when a disingenious client sets a silly content-type.