httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Question on APLOGNO assignment, 2.4 vs trunk
Date Wed, 13 Nov 2013 03:10:16 GMT
On Wed, 13 Nov 2013 00:07:08 +0200
Graham Leggett <minfrin@sharp.fm> wrote:

> On 13 Nov 2013, at 12:00 AM, "William A. Rowe Jr."
> <wrowe@rowe-clan.net> 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.


Mime
View raw message