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

[johnzeng]

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.

[Avraham Serour]

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

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