Re: [MirageOS-devel] Cohttp, and the SSL saga update

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 14 Apr 2014, at 00:14, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:

>> Thomas, you also mentioned you ran across a potential HTTP chunked POST 
>> issue in Irminsule -- any more details on that?
> 
> Haven't got the time to dig into it (so that might be unrelated ...) but 
> that's easy to repro with cohttp.0.10 and 0.11:
> 
> $ opam install irminsule
> $ git init && touch c && git add c && git commit -a -m toto 
> $ git irmin -d -g
> 

I assume this is `irmin init -d -g` here?

> open a browser, points to localhost:8080/watch 
> 
> 1st issue: we should see [ but this never appears in chrome and appears 
> sometime in safari
> 
> and back in the terminal:
> 
> $ for i in `seq 1 10`; do echo foo >> c && git commit -a -m bar; sleep 1; done
> 
> 2st: still nothing appears on chrome, sometime safari shows something
> 
> It might be an issue with the response headers set by the irminsule server 
> though.

I ran this with

$ COHTTP_DEBUG=1 irmin init -d -g

and noticed this in the output:

30256 <<< GET /watch HTTP/1.1
30256 <<< Host: localhost:8080
30256 <<< Connection: keep-alive
30256 <<< Cache-Control: max-age=0
30256 <<< Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
30256 <<< User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36
30256 <<< Accept-Encoding: gzip,deflate,sdch
30256 <<< Accept-Language: en-US,en;q=0.8
30256 <<< 
30256 >>> HTTP/1.1 200 OK
30256 >>> content-type: application/json
30256 >>> transfer-encoding: chunked
30256 >>> 
30256 >>> 1
30256 >>> [
30256 >>> 
30256 >>> 3b
30256 >>> {"result":[[],"e5e8dc7a85dfd473e7ff6b939b0ac2ea52cc7941"]},
30256 >>> 
30256 >>> 3b
30256 >>> {"result":[[],"37b278fa95d852e5530b5f07e08a0bec7c0daa74"]},
30256 >>> 
30256 >>> 3b
30256 >>> {"result":[[],"a6964ce27d0e93d8ffc3cb91b419136312af5c41"]},
30256 >>> 

The JSON you're transmitting in each chunk is incremental.  Shouldn't every 
response chunk be standalone parseable?

Also, I'm not sure that this sort of long-lived connection will work outside an 
Javascript request, since the client will be buffering and waiting for a 
0-length chunk for the end of the connection.  Chrome is probably just waiting 
rather than doing an incremental rendering.  If you stick some Javascript on 
/watch and try a long poll it will probably work better.

TL;DR: Cohttp has no bugs! It's perfect!

-anil


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel