W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Major errors in Caching and Cache-Control

From: Benjamin Franz <snowhare@netimages.com>
Date: Wed, 5 Jun 1996 13:33:20 -0700 (PDT)
To: jg@w3.org
Cc: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>, Jeffrey Mogul <mogul@pa.dec.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.LNX.3.93.960605132045.13252B-100000@ns.viet.net>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/805
On Wed, 5 Jun 1996 jg@w3.org wrote:

> There are two issues here:
> 1) what content authors can/need to say about how their content
> might be modified.
> 2) what HTTP allows/disallows in the protocol.
> To begin with, believing that all web stuff uses HTTP is a mistake;
> in particular, we'd like to eventually transition to other transport
> protocols, which may potentially take a more liberal view of content.
> It seems perfectly reasonable to me, particularly working for an international
> company as I do, to think that a set of proxies that
> transformed all GIF files to JPEG before transporting them across the
> expensive interoceanic links would BE A GOOD THING.  This may very well
> save me 2X on bandwidth right now.  Not a trivial deal at all.  I'd
> like my cache to be more efficient as well, and would like to store the
> data that way.

As a site developer I can tell you that silent content transformation is
*EVIL*. AOL was converting JPEGs to ART silently this way. Caused one of
my clients some grief as people on AOL downloaded files with a .jpg ending
and their viewers puked on it. Fortunately I was aware of the possibility
that AOL might be doing this and could guide the user in *disabling* the
JPEG->ART transformation. I am NOT in favor of content transformation
by proxies in the least. The legal ramifications alone are potentially

> It seems to me that the sooner we get "no-transform" into the hands of
> content authors the ability to say that this data better not be messed
> with between me and the end user, the better.  I'd sure not want my
> medical images so messed with.  People will (already are) experimenting
> with such data transformation in research contexts; wouldn't surprise me
> (might even take bets on) people doing it for product.

See above.

> I think that "no-transform" is worth having, even if HTTP forbids transformation
> (for which I think forbidding tranformations would be draconian, and people
> who run corporate or island cache systems would not thank you for).

I think that transformations *should* be forbidden. You want to break
protocal inside an organization fine - but don't tempt fate by allowing it
on the big bad net.
> Note that adding it later is closing the barn door after the animals escape;
> we'd like content authors to start now, so that such proxy systems might
> be deployed in the future, while allowing critical data to be marked.

If this allowed at all, it should be in the affirmative mode: 
transform-allowed. The default without question should be no content
transformations allowed unless explicitly stated otherwise. At no point
should intermediates be allowed to transform content unless I
affirmatively give them permission to do so.

Benjamin Franz
Received on Wednesday, 5 June 1996 13:26:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC