Comment by cbr | Hacker News Reader

Comment by cbr | Hacker News Reader

They claim this is good for responsive images:

    The download or file read operations can be stopped
    as soon as sufficient detail is available, and if
    needed, it can be resumed when for whatever reason
    more detail is needed.
     -- http://flif.info/responsive.php

Unfortunately that's not how HTTP works. Your browser opens several connections to a website, and makes requests for resources. Each connection is in use until that resource is fully loaded, at which point you can send a request for another resource up that connection. Yes, the browser could close the connection after it has received enough of the image for the desired quality, but there's a lot of overhead in setting up a new connection, including some round trips, and so that is probably a net loss.

The JPEG image format also supports progressive images, in browsers today, and no one has figured out how to use that for single-file responsive images yet.

(You might be able to do something in HTTP/2 where you set the priority of the stream to 0 after you have enough of it for your needs, but I don't think anyone has gotten this working yet.)

Could use range requests (RFC 7233), albeit with some overhead.

To use a range request the client needs to know what range of bytes it needs. Currently your html is:

  <img src="foo.jpg">

Now, let's say foo.jpg is progressive, and if you examine the file you can see that you need H bytes for the header, N bytes for the first layer, M for the next, and so on. Then you could mark up the html as:

  <img src="foo.jpg"
       bytes-1x="(H+N)"
       bytes-2x="(H+N+M)" ...>

but that's a huge pain to generate by hand, and people like to compose html by hand.

If we want something that can catch on, it needs to be something where browsers and servers can negotiate in a fully automated way. Or we can just use srcset/picture.

Could leverage HTTP Client Hints: https://github.com/igrigorik/http-client-hints

Client hints are a nice solution, but they don't require an image format stored in progressive order. They work fine with storing multiple copies on disk, and the overhead of low-rez versions server-side is minimal.

Why do you say it is a net loss? Maybe the server could signal the end of file based on some request parameters (the resolution of the image).

Yes, handling it on the server side sounds like a reasonable workaround. For example photo.flif?res=1x returns Content-Length: 100000, and photo.flif?res=2x returns Content-Length: 200000, with both returning data from the same file.

I say net loss because with current http the loss of closing the connection is typically much higher than the loss of downloading more bytes than you need. Connection reestablishment needs a lot of round trips.

HTTP supports range headers to get a portion of a file...

Reply on news.ycombinator.com