Conteg v0.12.2 available

Content-Negotiation PHP Class available for download

[AlexK]

AFAIK the last version of Conteg announced within this forum was v0.11 [webmasterworld.com]. That is a whoopsie on my part if so, since version 0.12.2 of Conteg has been available for download [webmasterworld.com] for some time.

Here are the headlines:

 * Conteg.include 
 * 
 * Content-Negotiation + Cache-Control for PHP produced web-output 
 * - Request/Response Headers attempt to be RFC-compliant 
 * - Compression is load-balanced by default 
 * - Document-wide multi search/replace available 
 * - Single array-parameter switches negotiation on/off: 
 * 
 * No switches: auto-negotiates Accept-Encoding (compression), User-Agent 
 * Add: 
 * +Modified-date: auto-negotiates If-Modified-Since, If-Unmodified-Since 
 * +Expiry time: auto-sends Expires 
 * +Etag: auto-negotiates If-None-Match, If-Match, If-Range 
 * +Ranges: auto-negotiates Range, If-Range 
 * +Charset: auto-negotiates Accept-Charset 
 * +Language: auto-negotiates Accept-Language 
 * +Media-Type auto-negotiates Accept 
 * 
 * With the appropriate switches, the routine will auto-send the correct 
 * +304 Not Modified, 406 Not Acceptable, 412 Precondition Failed, 416 Requested 
 * +Range Not Satisfiable, 206 Partial content or 200 OK page + full headers.

...and changes since the last version:

 * Change Log: 
 * 0.12.2: Added $_num_cpu for SMP boxes (like mine!) 18 Aug 06 
 * 0.12.1: Added sendStatusHeader() + 404 responses (used to create 02 Ju1 06 
 * +custom Error-pages). 
 * 0.12: Added requestNoCache(), requestNoStore(),  04 Jun 06 
 * +$_cache_control_response + $_cache_control_request arrays.

There have been further updates since this version but, sadly, the free-ISP that is used to supply the file has reduced the free webspace from 30MB to 15MB, and I can no longer upload any changes. Blast!

[edited by: coopster at 3:01 am (utc) on Aug. 6, 2008]

[mihomes]

Alex,

Do you have any step by step install instructions for a newbie? Not all too familiar with php. Basically I just want to show the correct 200 or 304 with if modifed and probably etags too.

[henry0]

For those interested: A W3c good article [w3.org]

[AlexK]

mihomes:

Do you have any step by step install instructions for a newbie?

