Serving Partial HTTP Response

Question

I would like to make a file download resumable using byte-range requests.

The problem is that my existing download action is responding on a POST method and I would like to keep it that way.

But it seems from my early tests that Chrome turns interrupted POST requests for file downloads into GET requests when the user tries to resume and thus the resuming of the download fails.

1. Am I missing something?
2. Is this something related to the HTTP specs that only allow GET requests to be resumed?
3. Or is it simply a design flaw in Chrome (and maybe other browsers as well) that makes it forget the original HTTP method used?

UPDATE:

Here are the request/response data:

Initial POST request:

POST http://localhost:35547/Download?Guid=396b4697-e275-4396-818c-548bf8c0a281 HTTP/1.1
Host: localhost:35547
Connection: keep-alive
Content-Length: 0
Cache-Control: max-age=0
Origin: http://localhost:35547
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://localhost:35547/File/396b4697-e275-4396-818c-548bf8c0a281
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Cookie: __RequestVerificationToken=LuPgM05MHrsuyskgfhsrHVUs; ASP.NET_SessionId=gfiulghfuygisghkf; .ASPXAUTH=FGDJHGDHSDFB15AFDE6371CGJHDFGFBHD; fileDownload=true

Initial response (to the request above):

HTTP/1.1 200 OK
Cache-Control: private, s-maxage=0
Content-Type: application/zip
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 5.2
Content-Disposition: attachment; filename="FILE-396b4697e2754396818c548bf8c0a281.zip"
X-AspNet-Version: 4.0.30319
Set-Cookie: fileDownload=true; path=/
X-Powered-By: ASP.NET
Date: Wed, 09 Nov 2016 11:13:50 GMT
Content-Length: 1885473

PK.......... ZIP file data .............................................

After the interruption, this is the request that the browser does on resume (notice the GET method used):

GET http://localhost:35547/Download?Guid=396b4697-e275-4396-818c-548bf8c0a281 HTTP/1.1
Host: localhost:35547
Connection: keep-alive
Referer: http://localhost:35547/File/396b4697-e275-4396-818c-548bf8c0a281
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8
Cookie: __RequestVerificationToken=.............

(Some data from security-related cookies have been shortened and altered)

Answer 1

Am I missing something ?

It depends, upon how have you analyzed the behavior of google chrome. Ideal way will be use any proxy or to use packet sniffer such as Wireshark to see what request method, is used by chrome in subsequent request.

Is this something related to the HTTP specs that only allow GET requests to be resumed?

As of now, there's no mention in spec of HTTP protocol, that only GET requests can be resumed.

Or is it simply a design flaw in Chrome (and maybe other browsers as well) that makes it forget the original HTTP method used?

Yes, It's the flaw of google chrome. Make sure that you check it on the latest version of Google chrome with all the update patches. Also check it on other browsers.

For more info about HTTP protocol, refer to https://www.ietf.org/rfc/rfc2616.txt. Refer to following request, for serving partial response : https://en.wikipedia.org/wiki/Byte_serving

Edit For more updated info regarding HTTP info, refer to :- https://www.rfc-editor.org/rfc/rfc7230