mod_include: include virtual and error handling

[Graham Leggett <mi...@sharp.fm>]

Hi all,

In mod_include, we currently only allow 200 OK responses to be  
included within the document. If any other code is returned, we  
replace the document body with a hard coded error string. This places  
a significant limitation on the usefulness of mod_include.

Ideally, the included URL should be empowered to handle errors itself,  
as you'd expect of any restful URL. In other words, an included URL  
might want to return 404 Not Found, with a body suitable for inclusion  
in the main template, possibly taking advantage of content  
negotiation, and if so, it should be allowed to do so.

What I have in mind is a syntax like this:

<!--#include response="200,404,500-599" virtual="/my/included/url"-->

This would mean that if the response code is in the range shown,  
include the URL, otherwise revert to the hard coded error string.

Other templating systems have tried to offer "URL to show on error"  
functionality, which I believe is overkill. HTTP already contains an  
error handling mechanism, and httpd supports ErrorDocument where the  
application doesn't handle errors of its own, mod_include should  
honour this existing mechanism, and not invent it's own.

Regards,
Graham
--

Re: mod_include: include virtual and error handling

[Graham Leggett <mi...@sharp.fm>]

On 02 Nov 2010, at 10:34 PM, Nick Kew wrote:

>> The lack of this one feature is the most cited reason I've been given
>> for why people have moved away from mod_include as a template
>> processor to other template processors within other servers. Rather
>> than moving to an entirely new type of server, I'd rather we just fix
>> the core problem.
>
> Wouldn't the same argument support an onerror="url" clause too?
>
> Yes, you can use an errordocument.  But there seem to be a lot of
> users who find that a difficult concept to grasp (an error document
> that we intentionally use???), so it's not really a great answer.
> Besides, an errordocument could easily end up getting overloaded!
>
> The implementation should presumably be straightforward alongside
> what you propose, and could use an errordocument processing path.

+1.

Turns out they would both work a very similar way.

Regards,
Graham
--

Re: mod_include: include virtual and error handling

[Nick Kew <ni...@webthing.com>]

On Tue, 2 Nov 2010 19:23:07 +0200
Graham Leggett <mi...@sharp.fm> wrote:

> The lack of this one feature is the most cited reason I've been given  
> for why people have moved away from mod_include as a template  
> processor to other template processors within other servers. Rather  
> than moving to an entirely new type of server, I'd rather we just fix  
> the core problem.

Wouldn't the same argument support an onerror="url" clause too?

Yes, you can use an errordocument.  But there seem to be a lot of
users who find that a difficult concept to grasp (an error document
that we intentionally use???), so it's not really a great answer.
Besides, an errordocument could easily end up getting overloaded!

The implementation should presumably be straightforward alongside
what you propose, and could use an errordocument processing path.

-- 
Nick Kew

Re: mod_include: include virtual and error handling

[Graham Leggett <mi...@sharp.fm>]

On 02 Nov 2010, at 7:02 PM, Dan Poirier wrote:

> As long as the default behavior continues unchanged, it seems  
> harmless.
> I just wonder how many users would find a use for it?  I assume you  
> have
> a use case in mind?

The lack of this one feature is the most cited reason I've been given  
for why people have moved away from mod_include as a template  
processor to other template processors within other servers. Rather  
than moving to an entirely new type of server, I'd rather we just fix  
the core problem.

Regards,
Graham
--

Re: mod_include: include virtual and error handling

[Dan Poirier <po...@pobox.com>]

As long as the default behavior continues unchanged, it seems harmless.
I just wonder how many users would find a use for it?  I assume you have
a use case in mind?

Dan