You still seem to be missing the point. Cache-Control as implemented commonly, and by your description, will instantly serve every request the new file as soon as a new file is available. It takes into account exactly one variable: file age.
The algorithm I describe takes into account variables which affect current system loading, and returns a "no, try again later", even when the file is actually different, because the server is trying to conserve some resource (usually in such cases it is bandwidth). Like I said, this can be done with etags, but a more explicit form of control is nicer. Which brings us to this:
> this allows better control should the client ignore the etags
by making the whole client use a custom communication channel? I'd expect ensuring the client correctly speaks HTTP would be easier than implementing a custom client from scratch.
A client speaking proper http would be perfect for this. So point your http client to:
domain.com/getlatest
if there is a token available, respond with a:
307 domain.com/reallatest?token=foo
If no token is available and no if-modified headers are sent, reply with:
503 + Retry-After N
if there is not a token available, and the requestor supplied approrpiate if modified headers respond with a:
304 + cache control for some scheduled time in the future (which the client can ignore or not)
Of course that last condition is strictly optional and not really required, since then it would be abusing cache control, rather than the using 503 as intended.
(also note, a request to domain.com/reallatest with an invalid token or no token could result in a 302 to /getlatest or a 403, or some other form of denial, depending on the specifics of the application).
edit: Strictly speaking, the multiple url scheme above isn't even needed, just a smart responder associated with the 503 is needed, however the url redirect method above was there because there may be a larger application context around system, in which getlatest does more than just serve the file, or in which multiple urls would redirect to reallatest, both easily imaginable situations.
> If no token is available and no if-modified headers are sent, reply with:
> 503 + Retry-After N
That's cool. There's still no reason for the second url and the 307, and you're still getting hit with requests so you're not avoiding the request load, only the download. You're smoothing out bandwidth, but not CPU & sockets.
This is sort of true. I don't know of a way to simply limit the number of incoming sockets without getting a lot of ISP level involvement or just outright rejecting connections. It does limit the number of long-lived sockets for file transfer. On static file serves, I am assuming the cpu has plenty of spare capacity for doing the algorithm, so I am not worried about that. Finally I am assuming the limiting factor is bandwidth here, so bandwidth smoothing the main goal.
The algorithm I describe takes into account variables which affect current system loading, and returns a "no, try again later", even when the file is actually different, because the server is trying to conserve some resource (usually in such cases it is bandwidth). Like I said, this can be done with etags, but a more explicit form of control is nicer. Which brings us to this:
> this allows better control should the client ignore the etags
by making the whole client use a custom communication channel? I'd expect ensuring the client correctly speaks HTTP would be easier than implementing a custom client from scratch.
A client speaking proper http would be perfect for this. So point your http client to:
domain.com/getlatest
if there is a token available, respond with a:
307 domain.com/reallatest?token=foo
If no token is available and no if-modified headers are sent, reply with:
503 + Retry-After N
if there is not a token available, and the requestor supplied approrpiate if modified headers respond with a:
304 + cache control for some scheduled time in the future (which the client can ignore or not)
Of course that last condition is strictly optional and not really required, since then it would be abusing cache control, rather than the using 503 as intended.
(also note, a request to domain.com/reallatest with an invalid token or no token could result in a 302 to /getlatest or a 403, or some other form of denial, depending on the specifics of the application).
edit: Strictly speaking, the multiple url scheme above isn't even needed, just a smart responder associated with the 503 is needed, however the url redirect method above was there because there may be a larger application context around system, in which getlatest does more than just serve the file, or in which multiple urls would redirect to reallatest, both easily imaginable situations.