which is why i have given myself plausible deniability. no one likes a whistleblower.
when a connection aborts (which seems to be the case with https), there is nothing they can return. the same request under http does return 204, as expected.
this error message is the key: ResponseError. Reason: okhttp3.internal.http2.StreamResetException: stream was reset: PROTOCOL_ERROR, Response:
if the authorities are presented with this (and they research it), they might make nice to you.
on the client side, if you check for -1 and the error message and you see the above, at least you'll know what has happened. it's basically what the guys who wrote the server side api would do, no? it's the equivalent of your returning 204 to yourself.
why things work for apple needs some research; it is a different os with protocols implemented differently. sorry to repeat on my part, but i believe the front end (httputils) is not at fault. okhttp3 is further up the stack (or down, depending on your viewpoint).
a suitably abject message to your provider and to let's encrypt - with that error message - might help. i wouldn't go beyond mentioning that the same request made via http works. let them ask what they want to know, don't tell them what you think they should know.