[148166] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] HTTP should be deprecated.

daemon@ATHENA.MIT.EDU (=?UTF-8?Q?Lodewijk_andr=C3=A9_de_l)
Wed Nov 13 14:55:17 2013

X-Original-To: cryptography@metzdowd.com
In-Reply-To: <52829FA4.7060804@witmond.nl>
From: =?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?= <l@odewijk.nl>
Date: Wed, 13 Nov 2013 18:01:40 +0100
To: Guido Witmond <guido@witmond.nl>
Cc: cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

--===============5572452988477703799==
Content-Type: multipart/alternative; boundary=047d7b604cfe704bfa04eb11ec66

--047d7b604cfe704bfa04eb11ec66
Content-Type: text/plain; charset=UTF-8

2013/11/12 Guido Witmond <guido@witmond.nl>

> The era of ISP-operated caches is past.
>
> With Netflix and other movie streaming sites reaching 50% traffic mark,
> that's out of the league for ISP's. Both Netflix and Youtube (Google)
> offer free (or cheap) caches for their contents to ISPs.
>

Being fair that means that the corporations help the ISPs have caches. That
50% is mostly added traffic (didn't reduce other traffic). It would be very
interesting to know if ISPs still cache commonly accessed cache-able files.
They might not do it for a wealth of peering agreements and cheap bandwidth
mostly consumed by those companies that remove the need by having CDNs.


> The rest of the web out there is so full of advertisements that those
> operators don't want caches as it diminishes their 'tracking' abilities.
> In fact, the content of the page can be cached, the advertisement
> require a new connection each time. I'd say that the advertisements are
> more costly (in network resources) than the content.
>

Advertisements can (are, usually) served through iframes or similar
constructs, meaning the page with the adverts can be cached. The adverts
themselves fly in through their regular channel.

It is true that many websites are dynamic nowadays. I think that'll change.
The web is moving towards web-applications. Those applications have shared
libraries and are for a large part static. It simply makes very little
sense to work against caches.

The problem is that the current http-infrastructure is not good at
> specifying what can be cached and what not.
>

TTL headers aren't good enough?

--047d7b604cfe704bfa04eb11ec66
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013=
/11/12 Guido Witmond <span dir=3D"ltr">&lt;<a href=3D"mailto:guido@witmond.=
nl" target=3D"_blank">guido@witmond.nl</a>&gt;</span><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">

<div id=3D":4mx" style=3D"overflow:hidden">The era of ISP-operated caches i=
s past.<br>
<br>
With Netflix and other movie streaming sites reaching 50% traffic mark,<br>
that&#39;s out of the league for ISP&#39;s. Both Netflix and Youtube (Googl=
e)<br>
offer free (or cheap) caches for their contents to ISPs.<br></div></blockqu=
ote><div><br></div><div>Being fair that means that the corporations help th=
e ISPs have caches. That 50% is mostly added traffic (didn&#39;t reduce oth=
er traffic). It would be very interesting to know if ISPs still cache commo=
nly accessed cache-able files. They might not do it for a wealth of peering=
 agreements and cheap bandwidth mostly consumed by those companies that rem=
ove the need by having CDNs.<br>

</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv id=3D":4mx" style=3D"overflow:hidden">

The rest of the web out there is so full of advertisements that those<br>
operators don&#39;t want caches as it diminishes their &#39;tracking&#39; a=
bilities.<br>
In fact, the content of the page can be cached, the advertisement<br>
require a new connection each time. I&#39;d say that the advertisements are=
<br>
more costly (in network resources) than the content.<br>
</div></blockquote></div><br></div><div class=3D"gmail_extra">Advertisement=
s can (are, usually) served through iframes or similar constructs, meaning =
the page with the adverts can be cached. The adverts themselves fly in thro=
ugh their regular channel. <br>

<br>It is true that many websites are dynamic nowadays. I think that&#39;ll=
 change. The web is moving towards web-applications. Those applications hav=
e shared libraries and are for a large part static. It simply makes very li=
ttle sense to work against caches.<br>

<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb=
(204,204,204);padding-left:1ex" class=3D"gmail_quote">The problem is that t=
he current http-infrastructure is not good at<br>
specifying what can be cached and what not.<br></blockquote><div><br></div>=
<div>TTL headers aren&#39;t good enough? <br></div></div></div>

--047d7b604cfe704bfa04eb11ec66--

--===============5572452988477703799==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============5572452988477703799==--

home help back first fref pref prev next nref lref last post