On 22.11.2010, at 11:50, 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.
so Varnish 3.0 reached beta1 http://varnish-cache.org/trac/browser/doc/changes.rst note gzip with ESI is now natively supported more on top if the addition of streaming support. i am not sure however if this is supported for ESI already. mainly because they call it "Preliminary streaming support, both on miss and on pass." in the short release notes: http://www.varnish-cache.org/releases/varnish-cache-3.0-beta1 So it might come out in 3.1 as I was originally told. Just a pitty that it seems the 3.0 release has slipped quite a bit. But all of this means that through Varnish ESI Symfony2 will get support chunked response without the limitations that Ruby on Rail 3.1 has to add to support it: http://weblog.rubyonrails.org/2011/4/18/why-http-streaming Though of course Rails users can also just use Varnish, but unless Rails also adds native support for ESI it will be more work for them to use it. regards, Lukas Kahwe Smith [email protected] -- 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
