View routes caching empty payload (with redis)

[mshick]

I've tried using redis caching for a route that renders a simple view. I have caching working generally with the basic request.reply({ 'greeting': 'hello world' }) style response.

When I attempt a similarly simple test with a rendered Handlebars view I get all normal caching behavior (set / get / expiry) but an empty payload, e.g.,

"set" "hapi-cache:%2F:%2F" "{\"item\":{\"code\":200,\"payload\":\"\",\"headers\":{},\"flags\":{}},\"stored\":1374187970387,\"ttl\":20000}"

I've tried all the documented forms for generating a view, with the same results.

Is this a bug, or am I missing something?

-- Here's my view rendering code --

    handler: function (request) {
        var context = {
            title: 'Homepage',
            page: {
                name: 'Stub',
                contents: 'Not yet.'
            }
        };

        request.reply.view('index', context);
    }

[hueniverse]

Confirmed as a bug.

[hueniverse]

The problem is that caching is currently performed around the handler only. View and directory rendering happens before transmission. This is causing empty content to be cached. For now, I just removed directory and view from being cacheable. Long term solution will require a lot more effort to figure out what's the right way to accomplish this.

One problem with early rendering of view responses is that it is very common to inject additional values into the view context in onPreResponse. It is also common to add user-specific information. There is no simple solution here as it changes based on the use case.

[mshick]

Perhaps it would make sense to only cache the template name, context and options for the view, then use the cached payload to re-generate the view, with onPreResponse getting data virtually identical to what it would for an un-cached response?

Here's something I came up with:

https://github.com/mshick/hapi/commit/615201207f5999b7cf238b27cccae1d73777760e

Not ready for prime-time, but it is working for me, and it preserves onPreResponse.

I can imagine wanting to cache the fully-rendered output as well, though this strategy would at least save the server some work.