Now that we have this fun new router system, we need to be looking toward leveraging the more advanced parts of HTTP with it. Specifically, caching for subrequests. For that, Symfony already provides much of the plumbing for us:

http://drupalcode.org/project/drupal.git/blob/refs/heads/8.x:/core/lib/D...

That allows for an _internal URL prefix that maps to a route that knows how to handle subrequests. Effectively, /_internal/some_controller/stuff becomes the "native" URI of blocks. Once such is completed, we have a URI at which we can make subrequests using the HttpKernel::render() method, which is what does the magic of ESI, hInclude, etc.

We want! First, though, if we want to use that code we need to add a generator: #1705488: Implement a generator for Drupal paths

*sigh*

Then we can add a route for _internal (with toggle to enable?), and build coolness on top of that.

Comments

Anonymous’s picture

Anonymous (not verified) commented

so '_internal' means 'this is not really an http request'? instead, it just uses http-like language to refer to something that is not at all like http? and our caching of this not-at-all-like-http thing is constrained to http caching?

and the references to ESI - are we talking real ESI? with, like, real http requests? or are we just using that as our mental model, even though it's nothing like what's going to happen in most drupal sites?

yes, these questions are intended to spark some discussion. i really don't like this model, at all. if i'm smacked down, so be it, i'm not going to block anything, but i want to make clear my objection.

Crell’s picture

Crell commented

beejeebus: See the render method, here:

http://drupalcode.org/project/drupal.git/blob/refs/heads/8.x:/core/lib/D...

This "internal URL" is used for:

1) ESI strings in the output
2) hInclude strings in the output

If you call render() and neither ESI nor hInclude are available, Symfony issues a subrequest. If either of those options is true, Symfony injects the appropriate internal-path-using string, which will then get requested as a new *master* request.

Whether the ESI handling engine is Varnish, Symfony's in-process HttpCache implementation, or some other proxy server is irrelevant to this process, must be irrelevant to this process, must be kept hidden from code that benefits from this process, and is completely off topic for this issue. :-)

Anonymous’s picture

Anonymous (not verified) commented

"If you call render() and neither ESI nor hInclude are available, Symfony issues a subrequest. If either of those options is true, Symfony injects the appropriate internal-path-using string, which will then get requested as a new *master* request."

wow. so in the non-ESI (aka overwhelmingly common) case, Symfony builds fake http requests and calls HttpKernel::handle(). in a method called render(). i'll shut up now, carry on.

dawehner’s picture

dawehner
Primary language German
commented

It seems to be that we don't really need this once #1945024: Remove subrequests from central controllers and use the controller resolver directly. is in, as the fragment system does that automatically.

Crell’s picture

Crell commented
Status: Active » Closed (won't fix)

Agreed. The strategy has shifted too much for this issue to still be relevant.