I think if you're going to go the route of using ESI to build partial page
components (like the header and footer) and the assemble and steam with
varnish if it ends up being possible, that you will not be able to go a non
ESI route as easily.

Though, I guess the system would still cope, and worst case you could use
the Symfony 2 AppCache layer?


t

On Tue, Nov 23, 2010 at 01:41, Henrik Bjornskov <[email protected]> wrote:

> isnt this what the _internal route does?
>
> On 22 Nov., 12:53, Lukas Kahwe Smith <[email protected]> wrote:
> > On 22.11.2010, at 12:22, Fabien Potencier wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > The main page AND all ESI have their own URLs. Let's take an example to
> make things clearer:
> >
> > > I have a pagehttp://a.com/awith 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).
> >
> > Right. I guess that is what you were saying all along, but that is also
> what I was trying to say. But it seems like everybody seemed to not
> understand what I was saying and all the disagreeing confused me :)
> >
> > But this gets me back to the point of "implicit routes".
> > Obviously when my app is working without ESI I might not need a "
> http://a.com/b"; route. So when Symfony2 generates the ESI tag it should
> (not sure if it already does, but this is again something that I mentioned
> before and people seemed to disagree) generate  "
> http://a.com/allesigoeshere?controller={some encoding of the target
> controller}" that is only reachable from a the proxy. I dont want to have to
> manually have to create the required routes, nor do I want them to even be
> accessible to end users. Again, I kind of expect this to already be the
> case, but I didnt see it anymore in the documentation.
> >
> > 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]<symfony-devs%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>

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

Reply via email to