Textpattern Forum

You are not logged in. Register | Login | Help

#21 2005-05-19 02:22:12

soulship
Member
From: Always Sunny Charleston
Registered: 2004-04-30
Posts: 669
Website

Re: asy_jpcache 0.9.8 - Fast Full Page Caching

Thanks for tweaking this, Sencer. For some reason I can’t tell if this is working on one of my textdrive accounts, any hints on testing to make sure it is active?

Offline

#22 2005-05-19 03:36:09

Etz Haim
Plugin Author
From: Karlstad, Sweden
Registered: 2005-01-24
Posts: 262
Website

Re: asy_jpcache 0.9.8 - Fast Full Page Caching

Soulship: You can examine your response headers to see if X-Cache: asy_jpcache v2 – file is returned. You may use an online tool such as this one.

Offline

#23 2005-05-19 06:17:04

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 605
Website

Re: asy_jpcache 0.9.8 - Fast Full Page Caching

From the bottom of the help file

//Content-Sniffing to set correct Content-Type, because headers were not available

With version 0.8, I have a small problem with those headers.

I’m serving application/xhtml+xml for modern browsers via my plugin. This sets the headers (and gzip compressing) correctly.
Once asy_jpcache is activated, it overrides any header that the plugin sends, and serves everything as text/html (I haven’t checked the feeds yet).

  • I’ve disabled gzip in jpcache-config.php, no problems with that.
  • The mime type header proves harder to deal with. commenting out all those lines after the comment quoted above doesn’t help.

What actually happens is this: when the page is first requested, I get an error (and a blank page) – xml error in Firefox 1.0+, Safari returns this: ‘The error was: “bad server response

Offline

#24 2005-05-19 07:40:21

Sencer
Developer emeritus
From: cgn, de
Registered: 2004-03-23
Posts: 1,803
Website

Re: asy_jpcache 0.9.8 - Fast Full Page Caching

Hi phiw13,

I think I understand why the things are happening that are happening. I am just not sure wether there is a best way to handle them.
My proposal may seem a bit “intrusive”, but maybe someone else can come up with a better idea:

1) IMHO you should deactivate your plugin, and let jpcache handle the compression. Reason: For ob_gzhandler (or any gzip compression) to work, you have to send the correct header. If you turn off gzip in jpcache those headers are not being sent. And there is actually a “hack” in jpcache to uncompress compressed content before dealing with it, because the default textpattern gzips feeds, but not regular pages. Turning off gzip in asy_jpcache makes (IMHO) only sense, when you use mod_gzip/mod_deflate in Apache, or zlib.output_compression in php.ini.

2) Change the saved default header in file.php on line 104 (after the //Content-Sniffing…)
Find:
<notextile><pre> else $cachedata[“jpcachedata_type”] = ‘text/html; charset=utf-8’;
</pre></notextile>
change into:
<notextile><pre> else $cachedata[“jpcachedata_type”] = ‘application/xhtml+xml;charset=utf-8’;
</pre></notextile>

I think that should work. Reason: The first two “ifs” before that check for feeds, if they are not then this content-header gets saved and will later be served. If you comment those lines out, PHP will just send whatever default Content-Type is set in php.ini.

- The other solution would be to switch to a host that has PHP5, which I know is probably not an option in most cases. (If it is, Textdrive has PHP5;) )

Possible Problem: The header is saved in the cached file. If you only want to serve the xml-mimetype to those browsers that understand it, and text/html otherwise, you will also have to change the method “jpcache_restore” (in the same file.php) to not just read the type, but to check it against the Accept-Headers of the Browser.

If that all would solve the problem, I would adjust the code for the next release.

Questions: If an HTML Document starts with:
<notextile><pre>
<?xml version=“1.0” encoding=“utf-8” ?>
<!DOCTYPE
</pre></notextile>
will it always be sent as “application/xhtml+xml;charset=utf-8” (if we assume the browser understands it)? If a document should be served with that mimetype, does it always begin with that snippet?

edit: Nevermind my questions, I am looking at the code of your plugin right now. Thinking how best to take care of that…

Last edited by Sencer (2005-05-19 08:37:01)

Offline

#25 2005-05-19 08:44:01

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 605
Website

Re: asy_jpcache 0.9.8 - Fast Full Page Caching

> Sencer wrote:

- IMHO you should deactivate your plugin, and let jpcache handle the compression. Reason: For ob_gzhandler to work, you have to send the correct header. If you turn off gzip in jpcache those headers are not being sent. And there is actually a “hack” in jpcache to uncompress compressed content before dealing with it, because the default textpattern gzips feeds, but not regular pages. Turning off gzip in asy_jpcache makes (IMHO) only sense, when you use mod_gzip/mod_deflate in Apache, or zlib.output_compression in php.ini.

Turning off the ob_gzhandler in the plugin (and for my css files, which are served separately fom txp via a php file) wouldn’t be a problem at all. The ob_gzhandler is in the plugin, because my host doesn’t support mod/gzip yet.
When first tested, it was faster to disable that one line in your php files, ‘cuz I had them open in front of me :-)))). Call me lazy…
I was just a bit playing while dealing with some client issues which are pretty boring.

