The main page AND all ESI have their own URLs. Let's take an example to
make things clearer:
I have a page http://a.com/a with 1 included ESI. Here is the content of /a:
<html>
Some content
<esi:include src="http://a.com/b"; />
</html>
As you can see, the ESI has its very own URL (http://a.com/b).
When Varnish gets the /a page:
* it first looks in its cache and only calls the backend if necessary;
* then, it parses the page for ESI tags and gets the /b page content
(either from its local cache or from the backend);
* eventually, it assembles the page and returns it to the browser.
Note that the pages cannot be compressed by the backend (if they are,
Varnish won't be able to parse the content for ESI tags). But you can
still put another web server in front of Varnish for the compression
(nginx > varnish > apache/PHP).
Fabien
--
Fabien Potencier
Sensio CEO - symfony lead developer
sensiolabs.com | symfony-project.org | fabien.potencier.org
Tél: +33 1 40 99 80 80
On 11/22/10 11:50 AM, Lukas Kahwe Smith wrote:
On 21.11.2010, at 20:43, Fabien Potencier wrote:
ok .. so i think what isnt clear to me yet is what is the url set for
the given ESI include: does using ESI then generate some special
route for just "MyBundle:Page:welcome" going by the above example
that is requested if this ESI block ever does stale?
aka even of "MyBundle:Page:welcome" is usually always embedded on
other pages and there isnt any explicit route to just get
"MyBundle:Page:welcome", using ESI such an implicit route is
generated in order to be able to fetch just "MyBundle:Page:welcome".
MyBundle:Page:welcome is a normal URL; there is nothing special. It can
have its own URL or an "internal" one only depending on the security
access control you configure for it.
The reverse proxy calls this page when it expires.
controllers do not have url's (well IIRC there is some mode where routes are
implicitly defined).
so my confusion is that everybody made it sound like ESI blocks do not have
url's of their own, after reading the spec, I am pretty sure though that this
needs to be the case.
so if I have a homepage with 3 ESI blocks A, B, C it means that I need to have
a route for the homepage as well as the content for ESI block A, B, C which
return the HTML fragments for only these blocks.
now varnish will assemble the homepage from with these blocks either from its
cache or by executing parallel requests (*). this is already quite nice to
speed up delivery of content not only from a cache, but also being able to
parallelize the generation of the dynamic bits.
now it seems to me like it should be fairly easy to then have some marker that
tells the Symfony2 ESI layer to return once all blocks to a given point have
been returned.
now how it will work in varnish is still not clear and form some more
discussions with the developer it seems like 3.0 (expected for january 2011)
will only bring the necessary infrastructure changes and the actual support for
streaming responses will only come in 3.1 (no release date planned yet, but
streaming support could hit trunk right after 3.0 is out).
so my conclusion:
i think we should ensure that we can support streaming responses in the ESI
layer, but lets wait for now. but maybe we can create a wiki page or a ticket
for this in the mean time?
regards,
Lukas Kahwe Smith
[email protected]
(*) there could be some troubles if the blocks actually have dependencies, like
one block writing a new news item and another one generating a sidebar with the
latest news. but i guess one just needs to be cautious especially when using
ESI in POST requests.
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