The following comes from "Help, Advice + Other Stuff" (begins line #1937).

 * How to use:
 *
 * Before use: change $_num_cpu to the number on *your* machine (default 1)
 *
 * Simplest possible usage requires 3 lines:
 * 1 Turn Output Buffering on.
 * 2 Include the Class file.
 * 3 On the *very* last line create an instance of the Class.
 *
 * ------------Start of file---------------
 * ¦<?php
 * ¦ ob_start(); // <==== line 1
 * ¦ include('Conteg.inc'); // <==== line 2
 * ¦
 * ¦... the page ...
 * ¦
 * ¦ new Conteg(); // <==== line 3
 * ¦?>
 * -------------End of file----------------

The above will auto-negotiate

Accept-Encoding

(load-balanced compression) &

User-Agent

.

Please note that the default for the program is to print (output ob-contents) immediately on declaration, which is why--in the example above--it needs to be declared upon the absolute final line. If you are to conduct any content-negotiation that requires programmatic-mediation (

Accept-Language

would be a good example) then the Class would need creating with a

'noprint' => TRUE

parameter at the beginning, and

$Encode->show()

declaration at the end. That does NOT necessarily apply to the following discussion.

In order to add the Modified-date (

If-Modified-Since

,

If-Unmodified-Since

) & ETag (

If-None-Match

,

If-Match

,

If-Range

):

• Provide a means of obtaining the page-modified date ($mdate).
  
• Decide whether to use strong or weak ETags.

The following assumes that you have decided to use weak etags, since these are more suitable for php-originated pages.

This is the replacement for 'line 3' above (copied from lines #2000-2008 within Class):

 * Here is the simplest HTTP/1.1 usage:
 *
$param= array(
'use_etag'=> TRUE,// default is Weak ETags
'modified'=> $mdate,// (here, $mdate is Unix timestamp)
'expiry'=> 3600// set expiry date 1 hour from time()
);
$Encode= new Conteg( $param );
 *

My pages are all .htm/.html but I set them up to parse as php ... Do you have any walk through instructions for a newbie to implement that?

That has already been gone through at length... see the dicussion beginning msg#1260952 in this thread [webmasterworld.com].

[mihomes]

Alex,

If I do not want to use compression would this be correct? :

* ------------Start of file---------------
<?php
include('Conteg.inc');
$param= array(
'use_etag'=> TRUE,// default is Weak ETags
'modified'=> $mdate,// (here, $mdate is Unix timestamp)
'expiry'=> 3600// set expiry date 1 hour from time()
);
$Encode= new Conteg( $param );
?>
--rest of page goes here (all pages are .htm/.html and I parse them as .php which is why I need this in the first place)
* -------------End of file----------------

Thanks for all your help!

[AlexK]

mihomes, it took me almost 2 hours to research and type the previous message, and it seems that you did not read one line of it. Now no disrespect, my friend, but I am not going to put in another hour's work for you to ignore.

This message [webmasterworld.com] has precisely what you require.

Add:

'use_accept_encode' => FALSE,

...if you do not wish to negotiate compression (a bad idea IMO).

[mihomes]

Thanks a ton Alex! After finishing some work I needed to do I will be testing this implementation on a site as soon as I download the 12.3 version.

Everything is clear as day to me now... just a simple prepend and append called in htaccess with the correct files I throw on the server.

Quick question though, my pages (while parsed in php) are basically static and do not change much at all. Would you still recommend compression in this case? Is there a great downside to one over the other I should be concerned about? I am talking about sites with about 400 or so pages on each which rarely change.

Again, thank you for your help and the amazing script!

[mihomes]

Alex,

Okay, I got everything running (and I must say that was very easy), however, I have a few questions...

1. I set the expires for a full day (86400), but the header always shows one hour in the future. Is this something I need 12.3 for?

[AlexK]

mihomes:

Quick question though, my pages (while parsed in php) are basically static and do not change much at all. Would you still recommend compression in this case?

Two principal reasons for Content Negotiation are to:

1. Speed display of web-pages.
   
2. Reduce bandwidth

Content Encoding, which is simply one of a dozen Content Negotiation features, dates right back to HTTP 1.0 (improved in HTTP 1.1 if I recall correctly) and will directly achieve both of the above.

Current AWStats figures for my .co.uk site (almost entirely static, unchanging .html pages, processed exactly the same as your own) show an *average* compression of 81% (829.08 MB reduced to 156.97 MB for January). That's better than a 5-fold reduction. That means that the page arrives 5 times faster than it normally would. Even ignoring the faster (client) computers available nowadays, that means a much faster display, since--usually--the page can start to be de-compressed whilst later chunks are arriving and, as long as your page is written correctly, that means that the top of the page can be displayed whilst later chunks are still being dispatched.

Turning to php-originated pages, I have to confess--to my shame--that I have a page that is more than 500 KB on my .com site. Because of large-scale duplication of HTML code on that page, it shrinks by better than 90%. That means a 50k page rather than half-a-megabyte, which is a much more reasonable proposition. For the same reason, my admin pages can approach 95% reduction.

Finally, the compression is load-balanced, which means that the server is never compromised by the extra load required.

You will, perhaps, have gotten the point that I am a complete fan of file-compression.

[AlexK]

mihomes:

I set the expires for a full day (86400), but the header always shows one hour in the future. Is this something I need 12.3 for?

Yes.

That is the precise bugfix in v0.12.3 cf v0.12.2.

v0.12.3 will cost you £1 GBP (covers my bandwidth charges). However, if you are a complete miser (no disrespect intended - that phrase neatly describes myself) you will find the changes required within the "Site Info & Diary" forum on my site; just search for "Conteg".

[mihomes]

Sounds great Alex. Simply an amazing script and yes, the load times are very quick! I will be adding the htaccess lines to all my sites this week to use the files I added to the server.

My last and final question, I promise... I used the liveheaders extension in firefox to test results after I implemented this... I noticed that language (en) and encoding (iso 8859-1) are sent as well with the conteg. Does this mean I can remove those headers from my pages and will receive no ill affect? For SEO reasons even?

For instance, here is an example head portion of one of my static htm pages (yet parsed as php and using conteg) :

<html>
<head>
<title>About my site</title>
<meta name="description" content="my site desc">
<meta name="keywords" content="my, keywords">
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Content-Language" content="en-us">
<meta name="ROBOTS" content="ALL">
<meta name="Rating" CONTENT="General">
<link href="style.css" rel="stylesheet" type="text/css">
</head>

[AlexK]

mihomes:

language (en) and encoding (iso 8859-1) are sent as well ... Does this mean I can remove those headers from my pages and will receive no ill affect?

Health warning beforehand: I'm not an expert on this (simply well-informed), so canvass other views.

General reply:
The short answer is "Yes, but make sure that the server-headers match reality".

Personally, I'm a strong believer in 'Belt 'n' Braces', so if in doubt, send both. If browsers were perfect, that would not be necessary, but they most certainly are not. However, you will need to take steps to make sure that they are all--server-headers, page-headers & document--identically the same.

Specific reply:
Beware that this specific header is reported to cause some browsers to redraw the page after initially displaying it.

The

<meta http-equiv ... />

statement has a specific intention. It is designed to provide a means for those with either no access to the web-server config, or otherwise to make it simple, to instruct the server to deliver up specific HTTP headers (& inform browsers that can understand it as a fall-back). In other words:

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

means to those servers that can, and are configured to implement it:

"send a Content-Type: HTTP header with this value"

If the server already delivers up that header, then those statements are redundant, and could be removed. You could, in any case, be putting Charset info in a different part of the HTML:

<html lang='en-us'>

However, more important than all this is: is it all consistent?

In other words, consider:

1. The actual coding of the file document on the server.
   
2. The actual coding of the document transmitted to the browser.
   
3. The headers sent by the server together with that electronic document.
   
4. The explicit (or browser-default, if any) for the

   <html lang= ...>

   element.
   
5. The value of any

   <meta http-equiv='Content-Type' ... />

   element.

...and ask the question: "Are they all the same?".

If not, then you can bet that it will turn round and bite you on the bum. Google uses dozens of different parameters to score a page these days, and --although I have no specific info--I cannot believe that both the existence of Content-Type info, and it's consistency, are not among those parameters.

[mihomes]

Final question I promise... haha...

<?php
new Conteg( array(
'modified'=> filemtime($_SERVER['SCRIPT_FILENAME']),
'use_etag'=> TRUE,
'expiry'=> 86400,
'cache_control' => array(
'macro' => 'cache-all'
)
));
?>

So with that said, this sends the cache-control public with maxage and s-maxage at 86400 (one day). I'd like to use this to increase customers browsing speed just that little bit more by taking advantage of shared caches.

I guess my concern with this is for authenticated pages. For instance, I just viewed the headers on an auth page and it will be public which I definately do not want. Conteg over rides the deault headers sent in that protected directory.

On the other hand, I could also add 'no-cache' which would make the authentication sent before releasing the cached version, but then the catch 22 is it wil set that for every page including non-auth ones which I do not want either.

Is there a work around for this when using conteg?

[AlexK]

(cache-control) ... I guess my concern with this is for authenticated pages

That is the downside of using "just a simple prepend and append called in htaccess"; you want different headers for your authenticated pages. You will need to find a way to discriminate between those pages cf others (are they within their own directory?), and use different values for the

param

parameter in either the Conteg constructor or, perhaps, a later

setup()

call.

Cache-Control Macros:
I like as easy a life as possible, hence the 'cache-all' and 'no-cache' macros. You can, however, get as fine-grained control as you want, since *every* Cache-Control element can be set individually. There is also nothing to stop you from implementing your own macros - if you find some that you think are particularly useful in particular circumstances, pass them along.

[mihomes]

Yes, as is the downside of the htaccess append and prepend, however, I think with some modification to the append file I can come up with a quick if-else or case scenario to get the right macros based off my setup.

Will let you know if I come up with any useful macros... thanks again.