- Change the saved default header in file.php on line 104 (after the //Content-Sniffing…)
Find:
snipped
‘application/xhtml+xml;charset=utf-8’;

Here we’ll run into problems. Serving application/xhtml+xml to Gecko browers and to Opera 7.54+ is OK, Safari isn’t too happy, and then that browser ‘with dropping market share’ (aka IE) isn’t happy at all. Hence the content negotiation in the plugin.

Possible Problem: The header is saved in the cached file. If you only want to serve the xml-mimetype to those browsers that understand it, and text/html otherwise, you will also have to change the method “jpcache_restore” (in the same file.php) to not just read the type, but to check it against the Accept-Headers of the Browser.
If that all would solve the problem, I would adjust the code for the next release.

If that would be possible. I haven’t had a look at that part of the file yet.
The one thing that have to be kept in mind here, don’t force the TXP user to use application/xhtml+xml as it is tricky. You probably know that. The casual user doesn’t.

Questions: If an HTML Document starts with:

<notextile><pre>
<?xml version=“1.0” encoding=“utf-8” ?>
<!DOCTYPE
</pre></notextile>
will it always be sent as “application/xhtml+xml;charset=utf-8” (if we assume the browser understands it)? If a document should be served with that mimetype, does it always begin with that snippet?

Not necessarily, the xml declaration is optional anyway. I add it, in case a person want to save the page locally. The difference I use is in the DTD: xhtml1.1. or xhtml 1.0. But I know some TXP user who serves xhtml 1.0 anyway (UberNostrum), but a different mime-type.
As you see in the plugin code, the difference is all based on the accept-headers. It is all explained on this page, and a couple of forum threads around here.

edit: Nevermind my questions, I am looking at the code of your plugin right now. Thinking how best to take care of that…

Me too, although I won’t have time to really concentrate on this atm. And I’m looking forward to any idea that might come.

BTW, for a plain vanilla TXP site, your code does work very nicely. I’ve put it for a friend site, and he did notice a difference.

edit I disabled the ob_gzhandler in the plugin and the same in the php file that handles my stylesheets. Enabled asy_jpcache. This part works perfectly. On first load, I get the correct mime-type. A reload however, as expected, gives text/html.

Last edited by phiw13 (2005-05-19 09:18:33)

Offline

#26 2005-05-19 11:54:24

soulship
Member
From: Always Sunny Charleston
Registered: 2004-04-30
Posts: 669
Website

Re: asy_jpcache 0.9.8 - Fast Full Page Caching

Thanks Etz, It’s running. I’ll have to save that link.

Offline

#27 2005-05-19 12:02:29

edburdo
Member
Registered: 2004-09-20
Posts: 79
Website

Re: asy_jpcache 0.9.8 - Fast Full Page Caching

Ok, I have a question now.

I run AdSense on a couple of my sites. Do the ads get cached too? They are a javascript include.


Eric

Offline

#28 2005-05-19 13:24:03

Sencer
Developer emeritus
From: cgn, de
Registered: 2004-03-23
Posts: 1,803
Website

Re: asy_jpcache 0.9.8 - Fast Full Page Caching

For the moment application/xhtml+xml should not be used at all with this Plugin (version 0.8), even if you are on PHP5.

@edburdo: Javascript is executed client-side, therefore the result of that cannot be cached by PHP. You should be fine.

Offline

#29 2005-05-23 12:00:46

Sencer
Developer emeritus
From: cgn, de
Registered: 2004-03-23
Posts: 1,803
Website

Re: asy_jpcache 0.9.8 - Fast Full Page Caching

Ok, update to 0.9.5 (0.9 was not publicly released)
Download and read FAQ in the first post of this topic.

Here are the changes:

  • - added option to enable txp’s logging (defaults to off)
  • - clean cache on editing links
  • - extended help section in admin-plugin
  • - added statistics on read-write-ratio in admin-plugin (only if logging is enabled in jpcache and set to ‘all’ in Textpattern)
  • - work-around for bug in some php-versions
  • - added option to skip caching for feeds (defaults to off)
  • - skip caching of feeds if the request can result in partial content (A-IM/feed, RFC3229)
  • - skip caching when there is too little content (for example when doing redirects)
  • - added some code & explanation to hack in application/xhtml+xml support
  • - added Content-Length header

If you are upating:
Replace all files, clean the cache and re-upload the admin-plugin and re-examine the installation instructions! Here is the changed part:
Edit your index.php in the main directory and after <notextile><pre>include ‘./textpattern/config.php’;</pre></notextile><br />
append the following line:<br /> <notextile><pre>include ‘./jpcache/jpcache.php’;</pre></notextile><br />

(Formerly it said to append the line at the top, now it is included after config.php)

Last edited by Sencer (2005-05-23 12:01:09)

Offline

#30 2005-05-23 14:31:37

soulship
Member
From: Always Sunny Charleston
Registered: 2004-04-30
Posts: 669
Website

Re: asy_jpcache 0.9.8 - Fast Full Page Caching

This is working great Sencer! Thanks for all the work on this. Could this work on the backend as well? /textpattern/index.php?
<span style=“font-size: 9px”>
Sorry if thats a dumb question. I don’t know the implications, of using it there. :)</span>

Offline

Board footer

Powered by FluxBB