You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2015/06/11 16:08:28 UTC
[VOTE] Release Apache httpd 2.4.14 as GA
The pre-release test tarballs for Apache httpd 2.4.14 can be found
at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.
Vote will last the normal 72 hrs.
NOTE: The *-deps are only there for convenience.
Thx!
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
This is corrected in SVN, see
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/request.c?view=log
Unsure why this edit didn't carry on to the github mirror.
On Thu, Jun 11, 2015 at 11:50 AM, Rainer Canavan <
rainer.canavan@sevenval.com> wrote:
> Hi,
>
> is the commit message incorrect or the CHANGES file concerning
> CVE-2015-3183?
>
> The commit message at
>
> https://github.com/apache/httpd/commit/cd2b7a26c776b0754fb98426a67804fd48118708
> uses CVE-2015-3183 for the "Replacement of ap_some_auth_required",
> while the CHANGES uses it for "Remove apr_brigade_flatten()"
>
> I'm have no idea if that would qualify the CVE to get REJECTED.
>
> regards,
>
>
> rainer
>
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Rainer Canavan <ra...@sevenval.com>.
Hi,
is the commit message incorrect or the CHANGES file concerning CVE-2015-3183?
The commit message at
https://github.com/apache/httpd/commit/cd2b7a26c776b0754fb98426a67804fd48118708
uses CVE-2015-3183 for the "Replacement of ap_some_auth_required",
while the CHANGES uses it for "Remove apr_brigade_flatten()"
I'm have no idea if that would qualify the CVE to get REJECTED.
regards,
rainer
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Jun 11, 2015 at 4:08 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> [X] +1: Good to go
No regression with event and worker, included apr-1.5.2 and apr-util-1.5.4.
Tested systems:
* Debian 8 - amd64
* Debian 7 - amd64
* Debian 6 - amd64
* Debian 6 - amd64 - mixed 32/64bit system/kernel:
Thanks Jim,
Yann.
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jacob Perkins <ja...@cpanel.net>.
Hi Jeff,
Thanks for the response. You’re right, this does look to be in Apache 2.2.12 at this time. I was taking this from CHANGES, and it states:
Changes with Apache 2.4.13
*) mod_ssl: make sure to consistently output SSLCertificateChainFile
deprecation warnings, when encountered in a VirtualHost block.
[Falco Schwarz <hiding falco.me>]
This is why I was so concerned. Having this drop to one output should help, but it still may cause concerns for scripts that expect 0 output from a restart service script.
—
Jacob Perkins
Product Owner
cPanel Inc.
jacob.perkins@cpanel.net <ma...@cpanel.net>
Office: 713-529-0800 x 4046
Cell: 713-560-8655
> On Jun 12, 2015, at 11:48 AM, Jeff Trawick <tr...@gmail.com> wrote:
>
> On Fri, Jun 12, 2015 at 12:35 PM, Jacob Perkins <jacob.perkins@cpanel.net <ma...@cpanel.net>> wrote:
> +1 to Noels comments. We have a ton of servers running Apache 2.4 with our control panel. Doing this in a point release will cause us to have to change our product instead of doing a regular Apache release.
>
> When you have a server with 10k+ SSL vhosts, this can cause massive, unexpected problems. I have a feeling that this will cause massive headaches with all those running Apache 2.4.
>
> Thanks to Noel's comments, we have dropped this to one message at a quieter log level for the next 2.4.x release, and we can assist with a tiny patch to any recent 2.4.x.
>
> It doesn't make sense for us to hold up a release when that change has been in the last several releases however. (That's a high barrier for making progress.)
>
> Make sense?
>
>
> —
> Jacob Perkins
> Product Owner
> cPanel Inc.
>
> jacob.perkins@cpanel.net <ma...@cpanel.net>
> Office: 713-529-0800 x 4046 <tel:713-529-0800%20x%C2%A04046>
> Cell: 713-560-8655 <tel:713-560-8655>
>
>> On Jun 11, 2015, at 8:37 PM, Noel Butler <noel.butler@ausics.net <ma...@ausics.net>> wrote:
>>
>> On 12/06/2015 00:08, Jim Jagielski wrote:
>>
>>>
>>> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>>>
>>> [ ] +1: Good to go
>>> [ ] +0: meh
>>> [ ] -1: Danger Will Robinson. And why.
>>>
>> -1
>>
>> "The SSLCertificateChainFile directive () is deprecated, SSLCertificateFile should be used instead"
>>
>> The constant warnings on start, stop, and even reload for every single SSL host is unacceptable.
>>
>> This should never have been contemplated for a "point" release anyway.
>>
>> Clearly no consideration has been given to the headaches and collateral damage this will cause, some hosts have tens of thousands of SSL hosts, even a server reload will flood the hell out of them, most system/CP scripts look for a specific, or no output, after reload, this results in unexpected output and will trigger alarms, likely causing many systems to think " oh there was a problem adding this host, so I wont continue adding them into anything else and fail the entire new customer process" again, creating serious problems for those required to maintain these things.
>>
>>
>> It might be fine and dandy for a stand alone single SSL host server that is manually managed, but dont forget many hosts run up to 2+K hosts on a single server with many of them SSL, that is a lot of change when you have a server room half full of them, not to mention any inhouse scripting or control panels that will need to be modified to cater for such changes to create the new certs and deal with it all.
>>
>>
>> I for one will not place this release on any production servers. My recommendation is that chainfile remain as it is - at the very least for the 2.4 series, and if it is not enough to stop or delay this release to revert, then I sincerely hope it is changed in trunk for the next.
>>
>>
>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/ <http://emptyhammock.com/>
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jun 12, 2015 at 1:35 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Fri, Jun 12, 2015 at 1:31 PM, Jeff Trawick <tr...@gmail.com> wrote:
>
>> On Fri, Jun 12, 2015 at 1:25 PM, Rainer Jung <ra...@kippdata.de>
>> wrote:
>>
>>> Am 12.06.2015 um 19:12 schrieb William A Rowe Jr:
>>>
>>>> Revision 1678233 - (view) (download) (annotate) - [select for diffs]
>>>> Modified Thu May 7 16:26:43 2015 UTC (5 weeks, 1 day ago) by jim
>>>> File length: 57106 byte(s)
>>>> Diff to previous 1674655 (colored)
>>>> Merge r1676085 from trunk:
>>>>
>>>> consistently output SSLCertificateChainFile deprecation warnings
>>>> Submitted by: kbrand
>>>> Reviewed/backported by: jim
>>>>
>>>> sent the warnings to the console/main server error log, rather than a
>>>> specific server error log file. Because this is during config parsing,
>>>> it that may have previously been a bit bucket. So this could be
>>>> perceived as a regression although the logic and log file activity was
>>>> there for some time.
>>>>
>>>
>>> Indeed there was a discussion thread for r1562500 in 2014 during which
>>> Falco Schwarz reported, that he did *not* get the log message a anywhere
>>> (neither console, not log files) when he had the directive only in
>>> VirtualHosts. After the 2.4.13 change it seems to be new, that you get the
>>> message massively on console, if you have the directive in frequent use
>>> inside VHosts. That might well be perceived as a regression.
>>>
>>> The 2.4.13 change replaced cmd->server in ap_log_error by NULL. The log
>>> level "APLOG_WARNING|APLOG_STARTUP" was not changed.
>>>
>>> Rainer
>>>
>>>
>> I definitely have the old code and the SPAM... I wonder if before you
>> didn't see it if you didn't have vhost-specific logs configured, and now
>> you see it regardless?
>>
>
> so weird:
>
> With the old code, I have globally "LogLevel debug" and in a vhost
> "LogLevel warn" ; if I comment out that vhost's "LogLevel" I don't see the
> message even though I have ErrorLog in the vhost and *should* inherit the
> global LogLevel.
>
>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>>
>>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
>
I'm a flip-flopper who didn't understand the subtlety of this before... I
say "regression", though I think it is acceptable to have a tiny
recommended patch for those affected.
As for why one or more messages hits the console for something to be dealt
with by the time you upgrade to an as-yet-non-existing future release
stream, I don't have any justification.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jun 12, 2015 at 1:31 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Fri, Jun 12, 2015 at 1:25 PM, Rainer Jung <ra...@kippdata.de>
> wrote:
>
>> Am 12.06.2015 um 19:12 schrieb William A Rowe Jr:
>>
>>> Revision 1678233 - (view) (download) (annotate) - [select for diffs]
>>> Modified Thu May 7 16:26:43 2015 UTC (5 weeks, 1 day ago) by jim
>>> File length: 57106 byte(s)
>>> Diff to previous 1674655 (colored)
>>> Merge r1676085 from trunk:
>>>
>>> consistently output SSLCertificateChainFile deprecation warnings
>>> Submitted by: kbrand
>>> Reviewed/backported by: jim
>>>
>>> sent the warnings to the console/main server error log, rather than a
>>> specific server error log file. Because this is during config parsing,
>>> it that may have previously been a bit bucket. So this could be
>>> perceived as a regression although the logic and log file activity was
>>> there for some time.
>>>
>>
>> Indeed there was a discussion thread for r1562500 in 2014 during which
>> Falco Schwarz reported, that he did *not* get the log message a anywhere
>> (neither console, not log files) when he had the directive only in
>> VirtualHosts. After the 2.4.13 change it seems to be new, that you get the
>> message massively on console, if you have the directive in frequent use
>> inside VHosts. That might well be perceived as a regression.
>>
>> The 2.4.13 change replaced cmd->server in ap_log_error by NULL. The log
>> level "APLOG_WARNING|APLOG_STARTUP" was not changed.
>>
>> Rainer
>>
>>
> I definitely have the old code and the SPAM... I wonder if before you
> didn't see it if you didn't have vhost-specific logs configured, and now
> you see it regardless?
>
so weird:
With the old code, I have globally "LogLevel debug" and in a vhost
"LogLevel warn" ; if I comment out that vhost's "LogLevel" I don't see the
message even though I have ErrorLog in the vhost and *should* inherit the
global LogLevel.
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jun 12, 2015 at 1:25 PM, Rainer Jung <ra...@kippdata.de>
wrote:
> Am 12.06.2015 um 19:12 schrieb William A Rowe Jr:
>
>> Revision 1678233 - (view) (download) (annotate) - [select for diffs]
>> Modified Thu May 7 16:26:43 2015 UTC (5 weeks, 1 day ago) by jim
>> File length: 57106 byte(s)
>> Diff to previous 1674655 (colored)
>> Merge r1676085 from trunk:
>>
>> consistently output SSLCertificateChainFile deprecation warnings
>> Submitted by: kbrand
>> Reviewed/backported by: jim
>>
>> sent the warnings to the console/main server error log, rather than a
>> specific server error log file. Because this is during config parsing,
>> it that may have previously been a bit bucket. So this could be
>> perceived as a regression although the logic and log file activity was
>> there for some time.
>>
>
> Indeed there was a discussion thread for r1562500 in 2014 during which
> Falco Schwarz reported, that he did *not* get the log message a anywhere
> (neither console, not log files) when he had the directive only in
> VirtualHosts. After the 2.4.13 change it seems to be new, that you get the
> message massively on console, if you have the directive in frequent use
> inside VHosts. That might well be perceived as a regression.
>
> The 2.4.13 change replaced cmd->server in ap_log_error by NULL. The log
> level "APLOG_WARNING|APLOG_STARTUP" was not changed.
>
> Rainer
>
>
I definitely have the old code and the SPAM... I wonder if before you
didn't see it if you didn't have vhost-specific logs configured, and now
you see it regardless?
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Rainer Jung <ra...@kippdata.de>.
Am 12.06.2015 um 19:12 schrieb William A Rowe Jr:
> Revision 1678233 - (view) (download) (annotate) - [select for diffs]
> Modified Thu May 7 16:26:43 2015 UTC (5 weeks, 1 day ago) by jim
> File length: 57106 byte(s)
> Diff to previous 1674655 (colored)
> Merge r1676085 from trunk:
>
> consistently output SSLCertificateChainFile deprecation warnings
> Submitted by: kbrand
> Reviewed/backported by: jim
>
> sent the warnings to the console/main server error log, rather than a
> specific server error log file. Because this is during config parsing,
> it that may have previously been a bit bucket. So this could be
> perceived as a regression although the logic and log file activity was
> there for some time.
Indeed there was a discussion thread for r1562500 in 2014 during which
Falco Schwarz reported, that he did *not* get the log message a anywhere
(neither console, not log files) when he had the directive only in
VirtualHosts. After the 2.4.13 change it seems to be new, that you get
the message massively on console, if you have the directive in frequent
use inside VHosts. That might well be perceived as a regression.
The 2.4.13 change replaced cmd->server in ap_log_error by NULL. The log
level "APLOG_WARNING|APLOG_STARTUP" was not changed.
Rainer
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Revision 1678233 - (view) (download) (annotate) - [select for diffs]
Modified Thu May 7 16:26:43 2015 UTC (5 weeks, 1 day ago) by jim
File length: 57106 byte(s)
Diff to previous 1674655 (colored)
Merge r1676085 from trunk:
consistently output SSLCertificateChainFile deprecation warnings
Submitted by: kbrand
Reviewed/backported by: jim
sent the warnings to the console/main server error log, rather than a
specific server error log file. Because this is during config parsing, it
that may have previously been a bit bucket. So this could be perceived as
a regression although the logic and log file activity was there for some
time.
On Fri, Jun 12, 2015 at 11:58 AM, Eric Covener <co...@gmail.com> wrote:
> It doesn't make sense for us to hold up a release when that change has
>>> been in the last several releases however. (That's a high barrier for
>>> making progress.)
>>>
>>>
> There seems to be a 2.4.8 component and an actual 2.4.13 component. Did
> the 2.4.13 fix make it more frequent.
>
> (fixing my top-post)
>
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jun 12, 2015 at 12:58 PM, Eric Covener <co...@gmail.com> wrote:
> It doesn't make sense for us to hold up a release when that change has
>>> been in the last several releases however. (That's a high barrier for
>>> making progress.)
>>>
>>>
> There seems to be a 2.4.8 component and an actual 2.4.13 component. Did
> the 2.4.13 fix make it more frequent.
>
> (fixing my top-post)
>
Hmmm, I have one situation with a 2.4.11-dev server that spits it out once
for each (similarly configured) vhost, so I may have been unlucky earlier
than some others.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Eric Covener <co...@gmail.com>.
>
> It doesn't make sense for us to hold up a release when that change has
>> been in the last several releases however. (That's a high barrier for
>> making progress.)
>>
>>
There seems to be a 2.4.8 component and an actual 2.4.13 component. Did the
2.4.13 fix make it more frequent.
(fixing my top-post)
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Eric Covener <co...@gmail.com>.
There seems to be a 2.4.8 component and an actual 2.4.13 component. Did the
2.4.13 fix make it more frequent?
On Fri, Jun 12, 2015 at 12:49 PM Jeff Trawick <tr...@gmail.com> wrote:
> On Fri, Jun 12, 2015 at 12:35 PM, Jacob Perkins <ja...@cpanel.net>
> wrote:
>
>> +1 to Noels comments. We have a ton of servers running Apache 2.4 with
>> our control panel. Doing this in a point release will cause us to have to
>> change our product instead of doing a regular Apache release.
>>
>> When you have a server with 10k+ SSL vhosts, this can cause massive,
>> unexpected problems. I have a feeling that this will cause massive
>> headaches with all those running Apache 2.4.
>>
>
> Thanks to Noel's comments, we have dropped this to one message at a
> quieter log level for the next 2.4.x release, and we can assist with a tiny
> patch to any recent 2.4.x.
>
> It doesn't make sense for us to hold up a release when that change has
> been in the last several releases however. (That's a high barrier for
> making progress.)
>
> Make sense?
>
>
> —
>> Jacob Perkins
>> Product Owner
>> *cPanel Inc.*
>>
>> jacob.perkins@cpanel.net
>> Office: 713-529-0800 x 4046
>> Cell: 713-560-8655
>>
>> On Jun 11, 2015, at 8:37 PM, Noel Butler <no...@ausics.net> wrote:
>>
>> On 12/06/2015 00:08, Jim Jagielski wrote:
>>
>>
>> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>>
>> [ ] +1: Good to go
>> [ ] +0: meh
>> [ ] -1: Danger Will Robinson. And why.
>>
>> -1
>>
>> "The SSLCertificateChainFile directive () is deprecated,
>> SSLCertificateFile should be used instead"
>>
>> The constant warnings on start, stop, and even reload for every single
>> SSL host is unacceptable.
>>
>> This should never have been contemplated for a "point" release anyway.
>>
>> Clearly no consideration has been given to the headaches and collateral
>> damage this will cause, some hosts have tens of thousands of SSL hosts,
>> even a server reload will flood the hell out of them, most system/CP
>> scripts look for a specific, or no output, after reload, this results in
>> unexpected output and will trigger alarms, likely causing many systems to
>> think " oh there was a problem adding this host, so I wont continue adding
>> them into anything else and fail the entire new customer process" again,
>> creating serious problems for those required to maintain these things.
>>
>>
>> It might be fine and dandy for a stand alone single SSL host server that
>> is manually managed, but dont forget many hosts run up to 2+K hosts on a
>> single server with many of them SSL, that is a lot of change when you have
>> a server room half full of them, not to mention any inhouse scripting or
>> control panels that will need to be modified to cater for such changes to
>> create the new certs and deal with it all.
>>
>>
>> I for one will not place this release on any production servers. My
>> recommendation is that chainfile remain as it is - at the very least for
>> the 2.4 series, and if it is not enough to stop or delay this release to
>> revert, then I sincerely hope it is changed in trunk for the next.
>>
>>
>>
>>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
>
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Rainer Jung <ra...@kippdata.de>.
Am 12.06.2015 um 18:48 schrieb Jeff Trawick:
> On Fri, Jun 12, 2015 at 12:35 PM, Jacob Perkins
> <jacob.perkins@cpanel.net <ma...@cpanel.net>> wrote:
>
> +1 to Noels comments. We have a ton of servers running Apache 2.4
> with our control panel. Doing this in a point release will cause us
> to have to change our product instead of doing a regular Apache
> release.
>
> When you have a server with 10k+ SSL vhosts, this can cause massive,
> unexpected problems. I have a feeling that this will cause massive
> headaches with all those running Apache 2.4.
>
>
> Thanks to Noel's comments, we have dropped this to one message at a
> quieter log level for the next 2.4.x release, and we can assist with a
> tiny patch to any recent 2.4.x.
>
> It doesn't make sense for us to hold up a release when that change has
> been in the last several releases however. (That's a high barrier for
> making progress.)
>
> Make sense?
Agreed, I forgot about that, the warning exists since 2.4.9 in March
2014. So from my project member point of view you are totally right.
Rainer
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jun 12, 2015 at 12:35 PM, Jacob Perkins <ja...@cpanel.net>
wrote:
> +1 to Noels comments. We have a ton of servers running Apache 2.4 with
> our control panel. Doing this in a point release will cause us to have to
> change our product instead of doing a regular Apache release.
>
> When you have a server with 10k+ SSL vhosts, this can cause massive,
> unexpected problems. I have a feeling that this will cause massive
> headaches with all those running Apache 2.4.
>
Thanks to Noel's comments, we have dropped this to one message at a quieter
log level for the next 2.4.x release, and we can assist with a tiny patch
to any recent 2.4.x.
It doesn't make sense for us to hold up a release when that change has been
in the last several releases however. (That's a high barrier for making
progress.)
Make sense?
—
> Jacob Perkins
> Product Owner
> *cPanel Inc.*
>
> jacob.perkins@cpanel.net
> Office: 713-529-0800 x 4046
> Cell: 713-560-8655
>
> On Jun 11, 2015, at 8:37 PM, Noel Butler <no...@ausics.net> wrote:
>
> On 12/06/2015 00:08, Jim Jagielski wrote:
>
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
>
> -1
>
> "The SSLCertificateChainFile directive () is deprecated,
> SSLCertificateFile should be used instead"
>
> The constant warnings on start, stop, and even reload for every single SSL
> host is unacceptable.
>
> This should never have been contemplated for a "point" release anyway.
>
> Clearly no consideration has been given to the headaches and collateral
> damage this will cause, some hosts have tens of thousands of SSL hosts,
> even a server reload will flood the hell out of them, most system/CP
> scripts look for a specific, or no output, after reload, this results in
> unexpected output and will trigger alarms, likely causing many systems to
> think " oh there was a problem adding this host, so I wont continue adding
> them into anything else and fail the entire new customer process" again,
> creating serious problems for those required to maintain these things.
>
>
> It might be fine and dandy for a stand alone single SSL host server that
> is manually managed, but dont forget many hosts run up to 2+K hosts on a
> single server with many of them SSL, that is a lot of change when you have
> a server room half full of them, not to mention any inhouse scripting or
> control panels that will need to be modified to cater for such changes to
> create the new certs and deal with it all.
>
>
> I for one will not place this release on any production servers. My
> recommendation is that chainfile remain as it is - at the very least for
> the 2.4 series, and if it is not enough to stop or delay this release to
> revert, then I sincerely hope it is changed in trunk for the next.
>
>
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jacob Perkins <ja...@cpanel.net>.
+1 to Noels comments. We have a ton of servers running Apache 2.4 with our control panel. Doing this in a point release will cause us to have to change our product instead of doing a regular Apache release.
When you have a server with 10k+ SSL vhosts, this can cause massive, unexpected problems. I have a feeling that this will cause massive headaches with all those running Apache 2.4.
—
Jacob Perkins
Product Owner
cPanel Inc.
jacob.perkins@cpanel.net <ma...@cpanel.net>
Office: 713-529-0800 x 4046
Cell: 713-560-8655
> On Jun 11, 2015, at 8:37 PM, Noel Butler <no...@ausics.net> wrote:
>
> On 12/06/2015 00:08, Jim Jagielski wrote:
>
>>
>> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>>
>> [ ] +1: Good to go
>> [ ] +0: meh
>> [ ] -1: Danger Will Robinson. And why.
>>
> -1
>
> "The SSLCertificateChainFile directive () is deprecated, SSLCertificateFile should be used instead"
>
> The constant warnings on start, stop, and even reload for every single SSL host is unacceptable.
>
> This should never have been contemplated for a "point" release anyway.
>
> Clearly no consideration has been given to the headaches and collateral damage this will cause, some hosts have tens of thousands of SSL hosts, even a server reload will flood the hell out of them, most system/CP scripts look for a specific, or no output, after reload, this results in unexpected output and will trigger alarms, likely causing many systems to think " oh there was a problem adding this host, so I wont continue adding them into anything else and fail the entire new customer process" again, creating serious problems for those required to maintain these things.
>
>
> It might be fine and dandy for a stand alone single SSL host server that is manually managed, but dont forget many hosts run up to 2+K hosts on a single server with many of them SSL, that is a lot of change when you have a server room half full of them, not to mention any inhouse scripting or control panels that will need to be modified to cater for such changes to create the new certs and deal with it all.
>
>
> I for one will not place this release on any production servers. My recommendation is that chainfile remain as it is - at the very least for the 2.4 series, and if it is not enough to stop or delay this release to revert, then I sincerely hope it is changed in trunk for the next.
>
>
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Noel Butler <no...@ausics.net>.
On 12/06/2015 00:08, Jim Jagielski wrote:
> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
-1
"The SSLCertificateChainFile directive () is deprecated,
SSLCertificateFile should be used instead"
The constant warnings on start, stop, and even reload for every single
SSL host is unacceptable.
This should never have been contemplated for a "point" release anyway.
Clearly no consideration has been given to the headaches and collateral
damage this will cause, some hosts have tens of thousands of SSL hosts,
even a server reload will flood the hell out of them, most system/CP
scripts look for a specific, or no output, after reload, this results in
unexpected output and will trigger alarms, likely causing many systems
to think " oh there was a problem adding this host, so I wont continue
adding them into anything else and fail the entire new customer process"
again, creating serious problems for those required to maintain these
things.
It might be fine and dandy for a stand alone single SSL host server that
is manually managed, but dont forget many hosts run up to 2+K hosts on a
single server with many of them SSL, that is a lot of change when you
have a server room half full of them, not to mention any inhouse
scripting or control panels that will need to be modified to cater for
such changes to create the new certs and deal with it all.
I for one will not place this release on any production servers. My
recommendation is that chainfile remain as it is - at the very least for
the 2.4 series, and if it is not enough to stop or delay this release to
revert, then I sincerely hope it is changed in trunk for the next.
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jun 11, 2015, at 10:08 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> The pre-release test tarballs for Apache httpd 2.4.14 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>
> [X] +1: Good to go
Go for release:
o OSX 10.10.3/Xcode 6.3.2, x86_64
o Fedora 20, x86_64
o CentOS 6, x86_64
o FreeBSD 10, x86_64
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Jun 13, 2015 at 9:24 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Thu, Jun 11, 2015 at 10:08 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> The pre-release test tarballs for Apache httpd 2.4.14 can be found
>> at the usual place:
>>
>> http://httpd.apache.org/dev/dist/
>>
>> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>>
>> [ ] +1: Good to go
>> [ ] +0: meh
>> [ ] -1: Danger Will Robinson. And why.
>>
>>
> CentOS 7, 64-bit: HTTP::DAV skipped; event and prefork tested, no failures
>
> FreeBSD 10.1, 32-bit: lua skipped, accept filter not loaded, event and
> prefork tested
>
> Test Summary Report
> -------------------
> t/ssl/pr12355.t (Wstat: 0 Tests: 10 Failed: 4)
> Failed tests: 3-4, 7-8
> t/ssl/pr43738.t (Wstat: 0 Tests: 4 Failed: 2)
> Failed tests: 1-2
>
> (same as with 2.4.13)
>
> My vote: -1 for now :(
>
That won't change :( I don't think we can proxy to httpd 1.3[-based]
servers anymore and accept chunked responses.
> Steffen's apparent regression between 2.4.13 and 2.4.14 needs to be
> investigated if he is able to assist further. Other than that, I am
> concerned about the console message issue with lots of SSL-enabled vhosts
> but no per-vhost LogLevel (no deprecation messages before, lots now) but I
> think that could be addressed in a recommended patch.
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Jun 11, 2015 at 10:08 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> The pre-release test tarballs for Apache httpd 2.4.14 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
>
>
CentOS 7, 64-bit: HTTP::DAV skipped; event and prefork tested, no failures
FreeBSD 10.1, 32-bit: lua skipped, accept filter not loaded, event and
prefork tested
Test Summary Report
-------------------
t/ssl/pr12355.t (Wstat: 0 Tests: 10 Failed: 4)
Failed tests: 3-4, 7-8
t/ssl/pr43738.t (Wstat: 0 Tests: 4 Failed: 2)
Failed tests: 1-2
(same as with 2.4.13)
My vote: -1 for now :(
Steffen's apparent regression between 2.4.13 and 2.4.14 needs to be
investigated if he is able to assist further. Other than that, I am
concerned about the console message issue with lots of SSL-enabled vhosts
but no per-vhost LogLevel (no deprecation messages before, lots now) but I
think that could be addressed in a recommended patch.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Rainer Jung <ra...@kippdata.de>.
Am 14.06.2015 um 19:17 schrieb Rainer Jung:
>> [X] -1: Danger Will Robinson. And why.
>
> Not an easy call.
>
> -1 but even more thanks for RMing.
>
> Negative vote due to:
>
> - chance of breaking chunked encoding due to spec intolerance.
s/spec/space/ - Sorry.
> Proxy example reported by Steffen plus
> at least anecdotal evidence by Jeff (Apache 1.3 backends).
>
> - mass occurrence of SSLCertificateChainFile deprecation warning
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Rainer Jung <ra...@kippdata.de>.
Am 11.06.2015 um 16:08 schrieb Jim Jagielski:
> The pre-release test tarballs for Apache httpd 2.4.14 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [X] -1: Danger Will Robinson. And why.
Not an easy call.
-1 but even more thanks for RMing.
Negative vote due to:
- chance of breaking chunked encoding due to spec intolerance.
Proxy example reported by Steffen plus
at least anecdotal evidence by Jeff (Apache 1.3 backends).
- mass occurrence of SSLCertificateChainFile deprecation warning
IMHO it would be better to tolerate white space in chunk header, as
suggested by Yann now in STATUS.
Concerning the deprecation warnings I'm not sure what the current
consensus for best behavior is. I think we want only one log message,
not one per VHosts. Probably undecided currently:
- log level of this one message (IMHO: WARNING)
- send it to log file only or also to console (IMHO: log file only)
- should we indicate in the message, that here might be other places
using SSLCertificateChainFile as well? (IMHO yes)
- should we log all the other places, but only to log file and with info
or debug log level? (IMHO no, because it could be quite a lot and
switching to debug would make it invisible for most people; find/grep is
not that hard)
Test using test suite:
In short: No regressions found.
Detailed report:
- Sigs and hashes OK
- contents of tarballs identical
- contents of tag and tarballs identical
except for expected deltas
(we could cleanup some m4 files in apr-util/xml/expat/conftools
at the end of buildconf, no regression)
Built on
- Solaris 8+10 Sparc as 32 Bit Binaries
- SLES 10+11 (64 Bits)
- RHEL 6 (64 Bits)
For all platforms built
- with default (shared), shared and static modules
- with module sets none, few, most, all, reallyall and default
(always mod_privileges disabled)
- using --enable-load-all-modules
- against "included" APR/APU from deps tarball,
plus external APR/APU 1.5.2/1.5.4
- using external libraries
- expat 2.1.0
- pcre 8.37
- openssl 1.0.1n
- lua 5.2.4
- distcache 1.5.1
- libxml2 2.9.2
- Tool chain:
- platform gcc except for Solaris
(gcc 4.1.2 for Solaris 8 and 4.9.2 for Solaris 10)
- CFLAGS: -O2 -g -Wall -fno-strict-aliasing
(and -mpcu=v9 on Solaris)
All builds succeeded
- two compiler warnings
server/mpm/event/event.c:1438: warning: 'last' may be used uninitialized
in this function
ssl/ssl_util_stapling.c:657: warning: 'ok' may be used uninitialized in
this function
Tested for
- Solaris 8+10 (32), SLES 10+11 (64), RHEL 6 (64)
- MPMs prefork, worker, event
(except event on Solaris8, unsupported)
- default, shared and static modules
- log levels info, debug and trace8
- module set reallyall (121 modules plus MPMs)
The following test failures were seen:
a Test 4 or 5 in t/modules/dav.t:
Happens for 27 out of 364 runs.
Creation, modified and now times not in the correct order.
This seems to be a system issue, all tests done on NFS,
many tested on virtualized guests.
Not a regression.
b Various tests in t/apache/expr_string.t: (6, 11, 14, 17, 20 ,23)
Happens for 63 out of 364 runs (almost all on SLES 10, 6 on RHEL6
and 1 on Solaris 8).
The failure is always on line 68, where the error_log contents
are checked.
Not a regression.
c Tests 55-57 of t/modules/cgi.t testing contents of ScriptLog.
Likely similar than what I observed for 2.4.12.
Fix probably by porting r1651085 from mod_cgi to mod_cgid.
Not a regression.
Regards,
Rainer
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Yann Ylavic <yl...@gmail.com>.
On Sun, Jun 14, 2015 at 11:09 AM, olli hauer <oh...@gmx.de> wrote:
> On 2015-06-14 02:46, Jeff Trawick wrote:
>> On Sat, Jun 13, 2015 at 7:42 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>
>>> On Sun, Jun 14, 2015 at 1:18 AM, Jeff Trawick <tr...@gmail.com> wrote:
>>>> On Sat, Jun 13, 2015 at 6:06 PM, Yann Ylavic <yl...@gmail.com>
>>> wrote:
>>>>>
>>>>> I did not look at pr12355.t and pr43738.t yet, however those passed in
>>>>> my tests, so it's probably something different.
>>>>
>>>>
>>>> Just in case it wasn't clear, these aren't regressions. I get them with
>>>> prior releases on FreeBSD 10.1 also.
>>>
>>> Ah ok, those are possibly the same as I reported in [1] for the 2.4.13
>>> vote (in the Post Scriptum, about latest stable debian 8).
>>>
>>>>
>>>> I don't know if it is the Perl stack or OpenSSL or ??? that results in
>>> the
>>>> consistent failure. (This FreeBSD has a significantly newer Perl stack
>>> from
>>>> system packages than CentOS 7.) IIUC, Rainer has been reporting
>>>> intermittent failures on various platforms for a while.
>>>
>>> It seems to be related to latest OpenSSL, maybe RC5 isn't handled anymore?
>>>
>>
>> I just tried on Fedora 22...
>>
>> For both the Perl interpreter/lib versions and OpenSSL versions, it seems
>> to be essentially
>>
>> CentOS 7 < FreeBSD 10.1 < Fedora 22
>>
>> and the one in the middle is the only one where I see the issue.
>>
>> The CentOS and Fedora builds of OpenSSL are FIPS-enabled; I don't know how
>> that affects the enabled ciphers.
>>
>
> From OpenSSL CHANGES (happed already with 0.9.7i in 2005)
> The patented RC5 and MDC2 algorithms will now be disabled unless
> "enable-rc5" and "enable-mdc2", respectively, are specified.
>
> And from src/crypto/openssl/Makefile
> OPTIONS= ... no-md2 no-rc5 ...
>
> OpenSSL is build in FreeBSD base with
> ... -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 ...
>
> So is assume tests for RC5 and MD2 will always fail.
Sorry for the noise about RC5, I was misleaded by a typo in
ssl/pr12355.t which talks about RC5-MD5 where RC4-MD5 is probably
meant (the test seems for force a renegotiation by using exclusively
either RC4-SHA or RC4-MD5).
So that was a wrong track.
However on Debian 8 (Jessie) where I can reproduce the failures here
for pr12355.t and pr43738.t, openssl is configured/compiled with
no_ssl3 (same on FreeBSD 10.1?).
This is more likely the cause, will dig a bit further into this...
Thanks for the ./configure hint anyway.
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by olli hauer <oh...@gmx.de>.
On 2015-06-14 02:46, Jeff Trawick wrote:
> On Sat, Jun 13, 2015 at 7:42 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
>> On Sun, Jun 14, 2015 at 1:18 AM, Jeff Trawick <tr...@gmail.com> wrote:
>>> On Sat, Jun 13, 2015 at 6:06 PM, Yann Ylavic <yl...@gmail.com>
>> wrote:
>>>>
>>>> I did not look at pr12355.t and pr43738.t yet, however those passed in
>>>> my tests, so it's probably something different.
>>>
>>>
>>> Just in case it wasn't clear, these aren't regressions. I get them with
>>> prior releases on FreeBSD 10.1 also.
>>
>> Ah ok, those are possibly the same as I reported in [1] for the 2.4.13
>> vote (in the Post Scriptum, about latest stable debian 8).
>>
>>>
>>> I don't know if it is the Perl stack or OpenSSL or ??? that results in
>> the
>>> consistent failure. (This FreeBSD has a significantly newer Perl stack
>> from
>>> system packages than CentOS 7.) IIUC, Rainer has been reporting
>>> intermittent failures on various platforms for a while.
>>
>> It seems to be related to latest OpenSSL, maybe RC5 isn't handled anymore?
>>
>
> I just tried on Fedora 22...
>
> For both the Perl interpreter/lib versions and OpenSSL versions, it seems
> to be essentially
>
> CentOS 7 < FreeBSD 10.1 < Fedora 22
>
> and the one in the middle is the only one where I see the issue.
>
> The CentOS and Fedora builds of OpenSSL are FIPS-enabled; I don't know how
> that affects the enabled ciphers.
>
>From OpenSSL CHANGES (happed already with 0.9.7i in 2005)
The patented RC5 and MDC2 algorithms will now be disabled unless
"enable-rc5" and "enable-mdc2", respectively, are specified.
And from src/crypto/openssl/Makefile
OPTIONS= ... no-md2 no-rc5 ...
OpenSSL is build in FreeBSD base with
... -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 ...
So is assume tests for RC5 and MD2 will always fail.
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Jun 13, 2015 at 7:42 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Sun, Jun 14, 2015 at 1:18 AM, Jeff Trawick <tr...@gmail.com> wrote:
> > On Sat, Jun 13, 2015 at 6:06 PM, Yann Ylavic <yl...@gmail.com>
> wrote:
> >>
> >> I did not look at pr12355.t and pr43738.t yet, however those passed in
> >> my tests, so it's probably something different.
> >
> >
> > Just in case it wasn't clear, these aren't regressions. I get them with
> > prior releases on FreeBSD 10.1 also.
>
> Ah ok, those are possibly the same as I reported in [1] for the 2.4.13
> vote (in the Post Scriptum, about latest stable debian 8).
>
> >
> > I don't know if it is the Perl stack or OpenSSL or ??? that results in
> the
> > consistent failure. (This FreeBSD has a significantly newer Perl stack
> from
> > system packages than CentOS 7.) IIUC, Rainer has been reporting
> > intermittent failures on various platforms for a while.
>
> It seems to be related to latest OpenSSL, maybe RC5 isn't handled anymore?
>
I just tried on Fedora 22...
For both the Perl interpreter/lib versions and OpenSSL versions, it seems
to be essentially
CentOS 7 < FreeBSD 10.1 < Fedora 22
and the one in the middle is the only one where I see the issue.
The CentOS and Fedora builds of OpenSSL are FIPS-enabled; I don't know how
that affects the enabled ciphers.
>
> [1]
> https://mail-archives.apache.org/mod_mbox/httpd-dev/201506.mbox/%3CCAKQ1sVP7iOJWoLpjw6mWODxyxnhTVB32-RMM-ZV_DqwjXR1GPg@mail.gmail.com%3E
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Yann Ylavic <yl...@gmail.com>.
On Sun, Jun 14, 2015 at 1:18 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Sat, Jun 13, 2015 at 6:06 PM, Yann Ylavic <yl...@gmail.com> wrote:
>>
>> I did not look at pr12355.t and pr43738.t yet, however those passed in
>> my tests, so it's probably something different.
>
>
> Just in case it wasn't clear, these aren't regressions. I get them with
> prior releases on FreeBSD 10.1 also.
Ah ok, those are possibly the same as I reported in [1] for the 2.4.13
vote (in the Post Scriptum, about latest stable debian 8).
>
> I don't know if it is the Perl stack or OpenSSL or ??? that results in the
> consistent failure. (This FreeBSD has a significantly newer Perl stack from
> system packages than CentOS 7.) IIUC, Rainer has been reporting
> intermittent failures on various platforms for a while.
It seems to be related to latest OpenSSL, maybe RC5 isn't handled anymore?
[1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201506.mbox/%3CCAKQ1sVP7iOJWoLpjw6mWODxyxnhTVB32-RMM-ZV_DqwjXR1GPg@mail.gmail.com%3E
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Jun 13, 2015 at 6:06 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Sat, Jun 13, 2015 at 6:51 PM, Rainer Jung <ra...@kippdata.de>
> wrote:
> >
> > any chance you can reproduce the problem with a slightly patched 2.4.14
> to
> > get additional log output around the suspect code?
> >
> > The patch would be
> >
> > Index: modules/http/http_filters.c
> > ===================================================================
> > --- modules/http/http_filters.c (revision 1685283)
> > +++ modules/http/http_filters.c (working copy)
> > @@ -514,6 +514,9 @@
> > rv = parse_chunk_size(ctx, buffer, len,
> >
> > f->r->server->limit_req_fieldsize);
> > if (rv != APR_SUCCESS) {
> > + ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, f->r,
> > APLOGNO(99999)
> > + "Error parsing chunk size, buffer
> > %*.*s, limit %d",
> > + len, len, buffer,
> > f->r->server->limit_req_fieldsize);
> > if (rv != APR_ENOSPC) {
> > http_error = HTTP_BAD_REQUEST;
> > }
>
> Hmm, it seems that the backported patch in r1684515 is not the
> proposed/voted v5, where AH01590 would normally have been logged here.
> Bill, looks like v4 was applied instead... Attached is the diff on
> http_filter.c between the two patches.
>
> BTW, v5 does not address the regression encountered by Steffen either:
> space(s) between the chunk-size and the CRLF which are not allowed
> anymore.
> This is not really RFC compliant, but I guess we have to be lenient here...
>
> I did not look at pr12355.t and pr43738.t yet, however those passed in
> my tests, so it's probably something different.
>
Just in case it wasn't clear, these aren't regressions. I get them with
prior releases on FreeBSD 10.1 also.
I don't know if it is the Perl stack or OpenSSL or ??? that results in the
consistent failure. (This FreeBSD has a significantly newer Perl stack
from system packages than CentOS 7.) IIUC, Rainer has been reporting
intermittent failures on various platforms for a while.
> Jeff, any idea where these failures can come from?
> What do -v and the logs say?
>
pr12355.t only:
# testing : renegotiation on POST works
# expected: 200
# received: 500
not ok 3
# testing : request body matches response
# expected: 'hello world'
# received: 'Status read failed: at
/usr/local/lib/perl5/site_perl/Net/HTTP/Methods.pm line 289.
# '
not ok 4
...
# testing : renegotiation on POST works
# expected: 200
# received: 500
not ok 7
# testing : request body matches response
# expected: 'xxxxxx...
# received: 'Status read failed: at
/usr/local/lib/perl5/site_perl/Net/HTTP/Methods.pm line 289.
# '
not ok 8
I think this is the underlying failure I'm seeing, possibly for both
testcases:
Sat Jun 13 23:08:55.005710 2015] [ssl:error] [pid 3745] [client
127.0.0.1:44064] AH02261: Re-negotiation handshake failed
[Sat Jun 13 23:08:55.005743 2015] [ssl:error] [pid 3745] SSL Library Error:
error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher -- Too
restrictive SSLCipherSuite or using DSA server certificate?
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Yann Ylavic <yl...@gmail.com>.
On Sat, Jun 13, 2015 at 6:51 PM, Rainer Jung <ra...@kippdata.de> wrote:
>
> any chance you can reproduce the problem with a slightly patched 2.4.14 to
> get additional log output around the suspect code?
>
> The patch would be
>
> Index: modules/http/http_filters.c
> ===================================================================
> --- modules/http/http_filters.c (revision 1685283)
> +++ modules/http/http_filters.c (working copy)
> @@ -514,6 +514,9 @@
> rv = parse_chunk_size(ctx, buffer, len,
>
> f->r->server->limit_req_fieldsize);
> if (rv != APR_SUCCESS) {
> + ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, f->r,
> APLOGNO(99999)
> + "Error parsing chunk size, buffer
> %*.*s, limit %d",
> + len, len, buffer,
> f->r->server->limit_req_fieldsize);
> if (rv != APR_ENOSPC) {
> http_error = HTTP_BAD_REQUEST;
> }
Hmm, it seems that the backported patch in r1684515 is not the
proposed/voted v5, where AH01590 would normally have been logged here.
Bill, looks like v4 was applied instead... Attached is the diff on
http_filter.c between the two patches.
BTW, v5 does not address the regression encountered by Steffen either:
space(s) between the chunk-size and the CRLF which are not allowed
anymore.
This is not really RFC compliant, but I guess we have to be lenient here...
I did not look at pr12355.t and pr43738.t yet, however those passed in
my tests, so it's probably something different.
Jeff, any idea where these failures can come from?
What do -v and the logs say?
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Steffen,
any chance you can reproduce the problem with a slightly patched 2.4.14
to get additional log output around the suspect code?
The patch would be
Index: modules/http/http_filters.c
===================================================================
--- modules/http/http_filters.c (revision 1685283)
+++ modules/http/http_filters.c (working copy)
@@ -514,6 +514,9 @@
rv = parse_chunk_size(ctx, buffer, len,
f->r->server->limit_req_fieldsize);
if (rv != APR_SUCCESS) {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, f->r,
APLOGNO(99999)
+ "Error parsing chunk size, buffer
%*.*s, limit %d",
+ len, len, buffer,
f->r->server->limit_req_fieldsize);
if (rv != APR_ENOSPC) {
http_error = HTTP_BAD_REQUEST;
}
It will *not* fix the problem but should give us enough additional info
to find out why it is happening.
It would be great if you could patch your 2.4.14, rebuild and rerun the
Sambar test.
Thanks a bunch!
Rainer
Am 13.06.2015 um 15:36 schrieb Steffen:
> Debug 2.4.14 was already in my first post.
> The 2.4.13 (no error) and 2.4.14 debug level error.log:
> Apache/2.4.13 (Win32)
> ================
> [Sat Jun 13 15:23:23.031198 2015] [authz_core:debug] [pid 9208:tid 1168]
> mod_authz_core.c(834): [client 127.0.0.1:54501] AH01628: authorization
> result: granted (no directives)
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> mod_proxy.c(1157): [client 127.0.0.1:54501] AH01143: Running scheme http
> handler (attempt 0)
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> proxy_util.c(2199): [client 127.0.0.1:54501] AH00944: connecting
> http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> proxy_util.c(2408): [client 127.0.0.1:54501] AH00947: connected
> /sysadmin/ to 127.0.0.1:81
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> proxy_util.c(2782): AH02824: HTTP: connection established with
> 127.0.0.1:81 (127.0.0.1)
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
> (127.0.0.1)
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> proxy_util.c(2160): AH00943: http: has released connection for (127.0.0.1)
> Apache/2.4.14 (Win32)
> =================
> [Sat Jun 13 15:20:54.616551 2015] [authz_core:debug] [pid 4676:tid 1152]
> mod_authz_core.c(834): [client 127.0.0.1:54430] AH01628: authorization
> result: granted (no directives)
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> mod_proxy.c(1157): [client 127.0.0.1:54430] AH01143: Running scheme http
> handler (attempt 0)
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> proxy_util.c(2199): [client 127.0.0.1:54430] AH00944: connecting
> http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> proxy_util.c(2408): [client 127.0.0.1:54430] AH00947: connected
> /sysadmin/ to 127.0.0.1:81
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> proxy_util.c(2782): AH02824: HTTP: connection established with
> 127.0.0.1:81 (127.0.0.1)
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
> (127.0.0.1)
> [Sat Jun 13 15:20:54.616551 2015] [proxy_http:error] [pid 4676:tid 1152]
> (20014)Internal error (specific information not available): [client
> 127.0.0.1:54430] AH01110: error reading response
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> proxy_util.c(2160): AH00943: HTTP: has released connection for (127.0.0.1)
> *From:* Jeff Trawick <ma...@gmail.com>
> *Sent:* Saturday, June 13, 2015 3:14 PM
> *Newsgroups:* gmane.comp.apache.devel
> *To:* Apache HTTP Server Development List <ma...@httpd.apache.org>
> *Subject:* Re: [VOTE] Release Apache httpd 2.4.14 as GA
> On Sat, Jun 13, 2015 at 8:31 AM, Steffen <info@apachelounge.com
> <ma...@apachelounge.com>> wrote:
>
> Tested with 2.4.13 tarball, then no error.
>
> Wow...
> Is anything written to the error log when you try proxy to the Sambar
> server? If my guess about the related code is correct, you'll need
> LogLevel Info (or debug or trace) to see all the relevant messages.
>
>
> -----Original Message----- From: Steffen
> Sent: Saturday, June 13, 2015 1:33 PM Newsgroups:
> gmane.comp.apache.devel
> To: dev@httpd.apache.org <ma...@httpd.apache.org>
> Subject: Re: [VOTE] Release Apache httpd 2.4.14 as GA
>
>
> Regression: All works fine except a Proxy Pass to Sambar server, was
> working ok with 2.4.12.
>
> ProxyPasses to other servers the Sambar works fine.
>
> ProxyPass /sysadmin http://127.0.0.1:81/sysadmin
> ProxyPassReverse /sysadmin http://127.0.0.1:81/sysadmin
>
> Calling with http://127.0.0.1:8080/sysadmin/ gives AH01110: error
> reading
> response :
>
> [Sat Jun 13 13:23:08.010826 2015] [authz_core:debug] [pid 5684:tid 1128]
> mod_authz_core.c(834): [client ::1:51072] AH01628: authorization result:
> granted (no directives)
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> mod_proxy.c(1157): [client ::1:51072] AH01143: Running scheme http
> handler
> (attempt 0)
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2145): AH00942: HTTP: has acquired connection for
> (127.0.0.1)
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2199): [client ::1:51072] AH00944: connecting
> http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81 <http://127.0.0.1:81>
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2408): [client ::1:51072] AH00947: connected /sysadmin/ to
> 127.0.0.1:81 <http://127.0.0.1:81>
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2782): AH02824: HTTP: connection established with
> 127.0.0.1:81 <http://127.0.0.1:81>
> (127.0.0.1)
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2936): AH00962: HTTP: connection complete to
> 127.0.0.1:81 <http://127.0.0.1:81>
> (127.0.0.1)
> [Sat Jun 13 13:23:08.010826 2015] [proxy_http:error] [pid 5684:tid 1128]
> (20014)Internal error (specific information not available): [client
> ::1:51072] AH01110: error reading response
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2160): AH00943: HTTP: has released connection for
> (127.0.0.1)
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2878): [remote 127.0.0.1:81 <http://127.0.0.1:81>]
> AH02642: proxy: connection
> shutdown
>
>
>
> -----Original Message----- From: Jim Jagielski
> Sent: Thursday, June 11, 2015 4:08 PM Newsgroups:
> gmane.comp.apache.devel
> To: httpd
> Subject: [VOTE] Release Apache httpd 2.4.14 as GA
>
> The pre-release test tarballs for Apache httpd 2.4.14 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
>
> Vote will last the normal 72 hrs.
>
> NOTE: The *-deps are only there for convenience.
>
> Thx!
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
--
kippdata
informationstechnologie GmbH Tel: 0228 98549 -0
Bornheimer Str. 33a Fax: 0228 98549 -50
53111 Bonn www.kippdata.de
HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Jun 13, 2015 at 9:36 AM, Steffen <in...@apachelounge.com> wrote:
> Debug 2.4.14 was already in my first post.
>
sorry!
>
> The 2.4.13 (no error) and 2.4.14 debug level error.log:
>
> Apache/2.4.13 (Win32)
> ================
>
> [Sat Jun 13 15:23:23.031198 2015] [authz_core:debug] [pid 9208:tid 1168]
> mod_authz_core.c(834): [client 127.0.0.1:54501] AH01628: authorization
> result: granted (no directives)
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> mod_proxy.c(1157): [client 127.0.0.1:54501] AH01143: Running scheme http
> handler (attempt 0)
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> proxy_util.c(2199): [client 127.0.0.1:54501] AH00944: connecting
> http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> proxy_util.c(2408): [client 127.0.0.1:54501] AH00947: connected
> /sysadmin/ to 127.0.0.1:81
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> proxy_util.c(2782): AH02824: HTTP: connection established with
> 127.0.0.1:81 (127.0.0.1)
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
> (127.0.0.1)
> [Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168]
> proxy_util.c(2160): AH00943: http: has released connection for (127.0.0.1)
>
>
>
> Apache/2.4.14 (Win32)
> =================
>
> [Sat Jun 13 15:20:54.616551 2015] [authz_core:debug] [pid 4676:tid 1152]
> mod_authz_core.c(834): [client 127.0.0.1:54430] AH01628: authorization
> result: granted (no directives)
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> mod_proxy.c(1157): [client 127.0.0.1:54430] AH01143: Running scheme http
> handler (attempt 0)
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> proxy_util.c(2199): [client 127.0.0.1:54430] AH00944: connecting
> http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> proxy_util.c(2408): [client 127.0.0.1:54430] AH00947: connected
> /sysadmin/ to 127.0.0.1:81
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> proxy_util.c(2782): AH02824: HTTP: connection established with
> 127.0.0.1:81 (127.0.0.1)
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
> (127.0.0.1)
> [Sat Jun 13 15:20:54.616551 2015] [proxy_http:error] [pid 4676:tid 1152]
> (20014)Internal error (specific information not available): [client
> 127.0.0.1:54430] AH01110: error reading response
> [Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152]
> proxy_util.c(2160): AH00943: HTTP: has released connection for (127.0.0.1)
>
>
AH01110 reading backend server response...
Just looking for APR_EGENERAL in modified code that doesn't have a log
message, I guess it is chunked and we hit this APR_EGENERAL ("Internal
error"):
+ else {
+ /* Should not happen */
+ return APR_EGENERAL;
+ }
Any better guesses out there?
>
> *From:* Jeff Trawick <tr...@gmail.com>
> *Sent:* Saturday, June 13, 2015 3:14 PM
> *Newsgroups:* gmane.comp.apache.devel
> *To:* Apache HTTP Server Development List <de...@httpd.apache.org>
> *Subject:* Re: [VOTE] Release Apache httpd 2.4.14 as GA
>
> On Sat, Jun 13, 2015 at 8:31 AM, Steffen <in...@apachelounge.com> wrote:
>
>> Tested with 2.4.13 tarball, then no error.
>>
>
> Wow...
>
> Is anything written to the error log when you try proxy to the Sambar
> server? If my guess about the related code is correct, you'll need
> LogLevel Info (or debug or trace) to see all the relevant messages.
>
>
>
>>
>> -----Original Message----- From: Steffen
>> Sent: Saturday, June 13, 2015 1:33 PM Newsgroups: gmane.comp.apache.devel
>> To: dev@httpd.apache.org
>> Subject: Re: [VOTE] Release Apache httpd 2.4.14 as GA
>>
>>
>> Regression: All works fine except a Proxy Pass to Sambar server, was
>> working ok with 2.4.12.
>>
>> ProxyPasses to other servers the Sambar works fine.
>>
>> ProxyPass /sysadmin http://127.0.0.1:81/sysadmin
>> ProxyPassReverse /sysadmin http://127.0.0.1:81/sysadmin
>>
>> Calling with http://127.0.0.1:8080/sysadmin/ gives AH01110: error reading
>> response :
>>
>> [Sat Jun 13 13:23:08.010826 2015] [authz_core:debug] [pid 5684:tid 1128]
>> mod_authz_core.c(834): [client ::1:51072] AH01628: authorization result:
>> granted (no directives)
>> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
>> mod_proxy.c(1157): [client ::1:51072] AH01143: Running scheme http handler
>> (attempt 0)
>> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
>> proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
>> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
>> proxy_util.c(2199): [client ::1:51072] AH00944: connecting
>> http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
>> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
>> proxy_util.c(2408): [client ::1:51072] AH00947: connected /sysadmin/ to
>> 127.0.0.1:81
>> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
>> proxy_util.c(2782): AH02824: HTTP: connection established with
>> 127.0.0.1:81
>> (127.0.0.1)
>> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
>> proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
>> (127.0.0.1)
>> [Sat Jun 13 13:23:08.010826 2015] [proxy_http:error] [pid 5684:tid 1128]
>> (20014)Internal error (specific information not available): [client
>> ::1:51072] AH01110: error reading response
>> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
>> proxy_util.c(2160): AH00943: HTTP: has released connection for (127.0.0.1)
>> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
>> proxy_util.c(2878): [remote 127.0.0.1:81] AH02642: proxy: connection
>> shutdown
>>
>>
>>
>> -----Original Message----- From: Jim Jagielski
>> Sent: Thursday, June 11, 2015 4:08 PM Newsgroups: gmane.comp.apache.devel
>> To: httpd
>> Subject: [VOTE] Release Apache httpd 2.4.14 as GA
>>
>> The pre-release test tarballs for Apache httpd 2.4.14 can be found
>> at the usual place:
>>
>> http://httpd.apache.org/dev/dist/
>>
>> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>>
>> [ ] +1: Good to go
>> [ ] +0: meh
>> [ ] -1: Danger Will Robinson. And why.
>>
>> Vote will last the normal 72 hrs.
>>
>> NOTE: The *-deps are only there for convenience.
>>
>> Thx!
>>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Steffen <in...@apachelounge.com>.
Debug 2.4.14 was already in my first post.
The 2.4.13 (no error) and 2.4.14 debug level error.log:
Apache/2.4.13 (Win32)
================
[Sat Jun 13 15:23:23.031198 2015] [authz_core:debug] [pid 9208:tid 1168] mod_authz_core.c(834): [client 127.0.0.1:54501] AH01628: authorization result: granted (no directives)
[Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168] mod_proxy.c(1157): [client 127.0.0.1:54501] AH01143: Running scheme http handler (attempt 0)
[Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168] proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
[Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168] proxy_util.c(2199): [client 127.0.0.1:54501] AH00944: connecting http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
[Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168] proxy_util.c(2408): [client 127.0.0.1:54501] AH00947: connected /sysadmin/ to 127.0.0.1:81
[Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168] proxy_util.c(2782): AH02824: HTTP: connection established with 127.0.0.1:81 (127.0.0.1)
[Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168] proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81 (127.0.0.1)
[Sat Jun 13 15:23:23.031198 2015] [proxy:debug] [pid 9208:tid 1168] proxy_util.c(2160): AH00943: http: has released connection for (127.0.0.1)
Apache/2.4.14 (Win32)
=================
[Sat Jun 13 15:20:54.616551 2015] [authz_core:debug] [pid 4676:tid 1152] mod_authz_core.c(834): [client 127.0.0.1:54430] AH01628: authorization result: granted (no directives)
[Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152] mod_proxy.c(1157): [client 127.0.0.1:54430] AH01143: Running scheme http handler (attempt 0)
[Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152] proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
[Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152] proxy_util.c(2199): [client 127.0.0.1:54430] AH00944: connecting http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
[Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152] proxy_util.c(2408): [client 127.0.0.1:54430] AH00947: connected /sysadmin/ to 127.0.0.1:81
[Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152] proxy_util.c(2782): AH02824: HTTP: connection established with 127.0.0.1:81 (127.0.0.1)
[Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152] proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81 (127.0.0.1)
[Sat Jun 13 15:20:54.616551 2015] [proxy_http:error] [pid 4676:tid 1152] (20014)Internal error (specific information not available): [client 127.0.0.1:54430] AH01110: error reading response
[Sat Jun 13 15:20:54.616551 2015] [proxy:debug] [pid 4676:tid 1152] proxy_util.c(2160): AH00943: HTTP: has released connection for (127.0.0.1)
From: Jeff Trawick
Sent: Saturday, June 13, 2015 3:14 PM
Newsgroups: gmane.comp.apache.devel
To: Apache HTTP Server Development List
Subject: Re: [VOTE] Release Apache httpd 2.4.14 as GA
On Sat, Jun 13, 2015 at 8:31 AM, Steffen <in...@apachelounge.com> wrote:
Tested with 2.4.13 tarball, then no error.
Wow...
Is anything written to the error log when you try proxy to the Sambar server? If my guess about the related code is correct, you'll need LogLevel Info (or debug or trace) to see all the relevant messages.
-----Original Message----- From: Steffen
Sent: Saturday, June 13, 2015 1:33 PM Newsgroups: gmane.comp.apache.devel
To: dev@httpd.apache.org
Subject: Re: [VOTE] Release Apache httpd 2.4.14 as GA
Regression: All works fine except a Proxy Pass to Sambar server, was
working ok with 2.4.12.
ProxyPasses to other servers the Sambar works fine.
ProxyPass /sysadmin http://127.0.0.1:81/sysadmin
ProxyPassReverse /sysadmin http://127.0.0.1:81/sysadmin
Calling with http://127.0.0.1:8080/sysadmin/ gives AH01110: error reading
response :
[Sat Jun 13 13:23:08.010826 2015] [authz_core:debug] [pid 5684:tid 1128]
mod_authz_core.c(834): [client ::1:51072] AH01628: authorization result:
granted (no directives)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
mod_proxy.c(1157): [client ::1:51072] AH01143: Running scheme http handler
(attempt 0)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2199): [client ::1:51072] AH00944: connecting
http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2408): [client ::1:51072] AH00947: connected /sysadmin/ to
127.0.0.1:81
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2782): AH02824: HTTP: connection established with 127.0.0.1:81
(127.0.0.1)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
(127.0.0.1)
[Sat Jun 13 13:23:08.010826 2015] [proxy_http:error] [pid 5684:tid 1128]
(20014)Internal error (specific information not available): [client
::1:51072] AH01110: error reading response
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2160): AH00943: HTTP: has released connection for (127.0.0.1)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2878): [remote 127.0.0.1:81] AH02642: proxy: connection
shutdown
-----Original Message----- From: Jim Jagielski
Sent: Thursday, June 11, 2015 4:08 PM Newsgroups: gmane.comp.apache.devel
To: httpd
Subject: [VOTE] Release Apache httpd 2.4.14 as GA
The pre-release test tarballs for Apache httpd 2.4.14 can be found
at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.
Vote will last the normal 72 hrs.
NOTE: The *-deps are only there for convenience.
Thx!
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Jun 13, 2015 at 8:31 AM, Steffen <in...@apachelounge.com> wrote:
> Tested with 2.4.13 tarball, then no error.
>
Wow...
Is anything written to the error log when you try proxy to the Sambar
server? If my guess about the related code is correct, you'll need
LogLevel Info (or debug or trace) to see all the relevant messages.
>
> -----Original Message----- From: Steffen
> Sent: Saturday, June 13, 2015 1:33 PM Newsgroups: gmane.comp.apache.devel
> To: dev@httpd.apache.org
> Subject: Re: [VOTE] Release Apache httpd 2.4.14 as GA
>
>
> Regression: All works fine except a Proxy Pass to Sambar server, was
> working ok with 2.4.12.
>
> ProxyPasses to other servers the Sambar works fine.
>
> ProxyPass /sysadmin http://127.0.0.1:81/sysadmin
> ProxyPassReverse /sysadmin http://127.0.0.1:81/sysadmin
>
> Calling with http://127.0.0.1:8080/sysadmin/ gives AH01110: error reading
> response :
>
> [Sat Jun 13 13:23:08.010826 2015] [authz_core:debug] [pid 5684:tid 1128]
> mod_authz_core.c(834): [client ::1:51072] AH01628: authorization result:
> granted (no directives)
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> mod_proxy.c(1157): [client ::1:51072] AH01143: Running scheme http handler
> (attempt 0)
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2199): [client ::1:51072] AH00944: connecting
> http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2408): [client ::1:51072] AH00947: connected /sysadmin/ to
> 127.0.0.1:81
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2782): AH02824: HTTP: connection established with
> 127.0.0.1:81
> (127.0.0.1)
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
> (127.0.0.1)
> [Sat Jun 13 13:23:08.010826 2015] [proxy_http:error] [pid 5684:tid 1128]
> (20014)Internal error (specific information not available): [client
> ::1:51072] AH01110: error reading response
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2160): AH00943: HTTP: has released connection for (127.0.0.1)
> [Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
> proxy_util.c(2878): [remote 127.0.0.1:81] AH02642: proxy: connection
> shutdown
>
>
>
> -----Original Message----- From: Jim Jagielski
> Sent: Thursday, June 11, 2015 4:08 PM Newsgroups: gmane.comp.apache.devel
> To: httpd
> Subject: [VOTE] Release Apache httpd 2.4.14 as GA
>
> The pre-release test tarballs for Apache httpd 2.4.14 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
>
> Vote will last the normal 72 hrs.
>
> NOTE: The *-deps are only there for convenience.
>
> Thx!
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Steffen <in...@apachelounge.com>.
Tested with 2.4.13 tarball, then no error.
-----Original Message-----
From: Steffen
Sent: Saturday, June 13, 2015 1:33 PM Newsgroups: gmane.comp.apache.devel
To: dev@httpd.apache.org
Subject: Re: [VOTE] Release Apache httpd 2.4.14 as GA
Regression: All works fine except a Proxy Pass to Sambar server, was
working ok with 2.4.12.
ProxyPasses to other servers the Sambar works fine.
ProxyPass /sysadmin http://127.0.0.1:81/sysadmin
ProxyPassReverse /sysadmin http://127.0.0.1:81/sysadmin
Calling with http://127.0.0.1:8080/sysadmin/ gives AH01110: error reading
response :
[Sat Jun 13 13:23:08.010826 2015] [authz_core:debug] [pid 5684:tid 1128]
mod_authz_core.c(834): [client ::1:51072] AH01628: authorization result:
granted (no directives)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
mod_proxy.c(1157): [client ::1:51072] AH01143: Running scheme http handler
(attempt 0)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2199): [client ::1:51072] AH00944: connecting
http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2408): [client ::1:51072] AH00947: connected /sysadmin/ to
127.0.0.1:81
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2782): AH02824: HTTP: connection established with 127.0.0.1:81
(127.0.0.1)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
(127.0.0.1)
[Sat Jun 13 13:23:08.010826 2015] [proxy_http:error] [pid 5684:tid 1128]
(20014)Internal error (specific information not available): [client
::1:51072] AH01110: error reading response
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2160): AH00943: HTTP: has released connection for (127.0.0.1)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2878): [remote 127.0.0.1:81] AH02642: proxy: connection
shutdown
-----Original Message-----
From: Jim Jagielski
Sent: Thursday, June 11, 2015 4:08 PM Newsgroups: gmane.comp.apache.devel
To: httpd
Subject: [VOTE] Release Apache httpd 2.4.14 as GA
The pre-release test tarballs for Apache httpd 2.4.14 can be found
at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.
Vote will last the normal 72 hrs.
NOTE: The *-deps are only there for convenience.
Thx!
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Steffen <in...@apachelounge.com>.
Regression: All works fine except a Proxy Pass to Sambar server, was
working ok with 2.4.12.
ProxyPasses to other servers the Sambar works fine.
ProxyPass /sysadmin http://127.0.0.1:81/sysadmin
ProxyPassReverse /sysadmin http://127.0.0.1:81/sysadmin
Calling with http://127.0.0.1:8080/sysadmin/ gives AH01110: error reading
response :
[Sat Jun 13 13:23:08.010826 2015] [authz_core:debug] [pid 5684:tid 1128]
mod_authz_core.c(834): [client ::1:51072] AH01628: authorization result:
granted (no directives)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
mod_proxy.c(1157): [client ::1:51072] AH01143: Running scheme http handler
(attempt 0)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2145): AH00942: HTTP: has acquired connection for (127.0.0.1)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2199): [client ::1:51072] AH00944: connecting
http://127.0.0.1:81/sysadmin/ to 127.0.0.1:81
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2408): [client ::1:51072] AH00947: connected /sysadmin/ to
127.0.0.1:81
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2782): AH02824: HTTP: connection established with 127.0.0.1:81
(127.0.0.1)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2936): AH00962: HTTP: connection complete to 127.0.0.1:81
(127.0.0.1)
[Sat Jun 13 13:23:08.010826 2015] [proxy_http:error] [pid 5684:tid 1128]
(20014)Internal error (specific information not available): [client
::1:51072] AH01110: error reading response
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2160): AH00943: HTTP: has released connection for (127.0.0.1)
[Sat Jun 13 13:23:08.010826 2015] [proxy:debug] [pid 5684:tid 1128]
proxy_util.c(2878): [remote 127.0.0.1:81] AH02642: proxy: connection
shutdown
-----Original Message-----
From: Jim Jagielski
Sent: Thursday, June 11, 2015 4:08 PM Newsgroups: gmane.comp.apache.devel
To: httpd
Subject: [VOTE] Release Apache httpd 2.4.14 as GA
The pre-release test tarballs for Apache httpd 2.4.14 can be found
at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.
Vote will last the normal 72 hrs.
NOTE: The *-deps are only there for convenience.
Thx!
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jun 14, 2015, at 8:37 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Jun 14, 2015 12:45 PM, "Jim Jagielski" <ji...@jagunet.com> wrote:
> >
> > I am canceling this vote... The breakage due to the chunked
> > stuff is the reason.
> >
> > THIS is the reason I don't like "last-minute" changes that
> > (1) touch a LOT of code or a major code path and (2) has an
> > extremely limited QA history. We should also patch the test
> > framework to test for this.
>
> This is the reason I dont like security patches, but they are a fact of life. Sadly this one would not have been discovered without the breadth of interop testing that a release vote entails.
>
Oh agreed. But for a low-severity vuln, this is kinda embarrassing.
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Jun 14, 2015 12:45 PM, "Jim Jagielski" <ji...@jagunet.com> wrote:
>
> I am canceling this vote... The breakage due to the chunked
> stuff is the reason.
>
> THIS is the reason I don't like "last-minute" changes that
> (1) touch a LOT of code or a major code path and (2) has an
> extremely limited QA history. We should also patch the test
> framework to test for this.
This is the reason I dont like security patches, but they are a fact of
life. Sadly this one would not have been discovered without the breadth of
interop testing that a release vote entails.
Mad props to Steffan for identifying this bug, outstanding! Thank you.
> Let's patch this and I will T&R 2.4.15 this week.
+1. More interop testing in the meantime is most welcomed.
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Yann Ylavic <yl...@gmail.com>.
On Sun, Jun 14, 2015 at 10:08 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Sun, Jun 14, 2015 at 7:43 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> We should also patch the test
>> framework to test for this.
>
> It seems that I can't commit on ^/httpd/test/framework, test patch attached...
Applied in r1685463 (with more chunk-size tests).
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Yann Ylavic <yl...@gmail.com>.
On Sun, Jun 14, 2015 at 7:43 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> We should also patch the test
> framework to test for this.
It seems that I can't commit on ^/httpd/test/framework, test patch attached...
Re: [VOTE] Release Apache httpd 2.4.14 as GA
Posted by Jim Jagielski <ji...@jaguNET.com>.
I am canceling this vote... The breakage due to the chunked
stuff is the reason.
THIS is the reason I don't like "last-minute" changes that
(1) touch a LOT of code or a major code path and (2) has an
extremely limited QA history. We should also patch the test
framework to test for this.
Let's patch this and I will T&R 2.4.15 this week.
> On Jun 11, 2015, at 10:08 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> The pre-release test tarballs for Apache httpd 2.4.14 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'm calling a VOTE on releasing these as Apache httpd 2.4.14 GA.
>
> [ ] +1: Good to go
> [ ] +0: meh
> [ ] -1: Danger Will Robinson. And why.
>
> Vote will last the normal 72 hrs.
>
> NOTE: The *-deps are only there for convenience.
>
> Thx!