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+unsubscr...@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+unsubscr...@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.

Reply via email to