You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2013/11/12 22:41:19 UTC
Question on APLOGNO assignment, 2.4 vs trunk
Trying to apply
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-tags/next-number?r1=1527925&r2=1527924&pathrev=1527925
... there is no next-number tracking.
How are we tracking numbers on 2.4 vs. trunk, and avoiding some
discordance between the next 2.6 and 2.4 error numbers? Using
trunk number allocations on any-branch?
If we create a 2.4 branch-specific error for some cause, do we
simply tick the trunk counter?
AW: Question on APLOGNO assignment, 2.4 vs trunk
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
+1
Regards
Rüdiger
> -----Ursprüngliche Nachricht-----
> Von: Jim Jagielski
> Gesendet: Mittwoch, 13. November 2013 13:01
> An: dev@httpd.apache.org
> Betreff: Re: Question on APLOGNO assignment, 2.4 vs trunk
>
> +1.
>
> On Nov 12, 2013, at 4:44 PM, Graham Leggett wrote:
>
> > On 12 Nov 2013, at 11:41 PM, "William A. Rowe Jr."
> wrote:
> >
> >> Trying to apply
> >> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-
> tags/next-number?r1=1527925&r2=1527924&pathrev=1527925
> >> ... there is no next-number tracking.
> >>
> >> How are we tracking numbers on 2.4 vs. trunk, and avoiding some
> >> discordance between the next 2.6 and 2.4 error numbers? Using
> >> trunk number allocations on any-branch?
> >>
> >> If we create a 2.4 branch-specific error for some cause, do we
> >> simply tick the trunk counter?
> >
> > I think this is the most pragmatic approach, the numbers only need to
> be unique, and keeping the counter in one place makes sure we always
> stay that way.
> >
> > Regards,
> > Graham
> > --
> >
Re: Question on APLOGNO assignment, 2.4 vs trunk
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1.
On Nov 12, 2013, at 4:44 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 12 Nov 2013, at 11:41 PM, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>
>> Trying to apply
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-tags/next-number?r1=1527925&r2=1527924&pathrev=1527925
>> ... there is no next-number tracking.
>>
>> How are we tracking numbers on 2.4 vs. trunk, and avoiding some
>> discordance between the next 2.6 and 2.4 error numbers? Using
>> trunk number allocations on any-branch?
>>
>> If we create a 2.4 branch-specific error for some cause, do we
>> simply tick the trunk counter?
>
> I think this is the most pragmatic approach, the numbers only need to be unique, and keeping the counter in one place makes sure we always stay that way.
>
> Regards,
> Graham
> --
>
Re: Question on APLOGNO assignment, 2.4 vs trunk
Posted by Jim Jagielski <ji...@jaguNET.com>.
+1
On Nov 12, 2013, at 10:10 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On Wed, 13 Nov 2013 00:07:08 +0200
> Graham Leggett <mi...@sharp.fm> wrote:
>
>> On 13 Nov 2013, at 12:00 AM, "William A. Rowe Jr."
>> <wr...@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.
Re: Question on APLOGNO assignment, 2.4 vs trunk
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Wed, 13 Nov 2013 00:07:08 +0200
Graham Leggett <mi...@sharp.fm> wrote:
> On 13 Nov 2013, at 12:00 AM, "William A. Rowe Jr."
> <wr...@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.
Re: Question on APLOGNO assignment, 2.4 vs trunk
Posted by Graham Leggett <mi...@sharp.fm>.
On 13 Nov 2013, at 12:00 AM, "William A. Rowe Jr." <wr...@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.
Regards,
Graham
--
Re: Question on APLOGNO assignment, 2.4 vs trunk
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Tue, 12 Nov 2013 23:44:08 +0200
Graham Leggett <mi...@sharp.fm> wrote:
> On 12 Nov 2013, at 11:41 PM, "William A. Rowe Jr."
> <wr...@rowe-clan.net> wrote:
>
> > Trying to apply
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-tags/next-number?r1=1527925&r2=1527924&pathrev=1527925
> > ... there is no next-number tracking.
> >
> > How are we tracking numbers on 2.4 vs. trunk, and avoiding some
> > discordance between the next 2.6 and 2.4 error numbers? Using
> > trunk number allocations on any-branch?
> >
> > If we create a 2.4 branch-specific error for some cause, do we
> > simply tick the trunk counter?
>
> I think this is the most pragmatic approach, the numbers only need to
> be unique, and keeping the counter in one place makes sure we always
> stay that way.
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?
Re: Question on APLOGNO assignment, 2.4 vs trunk
Posted by Stefan Fritsch <sf...@sfritsch.de>.
Am Dienstag, 12. November 2013, 23:44:08 schrieb Graham Leggett:
> On 12 Nov 2013, at 11:41 PM, "William A. Rowe Jr." <wrowe@rowe-
clan.net> wrote:
> > Trying to apply
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-ta
> > gs/next-number?r1=1527925&r2=1527924&pathrev=1527925 ... there is
> > no next-number tracking.
> >
> > How are we tracking numbers on 2.4 vs. trunk, and avoiding some
> > discordance between the next 2.6 and 2.4 error numbers? Using
> > trunk number allocations on any-branch?
> >
> > If we create a 2.4 branch-specific error for some cause, do we
> > simply tick the trunk counter?
>
> I think this is the most pragmatic approach, the numbers only need
> to be unique, and keeping the counter in one place makes sure we
> always stay that way.
+1
Re: Question on APLOGNO assignment, 2.4 vs trunk
Posted by Graham Leggett <mi...@sharp.fm>.
On 12 Nov 2013, at 11:41 PM, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> Trying to apply
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-tags/next-number?r1=1527925&r2=1527924&pathrev=1527925
> ... there is no next-number tracking.
>
> How are we tracking numbers on 2.4 vs. trunk, and avoiding some
> discordance between the next 2.6 and 2.4 error numbers? Using
> trunk number allocations on any-branch?
>
> If we create a 2.4 branch-specific error for some cause, do we
> simply tick the trunk counter?
I think this is the most pragmatic approach, the numbers only need to be unique, and keeping the counter in one place makes sure we always stay that way.
Regards,
Graham
--