esi:inline tags don't work

#1
Hello,

<esi:inline> tags don't seem to work. When surrounding something with <esi:inline></esi:inline>, you get a blank empty output.

<esi:include src="..." cache-control="no-cache"> works fine when you include a file.

But doing something like this to include a block of content:

<esi:inline cache-control="no-cache">
My ESI Content
</esi:inline>

doesn't work and outputs empty content.

Is this a bug in Litespeed?
 
#3
Hello,

I tried doing this:

<esi:inline name="something">
My data
</esi:inline>

and then include it with:

<esi:include src="something">

It works on the first pageload, however, it only uses the <esi:inline> block only on first pageload.

On subsequent pageloads it actually requests for the a url called "something" (which doesn't exist of course), resulting in a 404 error.

So this doesn't seem right. What is the purpose of esi:inline if you need a separate url anyway?
 
#5
I've already studied all of that.

I've also studied other documentation such as:
https://www.w3.org/TR/esi-lang/
http://pages.di.unipi.it/ghelli/didattica/bdldoc/A97329_03/caching.902/a95404/concepts.htm#1025318

by studying this documentation carefully, it seems that esi:inline are supposed to work independently, without needing to combine them with esi:include.

There is no mention of them needing to be combined with esi:include or requiring a separate url, it just says that whatever you put within <esi:inline></esi:inline> tags will be cached separately...
 
Last edited:

serpent_driver

Well-Known Member
#8
I don't kidding you! Why should I do that?! I only wanted to be safe don't tell you information you don't need, so please don't understand my reply wrong, okay?

As I already told you, the information about how to use ESI as inline tag isn't public and is undocumented, but it works because I developed it for a lot of applications. The only help I can give you is to combine both ESI tags, so <esi:inline works like a variable if src attribute for both tags have an existing and equal source.
 
#9
So again, what is the purpose of using esi:inline if you need a separate resource anyway?

What is a use case of esi:inline, if you also need a esi:include with a separate link? I don't understand that.
 
Last edited:

NiteWave

Administrator
#10
I created following test.php
Code:
<esi:inline name="something">
My data
</esi:inline>
<?php
echo $_SERVER['X-LSCACHE'];
?>
<hr>
<esi:include src="something">
<hr>
<esi:include src="something">
and in .htaccess
Code:
RewriteRule test.php - [E=esi_on:1]
then from browser, access /test.php, looks working. can you test and see if still issue ?
 
Last edited:
#11
@NiteWave

That's the same way I would expect them to use them, but add cache header to it:
(which is the whole purpose of esi blocks, to punch holes into caching)

Code:
<?php header('X-LiteSpeed-Cache-Control: public, max-age=60'); ?>
And it all falls apart from the second pageview (when cache is "hit")

It will look for an actual url /something

That seems to be the issue.
 
Last edited:

serpent_driver

Well-Known Member
#14
No, I can't, sorry. After I didn't get this information from LiteSpeed paid support, because they also don't know it, I worked on it for some weeks to find it out. Now, I know what has to be done. I can't give you this knowledge because that's part of my business. I hope you understand this?! If you want to pay for this knowledge make me an offer.
 

serpent_driver

Well-Known Member
#17
For everyone who is interested in how to get ESI work in non Wordpress application let's start an auction. You want to know what has to be done to get ESI work? The best price will solve it. I am open for requests.
 
Last edited:
#18
Here's an example of what it SHOULD look like according to what "kinda" works at the moment.

PHP:
<?php
header('X-LiteSpeed-Cache-Control:no-cache, esi=on');
header('X-LiteSpeed-Vary: value=istest');
?>
<!--esi
<esi:inline name="wow">
SOMETHING AMAZING
</esi:inline>
-->
<esi:remove>
ESI NOT ACTIVE
</esi:remove>
<!--esi
<esi:include src="wow" />
-->
Simple explanation: esi:inline is just like declaring a "variable" that you can "include" later.

Complete explanation: esi:inline seems to be a way to create a block that is not rendered yet by default and will only be rendered if called by name with a regular esi:include block - though Oracle's spec seems to advise otherwise. The esi:include block usually answers to a URL, but in this case it answers simply to a name, granted that the esi:inline block is provided in every response of your application.

BUT. There's just a little problem: it needs to re-request the full page. The Oracle's docs gives us some insight into the logic behind this and it appears that if we use headers in-script like my example, the esi:inline tag's cache-control attributes are ignored since the page request's ones prevail. I don't know if it's a bug in the implementation or if we're supposed to dance around this and output different max-age and varies, but until there's more clarification and examples floating around on how to properly use this, esi:include is definitely the easiest and best way to go for now.
 

mkaaaay

Well-Known Member
#19
Here's an example of what it SHOULD look like according to what "kinda" works at the moment.

PHP:
<?php
header('X-LiteSpeed-Cache-Control:no-cache, esi=on');
header('X-LiteSpeed-Vary: value=istest');
?>
<!--esi
<esi:inline name="wow">
SOMETHING AMAZING
</esi:inline>
-->
<esi:remove>
ESI NOT ACTIVE
</esi:remove>
<!--esi
<esi:include src="wow" />
-->
Simple explanation: esi:inline is just like declaring a "variable" that you can "include" later.

Complete explanation: esi:inline seems to be a way to create a block that is not rendered yet by default and will only be rendered if called by name with a regular esi:include block - though Oracle's spec seems to advise otherwise. The esi:include block usually answers to a URL, but in this case it answers simply to a name, granted that the esi:inline block is provided in every response of your application.

BUT. There's just a little problem: it needs to re-request the full page. The Oracle's docs gives us some insight into the logic behind this and it appears that if we use headers in-script like my example, the esi:inline tag's cache-control attributes are ignored since the page request's ones prevail. I don't know if it's a bug in the implementation or if we're supposed to dance around this and output different max-age and varies, but until there's more clarification and examples floating around on how to properly use this, esi:include is definitely the easiest and best way to go for now.
Again, this just seems like some kind of black magic. Why LS can't just provide a clear and effective working tutorial / example of this I'm not too sure. Perhaps they don't even understand it themselves?

We just use ajax requests to break through the cache and it works just fine for us.
 

serpent_driver

Well-Known Member
#20
Again, this just seems like some kind of black magic.
No, it isn't. It is neither black nor magic. It's just a question of understanding what ESI is good for and what has to be done to handle different content areas with different cache parameters, but within 1 request.

@davidwebca
Here's an example of what it SHOULD look like according to what "kinda" works at the moment.
This can't work. The header in your code only defines not to cache the requested URL and ESI should be ON, but nothing else. This has nothing to do with how ESI, regardless if inline or include, works.

The (mis)understanding of ESI:inline is mostly based on the word "inline" and expects that ESI:inline works like css or js code that is placed inline, but this is wrong. ESI:inline means that the ESI content is defined inline to use this defined content to include it. Therefore ESI inline has to be used together with ESI include. This also means that the variable isn't just a name, it has to be the path to an existing source that contains the content of the defined ESI area.

Why LS can't just provide a clear and effective working tutorial / example of this
Good idea, but there is no fixed method that works in all cases. For example, if your application has a template engine like Smarty the way to use ESI:inline is quite different as without template engine.
 
Last edited:
Top