Plex Sync: the `{}` body on GET requests makes Plex drop the connection behind a reverse proxy, plays go missing

Hi,

So the short version: the sync sends {} with Content-Length: 2 on every GET. When Plex sits behind a reverse proxy, it reads the headers, misses the body, answers anyway and then closes a connection that still has 600 KB of response in it.

The longer version. Plex reads a request only once. Behind a proxy (Caddy here, but anything built on Go's HTTP stack will do the same) the two body bytes arrive just after that read, because the proxy sends the headers first and the body a moment later. Plex sees a request without a body, answers it and closes the connection. The kernel finds unread bytes on that socket and turns the close into a reset. Any part of the response still waiting to be sent is thrown away. The small calls survive. The big one, /library/metadata with 100 ids, does not. The client retries three times, gives up and never gets to the history call. The next round starts from a later lastViewedAt, so those plays are skipped for good.

I confirmed this with packet captures and a kernel trace (tcp_send_reset, reason TCP_ABORT_ON_CLOSE), then reproduced it through a plain Caddy: four resets in eighteen batch calls. A direct https connection to Plex never lost a byte. So this only hits people with a proxy in front of Plex. They will not know why an episode is missing.

Suggested fix: send GET requests without a body. Plex does not read it. Now we know exactly how it does not read it.

I have a workaround in place (my proxy strips GET bodies), so no rush on my end. Captures and a reproducer script are available if you want them.

Cheers! Eric.