On 6/23/2010 4:33 PM, Nick Kew wrote:
>
> On 23 Jun 2010, at 16:54, William A. Rowe Jr. wrote:
>>>
>>> --- httpd/httpd/trunk/modules/cache/mod_socache_dbm.c (original)
>>> +++ httpd/httpd/trunk/modules/cache/mod_socache_dbm.c Wed Jun 23 15:04:57
>>> 2010
>>> @@ -291,7 +291,7 @@ static apr_status_t socache_dbm_retrieve
>>> rc = apr_dbm_fetch(dbm, dbmkey, &dbmval);
>>> if (rc != APR_SUCCESS) {
>>> apr_dbm_close(dbm);
>>> - return rc;
>>> + return APR_NOTFOUND;
>>
>> The other two changes were fine, but why truncate an apr_status_t value?!?
>
> Startingpoint was empirical testing: mod_authn_socache with dbm backend
> was getting incorrect return values.
>
> A look at the apr_dbm source shows uncertainty over mapping DBM errors
> to APR status, including blanket use of APR_EGENERAL. Didn't see an
> obvious fix.
Well, please don't break an API that works. Could you revert that bit and
we can continue to study what appropriate, specific codes should be NOTFOUND?
Maybe APR_EEXIST is the current error?
