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.

Regards,
Graham
--

Reply via email to