JC, I would encourage you to get more familiar with the HTTP 1.1 spec with
regard to your claim of copyright infringement. I will summarize my
interpretation of a part of it here.
When someone provides HTTP content, they are agreeing to the protocols
governing the transmission of that content, which includes caching and
transformation of that content by proxy systems.
Fortunately, the spec provides for netizens to send Cache-Control headers
that can exclude their content from storage on and transformation by
proxies. These headers are outlined in the spec, so I'm not going to
detail them here. But as far as I have been able to tell, AOL is in
compliance with the Cache-Control specs.
I see it like this: Not including Cache-Control headers and claiming
copyright infringement is like publishing a novel in English and
distributing it in the U.S., but printing the copyright notice in Chinese.
Clients accessing your content must be able to understand that you do not
wish for it to be transformed; and since proxies speak HTTP, content
providers need to include the appropriate HTTP headers so the proxies
understand their wishes. Conversely, when a content provider excludes
Cache-Control headers, ISPs have free reign to handle the content and
deliver to the end user in whatever way they wish, as long as that way
falls within the HTTP 1.1 spec.
As an aside, I have a special folder on my Apache server for Jessica
Stover's website where I keep images that I don't want to be compressed by
all of these web accelerators (Earthlink and NetZero have them too, not
just AOL). In that folder's .htacccess file, I have included instructions
to send the "Cache-Control: No-Transform" header on all files requested
via HTTP within that folder; those images are not modified in any way by
the various web caching systems out there -- the end user gets the
identical image to what is stored on my server.
~ The Gunn
webmaster@jessicastover.com
I wouldnt have thought what happens at Layer7/8 (ie the production, copyright
and distribution of the image) is related to whats going on at Layer4/5 (http)
in this context.
I recall this caching argument from a while back, but I dont think the subject
of altering the data was in the discussion, it was around the legality of making
and storing copies of copyrighted material without explicit consent.
As I think the caching debate was settled without incident I think people
publishing copyrighted material are happy with the situation, your suggestion
that they can add in no-cache is probably not something they want to do (nor
would ISPs want that in view of the performance effect it would have on their
cache hit rate)
Steve
your suggestion that they can add in no-cache
is probably not something they want to do (nor
would ISPs want that in view of the performance
effect it would have on their cache hit rate)
Steve, perhaps you misinterpreted my posting, or missed the quote from JC
that I referenced at the bottom. If you re-read it, you'll see that I made
no such suggestion (and I did not even mention "no-cache" specifically,
only no-transform).
What I am saying is that a specific allegation made by another poster to
this list (quoted again below) has no basis because the HTTP spec provides
mechanisms for ensuring copyrighted material is not transformed or stored
by proxy networks.
I would never suggest to anyone to arbitrarily put a Cache-Control:
no-cache header on their content. Cacheing by ISPs is a great thing for
everyone and a content provider who uses no-cache is only costing
themselves money in bandwidth.
But, on the flip side, there are a myriad of situations that necessitate
the need to control the way in which content is cached or (more commonly)
compressed/transformed by a proxy; for example, high-res medical x-rays
and other confidential information, consumer purchased high-res images and
other copyrighted information purchased by the end user, or trademarked
logos.
For situations like these, I do think that it's important for content
providers to know they have the ability to directly limit what the caches
can do by reasonably implementing the appropriate Cache-Control headers.
~ The Gunn
webmaster@jessicastover.com
> AOL is copying and redistributing the image in a new format *without the
> permission of the copyright holder* in a way that A) makes AOL money
and B)
<snipped since its kinda long>
Just got done working with my mother's machine again, and have been watching
her and a bunch of other people who use AOL 9.0 and some who use 8.0.
Something over the past week alone has definately happened in regards to the
AOL TopSpeed stuff. I've got a situation with more then 75% of the people
I've tested, that they have problems running java applets (including AOL's own
link into pogo games) in AOL 9.0 GM (that they are distributing to end users).
When the user switches to AOL 8.0, the problem exist. When the user uses IE
separate from AOL, the problem does not exist. There are other issues
developing as well - random freezing of java games for example. Once again,
this only happens in 9.0.
This was working fine two weeks ago on all of these people's machines.
Of course, this is increasing my daily workload, as I now have users having
problems that I need to sit and try and diagnose. I've been telling people to
use AOL 8.0 or IE if they want to play games.
But, yes, there appears to be a problem somewhere with this TopSpeed stuff
that people have been noting complaints about.
Sorta off topic, but alot of people here also do support for this kind of
stuff, and would like to get some feedback as to what others are seeing with
their end users. I have a sinking feeling that when I take the time to file
an official bug report/issue, they will tell me 'reformat and reinstall'.
Brian,
I have some friends in the web proxy group at AOL, if you can send me (or
post to this list) some urls that are breaking, they can take a look for
you.
According to them, if the java problem is happening on AOL 8.0 as well as
9.0, then it's not a TopSpeed issue (TopSpeed is just an executable that
runs in tandem with 9.0), but could be some other client-related problem..
And in response to Rob's suggestion to use SSL instead of implementing
cache-control, it would be a pretty wasteful implementation of SSL if its
purpose is solely to prevent a proxy from recompressing your images.
-- The Gunn
webmaster@jessicastover.com
"The Gunn" <webmaster@jessicastover.com> writes:
And in response to Rob's suggestion to use SSL instead of implementing
cache-control, it would be a pretty wasteful implementation of SSL if its
purpose is solely to prevent a proxy from recompressing your images.
To clarify (for list readers who are out of the loop because I made
the point in a private communication) I suggested use of SSL in the
cited hypothetical case of "for example, high-res medical x-rays and
other confidential information, consumer purchased high-res images and
other copyrighted information purchased by the end user". Given the
HIPAA and e-commerce implications of the two named cases, using SSL
would seem to be a no-brainer, and effectively renders the issue of
cache-control moot.
I also suggested that "The Gunn" read http://www.nanog.org/aup.html
item #7 and begin posting with an account that has a real name on it.
---Rob