+1 On Nov 12, 2013, at 10:10 PM, William A. Rowe Jr. <[email protected]> wrote:
> On Wed, 13 Nov 2013 00:07:08 +0200 > Graham Leggett <[email protected]> wrote: > >> On 13 Nov 2013, at 12:00 AM, "William A. Rowe Jr." >> <[email protected]> wrote: >> >>> Follow-up question; is reuse recommended? In this small bit of >>> trunk (comments removed for simplicity); >>> >>> - else if (!lenp) { >>> + else if (f->r->proxyreq == PROXYREQ_RESPONSE) { >>> ap_log_rerror( >>> - APLOG_MARK, APLOG_INFO, 0, f->r, >>> APLOGNO(01585) "Unknown Transfer-Encoding: %s", tenc); >>> - return APR_ENOTIMPL; >>> + APLOG_MARK, APLOG_INFO, 0, f->r, >>> APLOGNO(01586) "Unknown Transfer-Encoding: %s; using >>> read-until-close", tenc); >>> + tenc = NULL; >>> } >>> else { >>> ap_log_rerror( >>> - APLOG_MARK, APLOG_WARNING, 0, f->r, >>> APLOGNO(01586) "Unknown Transfer-Encoding: %s; using >>> Content-Length", tenc); >>> - tenc = NULL; >>> + APLOG_MARK, APLOG_INFO, 0, f->r, >>> APLOGNO(01585) "Unknown Transfer-Encoding: %s", tenc); >>> + return APR_EGENERAL; >>> >>> Indeed the second case becomes effectively the initial case, a >>> T-E/C-L combination we throw away and refuse to handle. Although >>> this is very subtly different - originally we gave up without a >>> C-L, now we cough without or without a C-L if this is not a >>> proxyreq response body. >>> >>> But the revised first case, 1586 'Reading to end', is indeed quite >>> different than the original second case, 1586 'Using C-L'. Should >>> this have been assigned a fresh number? Otherwise, we end up with >>> divergent meanings, and the user who stumbles across 1586 will come >>> up with two very different cases searching the web for their error. >>> >>> So should the second have been assigned a new number? Or both of >>> cases assigned new numbers? Or is reuse acceptable? >> >> I'd say probably not (ie assign a new number) - if the message >> description has changed materially and means something different from >> before, the number should probably change to reflect that. Otherwise >> google searches might return confusing results mixing "before change" >> and "after change" messages with the same number. > > On your feedback, I've picked up a new APERRNO for the second issue above. > I'm still thinking the first is an edge case, but since it is the same > general sort of error with identical error text, it doesn't seem all that > harmful to persist the old APERRNO.
