Hi! While building a podcast streaming app (SDK 3.1.2, Simulator on macOS) we hit these with playdate->network->http, all with redirect chains of the kind podcast hosts use (podtrac > pdst.fm > ... > megaphone, 2 to 6 hops of 302):
getResponseStatus()always returns 0 for us, including on the final 206.- After the response hands us the Location, the connection still follows the redirect in the background. Those hidden requests hold connection slots, and their headers and body bytes turn up in later connections (stray callbacks, extra bytes before the real body, hangs).
- Closing a connection partway through a body breaks the next requests.
setByteRange()isn't sent again on a redirect hop.
We worked around it by speaking HTTP/1.1 ourselves over network->tcp (TLS), which works well: 10 of 11 real chains returned 206 at 65 to 430 KB/s in the Simulator. The code is MIT if it helps anyone: static-playdate/src/net.c at main · madewith-bestpractice/static-playdate · GitHub
Happy to send a minimal repro project.