SameSite=Lax on a cookie used for authentication exposed this issue for me.  In order to save a PDF, have to go into settings to tell Chrome to use the default PDF viewer in chrome://settings/content.

I think this is the same issue, but this may be a variant of this problem so I'm posting this occurrence.

Discovered when investigating a failure to download a PDF that requires a cookie for authentication. If the "Accept-Range" header is present on the initial download and SameSite=(Strict or Lax) is set on the cookie and the connection is slow (either real wire latency or simulated in-chrome latency), an additional GET request with a Range header will be issued to the same resource, but without the authentication cookie with SameSite=Strict or SameSite=Lax.

Working around this issue can be done by: (a) not setting "Accept-Range" in initial response (b) not setting SameSite=(Strict | Lax) in the cookie (c) ensuring the connection latency for all users is small enough that chrome doesn't issue the second range request.

(Unassigning myself, marking untriaged in preparation to retriage with folks who will do a better job taking care of cookies than I've been able to)