iOS: Empty HTTP responses


I have a issue regarding HTTP requests on iOS.

So I see empty HTTP responses. Then JSON parser crashes then. But in our server access log i see no 0 bytes sized http responses.

Can this be a OpenFL bug on iOS? We do not have issues on HTML or Android like that.

I use a stock openfl installation via HaxeLib and build our game via XCode for iOS.
lime: 5.5.0 5.6.0 5.7.0 5.8.2 6.0.1 6.2.0 6.3.1 6.4.0 7.0.0 7.1.1 7.2.0 7.2.1 7.3.0 7.5.0 7.6.0 [7.6.3]
openfl: 6.1.2 6.2.0 6.2.1 6.5.0 7.0.0 7.1.2 8.0.2 8.2.2 8.4.1 8.5.1 8.6.4 8.7.0 8.8.0 8.9.0 8.9.1 8.9.2 [8.9.5]

Please see attached a screen shot of LLDB being connected to my iPAD.

But access log has no 0 bytes response. And every response had a 200 status code

Any ideas how to debug this issue or find its origin?

Many thanx and

Best regards

Here’s an overview of how the network subsystem should be working:

  1. (and similar methods) use Lime internally to make network requests
  2. is the actual place where network requests are made (with separate implementations for native and HTML5 platforms)
  3. lime._backend.native.NativeHTTPRequest is the implementation of HTTPRequest for native targets, using a background thread and a cURL Multi instance internally
  4. has a perform() method where network traffic is processed and flushed
  5. “project/src/net/CURLBindings.cpp” is where this is actually implemented in the native C++ code

In order to prevent crashes caused by triggering Haxe garbage collection on the wrong thread we cannot make progress callbacks while we are transferring network data because it is a blocking operation

As a result we use a buffer when downloading then flush the buffer when multi.perform() is called when we can handle the data on the correct thread

Short of a better reproduction case my thoughts do go to the buffer/flush mechanism and wonder if somehow the complete event is triggering without flushing the data or if we somehow are writing the wrong byte length on the callback – regardless there’s a lot of layers here that could be traced to see if the results seem sound

Is there a simple way to reproduce the issue or do you think it would be possible to debug this a bit further to get more information on what is occurring? Thank you!


thank you very much. I will tomorrow check in the deepest layer if the data arrives and report here my observations. And then we can see what happens next.

Best regards


I’ve created a test that can reproduce this issue. Do you want to have it?

This is the output before the app dies:
Main.hx:34: onRequestResponseHandler(): response == ok
Main.hx:39: onRequestResponseHandler(): have a request started
Main.hx:19: doRequest(): response == ok
libc++abi.dylib: terminating with uncaught exception of type Dynamic

  • thread #1, queue = ‘’, stop reason = signal SIGABRT
    • frame #0: 0x00000001c126b104 libsystem_kernel.dylib__pthread_kill + 8 frame #1: 0x00000001c12e7020 libsystem_pthread.dylib + 380
      frame #2: 0x00000001c11c2d78 libsystem_c.dylibabort + 140 frame #3: 0x00000001c088cf78 libc++abi.dylib + 132
      frame #4: 0x00000001c088d120 libc++abi.dylib<redacted> + 304 frame #5: 0x00000001c08a5e68 libobjc.A.dylib + 140
      frame #6: 0x00000001c08990fc libc++abi.dylib<redacted> + 16 frame #7: 0x00000001c0898cec libc++abi.dylib__cxa_rethrow + 144
      frame #8: 0x00000001c08a5c20 libobjc.A.dylibobjc_exception_rethrow + 44 frame #9: 0x00000001c165f25c CoreFoundationCFRunLoopRunSpecific + 544
      frame #10: 0x00000001c38d8584 GraphicsServicesGSEventRunModal + 100 frame #11: 0x00000001ee5b4c00 UIKitCoreUIApplicationMain + 212
      frame #12: 0x0000000101363018 urlloadertestSDL_UIKitRunApp + 208 frame #13: 0x00000001c111ebb4 libdyld.dylib + 4

It seems that the issue does appear If I do a request within a request response handler.

Hmm. I could reproduce the error 2-3 times and now its gone. I will continue to test. Maybe I have a router problem. Idk yet.