Re: New Version Notification for draft-kamp-httpbis-structure-01.txt (fwd)

On Thu, Nov 17, 2016 at 09:48:16AM +0000, Poul-Henning Kamp wrote:
> >On the other hand most of the time we don't care about the sub-microsecond
> >accuracy,
> 
> Trust me:  We will never care about *timestamps* with sub-microsecond
> resolution in HTTP headers. They barely make sense in the first
> place and transmission noise and and delays will totally swamp any
> information they might carry.

That's inexact, I've already seen people using timestamps as an easy
way to have unique IDs. Of course that's wrong but when the principle
is that once you're cycle-accurate you know you can't do two things
at once, it works as long as you don't have time jumps.

Note I'm *not* defending this misuse and not even advocating for
supporting it. I'm just saying that it's untrue that nobody cares.

> >Or maybe Poul-Henning's 15-digit number can solve it as well. But we must not
> >use it for any number as it would remove the ability to pass 64-bit integers.
> 
> 15 digits is enough for a Content-Length of a petabyte, I don't think
> anybody, now or in the future, will find that a sensible thing to do.

Well it's only one day of traffic at 100 Gbps, it could conceivably be
used after the next decade for file system replication over HTTP. And
if you manage a flat filesystem, you possibly at least want to be able
to use more than this in the Range header to seek on your storage.
There's nothing wrong with asking for one GB of data starting at 1.23 PB.
Multi-petabyte filesystem are still not common but I do know people who
use some already, especially in web hosting (and I'm pretty sure you
know some as well). We clearly see that the boundary between web and
storage sometimes is very thin and we must not prevent solutions from
emerging just because of protocol limitations.

> If you want to move cryptographic bits, there is a dedicated "blob"
> datatype for that.

Agreed.

Willy

Received on Thursday, 17 November 2016 10:18:02 UTC