Closed bortexz closed 6 years ago
I can't think of what would cause this and I haven't seen it before. Did you discover anything? If so, please leave a comment here so I can look into it.
I'm going to close this for now, since it appears to be a Chrome bug, not a simple-get bug.
Hi @feross
Yes, it was/is a Chromium bug, I filled an issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=775014
Not sure if it's already solved in latest Chrome version.
@bertofer Thanks for sharing that update.
I am developing a project with Webtorrent that uses webseeds. I observed a weird behaviour with the range requests that were made to the webseed server. The downloads never completely finished, and my webseed was being choked (Although I am using WebTorrent 0.98.19), and the issue of choking webseeds has been already solved & released.
Observing the requests in the network, I could see that some of them were receiving 200 OK, instead of 206 Partial Content, and it turned out that the range header was not being sent:
I have tried in Firefox and Opera, and works properly. So I have been observing chrome://net-internals/#events and I see a strange behaviour. Somehow, when the cache is enabled this behaviour appears, but if in the network devTools the
Disable cache
option is ON, then everything works fine, so it seems to be a problem with the Chrome caching.These are logs of events of URL_REQUESTS, the first one is of a working request (206 partial content), while the second one is of a failing one. As you can see, after what seems to be a request to the cache, then the original request has the range header removed.
Working request:
Failing request:
My setup is Macbook Pro 13', macOS Sierra 10.12.6, Chrome 61.0.3163.100
I know the issue is probably not in the
simple-get
project itself, but I wanted to post it here to see if anyone has seen similar behaviour, or knows a workaround.