try and ensure 100% success rate even on crappy networks

[max-mapper]

today while testing duplex http at tivoli gardens in copenhagen we had the follow success/fails when doing a dat pull from an ubuntu server to a client tethered to either a slow t-mobile international roaming connection or a fast danish roaming connection:

• http w/ nginx on tmobile: fail
• https w/ nginx on tmobile: success
• http w/ nginx on 3: success
• https w/ nginx on 3: success
• http w/o nginx on tmobile: success
• https w/o nginx on tmobile: success
• http w/o nginx on 3: success
• https w/o nginx on 3: success
• ssh on tmobile: success
• http w/ nginx on tmobile plus calling http request.end - success (because it wasn't duplex http)

so something involving tmobile and nginx causes duplex http to break (major WTF). this wasn't a dat bug, we made a very small test case. the fix is to use https or ssh, and not http

we are thinking if you try and pull over http we should show a warning. we could also do a self signed certificate automatically when you do dat serve and default to https when cloning

we also want to write a simple duplex-http-tester CLI that anyone can run to test connections

[robert-nix]

I'm not familiar with this project, but I have a (USA domestic) T-Mobile wireless connection. If you can tell me how to get a server running and (hopefully) reproduce the issue, I can debug traffic and see what the root cause is.

[konklone]

Could be some kind of header "enrichment" or other kind of tracking/modification T-Mobile does as a company, which is only possible over HTTP (AT&T's and Verizon's programs also only worked over HTTP), and the modification is what nginx has a hard time with.