httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: Caching the useful headers
Date Sat, 09 Feb 2008 19:39:37 GMT

On Sat, 9 Feb 2008, Ruediger Pluem wrote:

> > +    return apr_table_make(pool, 10);
> > +    };
> > +
>
> Why this? Just some type of defensive programming if someone feeds in a t == NULL?
> If yes, I would prefer return NULL instead of creating an empty table.
> Garbage in, garbage out :-).

That was my first approach as well. But then I noticed that the users of
this functions virtually always will have to serialize/store the tables;
or otherwise track them. So if we have 3 options -

-	if (r->headers_in)
		in = ap_cache_cacheable_hdrs_in(
		serialize(in)
	else
		mark a skip or something that you did not

-	headers_in = ap_cache_cacheable_hdrs_in(
	if (headers_in)
		serialize(in)
	else
		mark a skip etc

-	headers_in = ap_cache_cacheable_hdrs_in
	serialize(headers_in) which can deal with empty arrays

or we defer - and simply return null and have the respective serializes
all deal with this. The advantage of returning null is that it is quicker
to check for those serializers. But if I had to optimize - I'd rather do
so on assuming an array - as in reality we have the headers virtually
always ?

> How about using @deprecated here instead of warning?
..
> Style ...

Will fix prior to commit.

Dw.

Mime
View raw message