TCP Retransmission Recovery SNAFU: Who’s at Fault?

Greetings sniffer warriors,

I have a strange TCP retransmission recovery error on an HTTPs exchange and I don't know who the culprit is, the client or the server.

All goes well (handshake, crypto, some data), then the client sends a TCP Zero Window with an ACK of a PARTIAL sequence. For example simply to illustrate, server sending:

[1-100 ] Seq 100

[101-200] Seq 200

[201-300] Seq 300

[301-400] Seq 400

At some point after this, the client sends: TCP Zero Window, ACK 263 (right smack somewhere in the middle of packet Seq 300)

It does that a few times, then sends a window size update, followed with a regular "ACK 263". The server doesn't seem to know how to send this "mid packet" 263 segment, so it restarts by sending segment 300. The client sends what is interpreted by Wireshark as Dup Acks, still for 263 and the server keeps sending packet Seq 300. After all the previous in-flights die, the trace shows that back and forth behavior packet by packet. Ack 263 ->, <- Seq 300. Eventually a RST kills all this off.

One wrinkle: SACK_PERM is not enabled. This is not something I control so I'm concentrating on explaining the behavior we see.

Question: Who's at fault?

TCP Zero Window and Update is a normal process, but is it normal / ok for the client to request that the server resume at a point that is not at the boundary of a previously sent packet?

If yes, is it the server's fault for not providing a retransmission starting at the requested sequence position rather than on a previous packet border?

Would Selective ACK help in this recovery process?

Thank you :)