Monday, March 2, 2015

Re: i have a question ,whether Django’s cache framework can support transparent proxy deploy mode at isp environment ?

I don't see how they are related, each is on a different layer

The final user will request a page from the ISP, it may get from its own cache (squid) or request from your django server.

Your django server will produce the response, it may get it from its own cache (memcached) or process it

So in case squid decides to respond from its own cache, django will never see the request

On Mon, Mar 2, 2015 at 8:48 AM, 'johnzeng' via Django users <django-users@googlegroups.com> wrote:

Hello All :

i have a question , if possible , hope to get your advisement

whether Django's cache framework can support transparent proxy at isp environment ?

and our goal is Django's cache framework ( middle cache layer ) + Squid ( transparent proxy mode ) at isp environment ?


although i read the detail , but i can't confirm whether Django's cache framework can support transparent proxy deploy mode

https://docs.djangoproject.com/en/1.7/topics/cache/



   Downstream caches¶
   <https://docs.djangoproject.com/en/1.7/topics/cache/#downstream-caches>

So far, this document has focused on caching your /own/ data. But another type of caching is relevant to Web development, too: caching performed by "downstream" caches. These are systems that cache pages for users even before the request reaches your Web site.

Here are a few examples of downstream caches:

 * Your ISP may cache certain pages, so if you requested a page from
   http://example.com/, your ISP would send you the page without having
   to access example.com directly. The maintainers of example.com have
   no knowledge of this caching; the ISP sits between example.com and
   your Web browser, handling all of the caching transparently.
 * Your Django Web site may sit behind a /proxy cache/, such as Squid
   Web Proxy Cache (http://www.squid-cache.org/), that caches pages for
   performance. In this case, each request first would be handled by
   the proxy, and it would be passed to your application only if needed.
 * Your Web browser caches pages, too. If a Web page sends out the
   appropriate headers, your browser will use the local cached copy for
   subsequent requests to that page, without even contacting the Web
   page again to see whether it has changed.

Downstream caching is a nice efficiency boost, but there's a danger to it: Many Web pages' contents differ based on authentication and a host of other variables, and cache systems that blindly save pages based purely on URLs could expose incorrect or sensitive data to subsequent visitors to those pages.

For example, say you operate a Web email system, and the contents of the "inbox" page obviously depend on which user is logged in. If an ISP blindly cached your site, then the first user who logged in through that ISP would have their user-specific inbox page cached for subsequent visitors to the site. That's not cool.

Fortunately, HTTP provides a solution to this problem. A number of HTTP headers exist to instruct downstream caches to differ their cache contents depending on designated variables, and to tell caching mechanisms not to cache particular pages. We'll look at some of these headers in the sections that follow.



--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54F407CD.2030403%40yahoo.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFWa6tLjLcixbsx1f4pRBDDUMViodGua0YugHaoezhA%3DVOOvuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment