4 ms·
It's a little odd that they elected to invent their own way of requesting just a range of bytes in a file. It's built into HTTP: https://tools.ietf.org/html/rf
by zackbloom 10y ago
It's a little odd that they elected to invent their own way of requesting just a range of bytes in a file. It's built into HTTP: https://tools.ietf.org/html/rfc7233 https://tools.ietf.org/html/rfc7233
- douglasfshearer 10y agoYouTube also put the byte range in the URL rather than using a range request header. Perhaps it mitigates against proxies stripping the headers, or it simplifies caching.
- tyre 10y agoyou can also send a link that way (e.g. via email/Slack.) No way to send a link with an http header
- a1k0n 10y agoI tried to use the Range header feature to resume downloads in an autoupdating app once, and it worked beautifully...for about 90% of users; the others had all kinds of weird issues thanks to transparent proxies and caches not handling the Range header correctly. This was years ago, but I'm not surprised they chose to be safer than sorry.
- JoshTriplett 10y ago> I tried to use the Range header feature to resume downloads in an autoupdating app once, and it worked beautifully...for about 90% of users; the others had all kinds of weird issues thanks to transparent proxies and caches not handling the Range header correctly. One of many reasons to use HTTPS: prevent tampering with your requests and responses.
- zeta0134 10y agoYoutube recently did a writeup on their long road to HTTPS: http://youtube-eng.blogspot.com/2016/08/youtubes-road-to-https.html http://youtube-eng.blogspot.com/2016/08/youtubes-road-to-htt... I find it particularly telling that switching to HTTPS caused many streaming errors to mysteriously vanish, and I suspect ISP / proxy tampering to be part of the cause. I'd love to know more about what their engineers saw though.
- dzlobin 10y agoWe had similar issues when I was at iHeartRadio. We got reports from a number of users that were getting a lot of playback issues. Once we saw that the users were all in a relatively small area in the southeastern US, it took a few days of dealing with local ISPs to sort out the issue: all requests on a certain local ISP were being rewritten and certain headers were getting removed altogether.
- andreasklinger 10y agoMost likely to make sure it works everywhere (browsers, proxies, etc)
- toast0 10y agoCan you set range headers from javascript? Can you set them from random video player SDKs?
- jonahx 10y ago> Can you set range headers from javascript? Yes, see http://stackoverflow.com/questions/15561508/xmlhttprequest-206-partial-content http://stackoverflow.com/questions/15561508/xmlhttprequest-2... > Can you set them from random video player SDKs? Good point, probably not.
- alexhornbake 10y agoNot that odd if you are trying to represent a chunk of a file with a single url, which would be desirable if you were serving video manifest/playlist files like m3u8 (HLS) or f4m (HDS). IIRC Netflix is using HDS. Edit: not sure what format they are using, probably several depending on the client... But one url per chunk makes sense for multiple delivery formats as well.
- donavanm 10y agoAs others have mentioned "ranges" are put in the uri stem & query string for two reasons; evading mangling proxies and simpler access from browsers/clients. From memory notable implementarions are MPEG DASH, action script/flash, icecast, and various proprietary "services". The formats that send time ranges instead of bytes ranges are the worst. In that case the server/cdn has to retrieve & read the manifest, decode time indexes to fragments/chunks/ranges, and then return the appropriate byte stream to the player. This also means you cant cache based on the URI plus query string! Source: ive worked at both ISPs and CDNs supporting streaming content
- toxik 10y agoI mean I see the benefit, but any semi-competent proxy already caches based on the Vary header, and also the range header (per the HTTP 1.1 specification.) It shouldn't be a problem. Also query strings are per definition part of the URL.