W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

Re: What constitutes protection [was: About using CORS]

From: Dirk Pranke <dpranke@google.com>
Date: Fri, 7 May 2010 10:32:41 -0700
Message-ID: <l2j3726d1bf1005071032s66abdceczb1501091f6c7325a@mail.gmail.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>
Cc: Anne van Kesteren <annevk@opera.com>, "Robert O'Callahan" <robert@ocallahan.org>, John Hudson <tiro@tiro.com>, Sylvain Galineau <sylvaing@microsoft.com>, "www-font@w3.org" <www-font@w3.org>
On Fri, May 7, 2010 at 8:41 AM, Levantovsky, Vladimir
<Vladimir.Levantovsky@monotypeimaging.com> wrote:
> On Wednesday, May 05, 2010 12:24 PM Dirk Pranke wrote:
>>
>> On Wed, May 5, 2010 at 5:19 AM, Levantovsky, Vladimir wrote:
>> > Yes, I can see this in their source, which seems to tell that this is
>> how they designed the site. It appears that they set up their own CDN
>> (or at least they have a server they named cdn.turner.com) where
>> stylesheets, javascripts and other resources live, and the content
>> comes from the main server cnn.com.
>> > I am curious about CDN like Akamai that creates and keeps multiple
>> local copies of site content. When I click on the link to a page and UA
>> receives the content back - what is the difference between the cases
>> when the response is coming from the original server vs. cached CDN
>> content? The content itself is the same, does UA actually see that it
>> is coming from CDN?
>> >
>>
>> The CDN usage I am most familiar with involves explicitly publishing
>> content from the origin servers to the CDN, which is then replicated
>> internally and distributed from the CDN nodes to the client machines.
>> CDNs (including Akamai) do not usually act as transparent caches. This
>> is mostly because CDNs don't work as well for dynamic content (it's
>> harder to cache it efficiently and correctly), and most of the
>> bandwidth on the web comes from files that are static and much more
>> cacheable. Akamai does (did?) have a technology called "edge serving"
>> that does claim to handle dynamic content generation, but I have no
>> experience with it.
>>
>> Also, it's easy to get confused here because Akamai and other CDNs
>> because they often provide a form of load-balancing DNS as a service
>> as well. So, you might use Akamai to determine which actual server
>> gets to respond to "www.cnn.com", making it look like Akamai is
>> somehow acting as a cache for "www.cnn.com", but it isn't.
>>
>> I will note, lastly, that it's not like there's a "this content is
>> coming from a CDN" header in the reply; to the client, they just look
>> like regular HTTP replies.
>>
>> Of course, we wander off-topic for this list; if you have further
>> questions, I'd be happy to try and answer them directly, although I'm
>> not a CDN expert, I just have some experience with them.
>>
>
> Dirk,
>
> Thank you very much for your response. The reason I am asking these questions is because CDN has been brought up couple of times as an argument against using same-origin restriction and CORS. I am trying to understand if there really is an issue with CDN that would prevent SOR and CORS from working properly. It seems that if there was an issue it would be an obstacle for CORS regardless of what it is used for, but so far I simply don’t see it - from my admittedly non-expert POV on this it seems that when UA is trying to access www.cnn.com it would get back the same content regardless of what actual server got to respond to the request, and the response would come back as if it *is* from www.cnn.com, from UA point of view. Did I miss anything?

 I can imagine that someone might object that you can't specify
additional headers from a request served by a CDN (just like you can
imagine web servers that might be unable to add headers), but I'm not
aware of any real-world examples of that with one of the more popular
CDNs.

I am not aware of any other issues,

-- Dirk
Received on Friday, 7 May 2010 17:33:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC