6 ms·

One of the heaviest users of range requests is (or was) the Adobe Acrobat PDF plugin.

by fanf2 6y ago

iudqnolq 6y ago
I'm surprised that works, iirc pdf isn't defined in order and can't be parsed streaming
- kindall 6y ago
  I think that's what the "optimize for Web" checkbox does
  - IshKebab 6y ago
    Wow so it actually does something! I wish programs would use such vague descriptions. (Or more of them had helpful instant tooltips.)
    - maskros 6y ago
      Linearized (a.k.a. web optimized) PDF files only help for displaying the first page quickly. The rest of the file is still in pretty much random access order.
      - e12e 6y ago
        For what it's worth, there's a format for content like pdfs that's optimized for viewing on screens (as opposed to printing), djvu: https://en.m.wikipedia.org/wiki/DjVu https://en.m.wikipedia.org/wiki/DjVu Oh, wow initial release 1998,now I'm feeling a bit old...
- tonyedgecombe 6y ago
  Linearised PDF files are defined in order and can be read from the start. https://blog.idrsolutions.com/2010/02/linearized-pdf-files/ https://blog.idrsolutions.com/2010/02/linearized-pdf-files/
scottlamb 6y ago
Also .mp4 files. The format is designed for seekability, and browsers take advantage of this.
- fy20 6y ago
  Progressive JPEGs work well for this too, so you could have the same file used for a tiny thumbnail and large preview and full sized photo by sending different range requests. However you need to know how many bytes to request. I'm surprised this isn't used on mobile browsers to lower data usage. I'm sure with a little research you could figure out what a good mapping from pixel size to byte size should be to give good enough results.
  - duskwuff 6y ago
    A browser doesn't have enough information to use this optimization. At the point where it's about to request an image, it doesn't know how large the resource will be, whether it'll be a progressive JPEG, or even whether it'll be a JPEG at all. Making range requests blindly would probably be a net loss -- for every progressive JPEG that the browser managed to save some time on, it'd have to make follow-up requests for many more non-progressive JPEGs, non-JPEG images, and progressive JPEGs which it didn't get enough data from on the first try.
    - _flux 6y ago
      You are correct. However, one could use this approach: download as usual, and in a streaming fashion process the data and if it's a progressive JPEG, you can close the connection before you have received everything; and then you can cache the prefix and later download the rest if needed. Fast clients will just swallow the whole file, while slow clients would be able to benefit from it. It wouldn't work for pipelined HTTP connections though without cancelling the whole pipeline, so maybe not a very practical solution given the performance benefit that already gives. And HTTP/2 maybe doesn't support cancelling a transfer either, so.. ? Maybe a direct "Accept" or "Prefer" header to indicate that it's enough to send just something useful for an icon would be a more ideal solution, but it would require server-side support.
0x0 6y ago
I remember putting together a sloppy http range implementation that initially only supported single ranges, it had quite the explosive effect on adobe reader when it didn't get the expected response to its multi-range requests :)

One of the heaviest users of range requests is (or was) the Adobe Acrobat PDF plugin.

by fanf2 6y ago

One of the heaviest users of range requests is (or was) the Adobe Acrobat PDF plugin.

iudqnolq 6y ago

I'm surprised that works, iirc pdf isn't defined in order and can't be parsed streaming

kindall 6y ago
I think that's what the "optimize for Web" checkbox does
- IshKebab 6y ago
  Wow so it actually does something! I wish programs would use such vague descriptions. (Or more of them had helpful instant tooltips.)
  - maskros 6y ago
    Linearized (a.k.a. web optimized) PDF files only help for displaying the first page quickly. The rest of the file is still in pretty much random access order.
    - e12e 6y ago
      For what it's worth, there's a format for content like pdfs that's optimized for viewing on screens (as opposed to printing), djvu: https://en.m.wikipedia.org/wiki/DjVu https://en.m.wikipedia.org/wiki/DjVu Oh, wow initial release 1998,now I'm feeling a bit old...
tonyedgecombe 6y ago
Linearised PDF files are defined in order and can be read from the start. https://blog.idrsolutions.com/2010/02/linearized-pdf-files/ https://blog.idrsolutions.com/2010/02/linearized-pdf-files/

scottlamb 6y ago

Also .mp4 files. The format is designed for seekability, and browsers take advantage of this.

fy20 6y ago
Progressive JPEGs work well for this too, so you could have the same file used for a tiny thumbnail and large preview and full sized photo by sending different range requests. However you need to know how many bytes to request. I'm surprised this isn't used on mobile browsers to lower data usage. I'm sure with a little research you could figure out what a good mapping from pixel size to byte size should be to give good enough results.
- duskwuff 6y ago
  A browser doesn't have enough information to use this optimization. At the point where it's about to request an image, it doesn't know how large the resource will be, whether it'll be a progressive JPEG, or even whether it'll be a JPEG at all. Making range requests blindly would probably be a net loss -- for every progressive JPEG that the browser managed to save some time on, it'd have to make follow-up requests for many more non-progressive JPEGs, non-JPEG images, and progressive JPEGs which it didn't get enough data from on the first try.
  - _flux 6y ago
    You are correct. However, one could use this approach: download as usual, and in a streaming fashion process the data and if it's a progressive JPEG, you can close the connection before you have received everything; and then you can cache the prefix and later download the rest if needed. Fast clients will just swallow the whole file, while slow clients would be able to benefit from it. It wouldn't work for pipelined HTTP connections though without cancelling the whole pipeline, so maybe not a very practical solution given the performance benefit that already gives. And HTTP/2 maybe doesn't support cancelling a transfer either, so.. ? Maybe a direct "Accept" or "Prefer" header to indicate that it's enough to send just something useful for an icon would be a more ideal solution, but it would require server-side support.

0x0 6y ago

I remember putting together a sloppy http range implementation that initially only supported single ranges, it had quite the explosive effect on adobe reader when it didn't get the expected response to its multi-range requests :)