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 2013/11/12 17:48:16 UTC
NOTE: Intent to T&R 2.2.6 tomorrow
I intend to T&R 2.2.26 tomorrow... post now if that's
an issue or problem...
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Tue, 12 Nov 2013 14:30:17 -0500
Jim Jagielski <ji...@jaguNET.com> wrote:
> I think http://svn.apache.org/viewvc?view=revision&revision=1527925
> is also needed...
Howso? APLOGNO() is specific to 2.4 and later.
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by Jim Jagielski <ji...@jaguNET.com>.
I think http://svn.apache.org/viewvc?view=revision&revision=1527925
is also needed...
On Nov 12, 2013, at 2:25 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> The only thing I worry about is that the below
> patches aren't even in 2.4 yet, although maybe they
> should be in the release-after-next.
>
> Oh yeah... I recall you had an issue with me building
> because of potential issues with using a later, but
> still 100% valid autoconf/libtool setup. I am not
> going to downgrade just to build 2.2 so if that is
> *really* a concern, backed-up by the PMC, then someone
> else will need to RM.
>
> On Nov 12, 2013, at 12:56 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>
>> On Tue, 12 Nov 2013 11:48:16 -0500
>> Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>>> I intend to T&R 2.2.26 tomorrow... post now if that's
>>> an issue or problem...
>>
>> As I mentioned earlier, two additional patches should possibly be
>> considered for protocol correctness. The first you shepherded into
>> trunk, so I'm particularly interested in your thoughts on backporting
>> this, Jim...
>>
>> http://svn.apache.org/viewvc?view=revision&revision=1524192
>> http://svn.apache.org/viewvc?view=revision&revision=1524770
>> (Note that the commit log message is missing patch attribution)
>>
>> A backport is attached, as best as I've figured from the trunk-modulo-
>> 2.2 code path.
>>
>> The second is the 100-continue behavior, when proxy-interim-response is
>> set to RFC. As Yann noted in a very long and winding message thread,
>> the core http filter is pushing a 100 continue interim status, and then
>> mod_proxy_http is pushing back yet another interim status response. The
>> core status response must be suppressed on proxy-interim-response RFC
>> requests.
>>
>> It's not clear where that discussion thread has ended up, or whether
>> there is a usable patch to enforce this behavior. As you had the most
>> to contribute to that thread, can you give us your thoughts on its
>> current status, Jim?
>>
>> And thanks for offering to RM - please remember not to leapfrog the
>> versions of autoconf/libtool, lest we potentially break configure
>> behavior on the more obscure platforms, and trigger incompatibilities
>> in configure.in which only occur on newer versions of autoconf.
>>
>> Libtool 1.5.26 and autoconf 2.67 were used for 2.2.25 release; any later
>> 1.5 libtool or 2.6x series autoconf aught to work but you would want to
>> pre- buildconf and review any newer versions before tagging.
>>
>> I'm happy to RM with that same toolchain as I offered in the first place,
>> if that environment poses a headache for you. Only the two questions
>> above seemed relevant to me before moving on with this tag.
>>
>> Cheers,
>>
>> Bill
>>
>>
>>
>>
>>
>>
>> <httpd-2.2-r1524192-r1524770-TE-CL.patch>
>
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by Jim Jagielski <ji...@jaguNET.com>.
This will happen noon eastern.
On Nov 12, 2013, at 4:22 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> I'll build w/ 2.67 and 1.5.26 for consistency.
>
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by Jim Jagielski <ji...@jaguNET.com>.
I'll build w/ 2.67 and 1.5.26 for consistency.
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Nov 12, 2013 at 4:00 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> So what versions of autoconf and libtool should we
> be baselining for 2.2.x?
>
autoconf: 2.2.24 and 2.2.25 used autoconf 2.67
libtool: I guess I don't know how to check that. Does it simply use the
apr libtool and have no need itself? (That wouldn't make sense for pcre
AFAIK.)
>
> On Nov 12, 2013, at 3:33 PM, Jeff Trawick <tr...@gmail.com> wrote:
>
> > On Tue, Nov 12, 2013 at 3:22 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> >
> > On Nov 12, 2013, at 2:39 PM, Ben Reser <be...@reser.org> wrote:
> >
> > > On Tue Nov 12 11:25:57 2013, Jim Jagielski wrote:
> > >> Oh yeah... I recall you had an issue with me building
> > >> because of potential issues with using a later, but
> > >> still 100% valid autoconf/libtool setup. I am not
> > >> going to downgrade just to build 2.2 so if that is
> > >> *really* a concern, backed-up by the PMC, then someone
> > >> else will need to RM.
> > >
> > > You don't need to downgrade at all. Just build autoconf/libtool
> > > versions and install them in another dir. Add that to the front of
> > > your path and off you go.
> >
> > Ugg. :)
> >
> > My reason to not downgrade isn't because of having
> > different versions but because ALL my testing and building
> > on my various machine is with the newer set. So all my
> > confidence on my voting is based on that toolset. Down-
> > grading throws an unknown factor into my process which
> > reduces my "trust" which was based on using a different
> > toolset.
> >
> > My 2 cents: Developers test the build on a wide variety of autotools
> anyway. Looking at all the differences from one release tarball to the
> next is useful, but if autotools versions are jumping around then the bits
> generated from .m4/.in changes are somewhere inside an unreviewable mess.
> If users didn't report an autotools-based problem before, they presumably
> won't now if the same versions are used. (But 2 cents doesn't buy much,
> and I don't want to add any heat here.)
> >
> > --
> > Born in Roswell... married an alien...
> > http://emptyhammock.com/
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by Jim Jagielski <ji...@jaguNET.com>.
I'm assuming:
libtool: 1.5.26
autoconf: 2.61
On Nov 12, 2013, at 4:00 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> So what versions of autoconf and libtool should we
> be baselining for 2.2.x?
>
> On Nov 12, 2013, at 3:33 PM, Jeff Trawick <tr...@gmail.com> wrote:
>
>> On Tue, Nov 12, 2013 at 3:22 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>
>> On Nov 12, 2013, at 2:39 PM, Ben Reser <be...@reser.org> wrote:
>>
>>> On Tue Nov 12 11:25:57 2013, Jim Jagielski wrote:
>>>> Oh yeah... I recall you had an issue with me building
>>>> because of potential issues with using a later, but
>>>> still 100% valid autoconf/libtool setup. I am not
>>>> going to downgrade just to build 2.2 so if that is
>>>> *really* a concern, backed-up by the PMC, then someone
>>>> else will need to RM.
>>>
>>> You don't need to downgrade at all. Just build autoconf/libtool
>>> versions and install them in another dir. Add that to the front of
>>> your path and off you go.
>>
>> Ugg. :)
>>
>> My reason to not downgrade isn't because of having
>> different versions but because ALL my testing and building
>> on my various machine is with the newer set. So all my
>> confidence on my voting is based on that toolset. Down-
>> grading throws an unknown factor into my process which
>> reduces my "trust" which was based on using a different
>> toolset.
>>
>> My 2 cents: Developers test the build on a wide variety of autotools anyway. Looking at all the differences from one release tarball to the next is useful, but if autotools versions are jumping around then the bits generated from .m4/.in changes are somewhere inside an unreviewable mess. If users didn't report an autotools-based problem before, they presumably won't now if the same versions are used. (But 2 cents doesn't buy much, and I don't want to add any heat here.)
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Tue, 12 Nov 2013 16:00:52 -0500
Jim Jagielski <ji...@jaguNET.com> wrote:
> So what versions of autoconf and libtool should we
> be baselining for 2.2.x?
On Tue, 12 Nov 2013 11:56:39 -0600
"William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> Libtool 1.5.26 and autoconf 2.67 were used for 2.2.25 release; any
> later 1.5 libtool or 2.6x series autoconf aught to work but you would
> want to pre- buildconf and review any newer versions before tagging.
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by Jim Jagielski <ji...@jaguNET.com>.
So what versions of autoconf and libtool should we
be baselining for 2.2.x?
On Nov 12, 2013, at 3:33 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Tue, Nov 12, 2013 at 3:22 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Nov 12, 2013, at 2:39 PM, Ben Reser <be...@reser.org> wrote:
>
> > On Tue Nov 12 11:25:57 2013, Jim Jagielski wrote:
> >> Oh yeah... I recall you had an issue with me building
> >> because of potential issues with using a later, but
> >> still 100% valid autoconf/libtool setup. I am not
> >> going to downgrade just to build 2.2 so if that is
> >> *really* a concern, backed-up by the PMC, then someone
> >> else will need to RM.
> >
> > You don't need to downgrade at all. Just build autoconf/libtool
> > versions and install them in another dir. Add that to the front of
> > your path and off you go.
>
> Ugg. :)
>
> My reason to not downgrade isn't because of having
> different versions but because ALL my testing and building
> on my various machine is with the newer set. So all my
> confidence on my voting is based on that toolset. Down-
> grading throws an unknown factor into my process which
> reduces my "trust" which was based on using a different
> toolset.
>
> My 2 cents: Developers test the build on a wide variety of autotools anyway. Looking at all the differences from one release tarball to the next is useful, but if autotools versions are jumping around then the bits generated from .m4/.in changes are somewhere inside an unreviewable mess. If users didn't report an autotools-based problem before, they presumably won't now if the same versions are used. (But 2 cents doesn't buy much, and I don't want to add any heat here.)
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Nov 12, 2013 at 3:22 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Nov 12, 2013, at 2:39 PM, Ben Reser <be...@reser.org> wrote:
>
> > On Tue Nov 12 11:25:57 2013, Jim Jagielski wrote:
> >> Oh yeah... I recall you had an issue with me building
> >> because of potential issues with using a later, but
> >> still 100% valid autoconf/libtool setup. I am not
> >> going to downgrade just to build 2.2 so if that is
> >> *really* a concern, backed-up by the PMC, then someone
> >> else will need to RM.
> >
> > You don't need to downgrade at all. Just build autoconf/libtool
> > versions and install them in another dir. Add that to the front of
> > your path and off you go.
>
> Ugg. :)
>
> My reason to not downgrade isn't because of having
> different versions but because ALL my testing and building
> on my various machine is with the newer set. So all my
> confidence on my voting is based on that toolset. Down-
> grading throws an unknown factor into my process which
> reduces my "trust" which was based on using a different
> toolset.
>
My 2 cents: Developers test the build on a wide variety of autotools
anyway. Looking at all the differences from one release tarball to the
next is useful, but if autotools versions are jumping around then the bits
generated from .m4/.in changes are somewhere inside an unreviewable mess.
If users didn't report an autotools-based problem before, they presumably
won't now if the same versions are used. (But 2 cents doesn't buy much,
and I don't want to add any heat here.)
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 12, 2013, at 2:39 PM, Ben Reser <be...@reser.org> wrote:
> On Tue Nov 12 11:25:57 2013, Jim Jagielski wrote:
>> Oh yeah... I recall you had an issue with me building
>> because of potential issues with using a later, but
>> still 100% valid autoconf/libtool setup. I am not
>> going to downgrade just to build 2.2 so if that is
>> *really* a concern, backed-up by the PMC, then someone
>> else will need to RM.
>
> You don't need to downgrade at all. Just build autoconf/libtool
> versions and install them in another dir. Add that to the front of
> your path and off you go.
Ugg. :)
My reason to not downgrade isn't because of having
different versions but because ALL my testing and building
on my various machine is with the newer set. So all my
confidence on my voting is based on that toolset. Down-
grading throws an unknown factor into my process which
reduces my "trust" which was based on using a different
toolset.
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by Ben Reser <be...@reser.org>.
On Tue Nov 12 11:25:57 2013, Jim Jagielski wrote:
> Oh yeah... I recall you had an issue with me building
> because of potential issues with using a later, but
> still 100% valid autoconf/libtool setup. I am not
> going to downgrade just to build 2.2 so if that is
> *really* a concern, backed-up by the PMC, then someone
> else will need to RM.
You don't need to downgrade at all. Just build autoconf/libtool
versions and install them in another dir. Add that to the front of
your path and off you go. Subversion includes the ability to download
and build the autoconf/libtool versions we use as part of our build-env
command to release.py which ensures we have consistent versions no
matter who does the release. Maybe we should look at doing something
like this:
https://subversion.apache.org/docs/community-guide/releasing.html#before-release
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Tue, 12 Nov 2013 14:25:57 -0500
Jim Jagielski <ji...@jaguNET.com> wrote:
> Oh yeah... I recall you had an issue with me building
> because of potential issues with using a later, but
> still 100% valid autoconf/libtool setup. I am not
> going to downgrade just to build 2.2 so if that is
> *really* a concern, backed-up by the PMC, then someone
> else will need to RM.
I'll defer to the list. Unlike several recent releases, I don't believe
this one will be a security release, so any change in behavior won't be
as troublesome as an 'update now!' vulnerabilities fix release.
It seems we have picked up the autoconf fixes (looking at the toolchain
of FC19), so my concerns are somewhat lessened. My own opinion is -0
for jumping from libtool 1.5.x to 2.x for the legacy 2.2.x branch, but
I don't feel strongly enough either way to cast a more explicit vote.
There's always the option for the user to re-buildconf if they do find
some issues or regressions.
$ ./buildconf
found apr source: srclib/apr
found apr-util source: srclib/apr-util
rebuilding srclib/apr/configure
buildconf: checking installation...
buildconf: python version 2.7.5 (ok)
buildconf: autoconf version 2.69 (ok)
buildconf: libtool version 2.4.2 (ok)
buildconf: copying libtool helper files using /usr/bin/libtoolize
buildconf: creating include/arch/unix/apr_private.h.in ...
buildconf: creating configure ...
buildconf: generating 'make' outputs ...
buildconf: rebuilding rpm spec file
rebuilding srclib/apr-util/configure
Looking for apr source in /home/wrowe/dev/httpd-2.2/srclib/apr
Creating include/private/apu_config.h ...
Creating configure ...
Generating 'make' outputs ...
Invoking xml/expat/buildconf.sh ...
Copying libtool helper files using /usr/bin/libtoolize
Creating config.h.in ...
Creating configure ...
rebuilding rpm spec file
copying build files
rebuilding srclib/pcre/configure
rebuilding include/ap_config_auto.h.in
rebuilding configure
rebuilding rpm spec file
fixing timestamps for mod_ssl sources
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by Jim Jagielski <ji...@jaguNET.com>.
The only thing I worry about is that the below
patches aren't even in 2.4 yet, although maybe they
should be in the release-after-next.
Oh yeah... I recall you had an issue with me building
because of potential issues with using a later, but
still 100% valid autoconf/libtool setup. I am not
going to downgrade just to build 2.2 so if that is
*really* a concern, backed-up by the PMC, then someone
else will need to RM.
On Nov 12, 2013, at 12:56 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On Tue, 12 Nov 2013 11:48:16 -0500
> Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> I intend to T&R 2.2.26 tomorrow... post now if that's
>> an issue or problem...
>
> As I mentioned earlier, two additional patches should possibly be
> considered for protocol correctness. The first you shepherded into
> trunk, so I'm particularly interested in your thoughts on backporting
> this, Jim...
>
> http://svn.apache.org/viewvc?view=revision&revision=1524192
> http://svn.apache.org/viewvc?view=revision&revision=1524770
> (Note that the commit log message is missing patch attribution)
>
> A backport is attached, as best as I've figured from the trunk-modulo-
> 2.2 code path.
>
> The second is the 100-continue behavior, when proxy-interim-response is
> set to RFC. As Yann noted in a very long and winding message thread,
> the core http filter is pushing a 100 continue interim status, and then
> mod_proxy_http is pushing back yet another interim status response. The
> core status response must be suppressed on proxy-interim-response RFC
> requests.
>
> It's not clear where that discussion thread has ended up, or whether
> there is a usable patch to enforce this behavior. As you had the most
> to contribute to that thread, can you give us your thoughts on its
> current status, Jim?
>
> And thanks for offering to RM - please remember not to leapfrog the
> versions of autoconf/libtool, lest we potentially break configure
> behavior on the more obscure platforms, and trigger incompatibilities
> in configure.in which only occur on newer versions of autoconf.
>
> Libtool 1.5.26 and autoconf 2.67 were used for 2.2.25 release; any later
> 1.5 libtool or 2.6x series autoconf aught to work but you would want to
> pre- buildconf and review any newer versions before tagging.
>
> I'm happy to RM with that same toolchain as I offered in the first place,
> if that environment poses a headache for you. Only the two questions
> above seemed relevant to me before moving on with this tag.
>
> Cheers,
>
> Bill
>
>
>
>
>
>
> <httpd-2.2-r1524192-r1524770-TE-CL.patch>
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by Jim Jagielski <ji...@jaguNET.com>.
I "just" added it to the backport proposal for
2.4... If there is sufficient support for adding
in 2.2 then I guess there will be enough for 2.4.
Go ahead and add to STATUS and we'll see...
On Nov 12, 2013, at 3:55 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On Tue, 12 Nov 2013 11:56:39 -0600
> "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>>
>> On Tue, 12 Nov 2013 11:48:16 -0500
>> Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>>> I intend to T&R 2.2.26 tomorrow... post now if that's
>>> an issue or problem...
>>
>> As I mentioned earlier, two additional patches should possibly be
>> considered for protocol correctness. The first you shepherded into
>> trunk, so I'm particularly interested in your thoughts on backporting
>> this, Jim...
>>
>> http://svn.apache.org/viewvc?view=revision&revision=1524192
>> http://svn.apache.org/viewvc?view=revision&revision=1524770
>> (Note that the commit log message is missing patch attribution)
>>
>> A backport is attached, as best as I've figured from the trunk-modulo-
>> 2.2 code path.
>>
>> The second is the 100-continue behavior, when proxy-interim-response
>> is set to RFC. As Yann noted in a very long and winding message
>> thread, the core http filter is pushing a 100 continue interim
>> status, and then mod_proxy_http is pushing back yet another interim
>> status response. The core status response must be suppressed on
>> proxy-interim-response RFC requests.
>>
>> It's not clear where that discussion thread has ended up, or whether
>> there is a usable patch to enforce this behavior. As you had the most
>> to contribute to that thread, can you give us your thoughts on its
>> current status, Jim?
>
> Let's let the question of adopting either or both of these changes
> expire at the end of the day. If there is no strong support for
> picking up either or both of these in 2.4.7, they can be pended for
> some later release.
>
> Committers - your thoughts?<httpd-2.2-r1524192-r1524770-TE-CL.patch>
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Tue, 12 Nov 2013 11:56:39 -0600
"William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
>
> On Tue, 12 Nov 2013 11:48:16 -0500
> Jim Jagielski <ji...@jaguNET.com> wrote:
>
> > I intend to T&R 2.2.26 tomorrow... post now if that's
> > an issue or problem...
>
> As I mentioned earlier, two additional patches should possibly be
> considered for protocol correctness. The first you shepherded into
> trunk, so I'm particularly interested in your thoughts on backporting
> this, Jim...
>
> http://svn.apache.org/viewvc?view=revision&revision=1524192
> http://svn.apache.org/viewvc?view=revision&revision=1524770
> (Note that the commit log message is missing patch attribution)
>
> A backport is attached, as best as I've figured from the trunk-modulo-
> 2.2 code path.
>
> The second is the 100-continue behavior, when proxy-interim-response
> is set to RFC. As Yann noted in a very long and winding message
> thread, the core http filter is pushing a 100 continue interim
> status, and then mod_proxy_http is pushing back yet another interim
> status response. The core status response must be suppressed on
> proxy-interim-response RFC requests.
>
> It's not clear where that discussion thread has ended up, or whether
> there is a usable patch to enforce this behavior. As you had the most
> to contribute to that thread, can you give us your thoughts on its
> current status, Jim?
Let's let the question of adopting either or both of these changes
expire at the end of the day. If there is no strong support for
picking up either or both of these in 2.4.7, they can be pended for
some later release.
Committers - your thoughts?
mod_proxy ping and 100-continue (was Re: NOTE: Intent to T&R 2.2.6
tomorrow)
Posted by Yann Ylavic <yl...@gmail.com>.
I peek this message from another thread and create a new one, since
details may not be relevant in the T&R note.
On 11/12/2013 06:56 PM, William A. Rowe Jr. wrote:
> On Tue, 12 Nov 2013 11:48:16 -0500
> Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> I intend to T&R 2.2.26 tomorrow... post now if that's
>> an issue or problem...
> As I mentioned earlier, two additional patches should possibly be
> considered for protocol correctness. The first you shepherded into
> trunk, so I'm particularly interested in your thoughts on backporting
> this, Jim...
>
> http://svn.apache.org/viewvc?view=revision&revision=1524192
> http://svn.apache.org/viewvc?view=revision&revision=1524770
> (Note that the commit log message is missing patch attribution)
>
> A backport is attached, as best as I've figured from the trunk-modulo-
> 2.2 code path.
>
> The second is the 100-continue behavior, when proxy-interim-response is
> set to RFC. As Yann noted in a very long and winding message thread,
> the core http filter is pushing a 100 continue interim status, and then
> mod_proxy_http is pushing back yet another interim status response. The
> core status response must be suppressed on proxy-interim-response RFC
> requests.
>
> It's not clear where that discussion thread has ended up, or whether
> there is a usable patch to enforce this behavior. As you had the most
> to contribute to that thread, can you give us your thoughts on its
> current status, Jim?
Actually the issue I described does not depend on the
proxy-interim-response value: when a (positive) ping is configured for
the worker, mod_proxy_http (via ap_proxy_create_hdrbrgd) will set
r->expecting_100 which will cause the http input filter to push a "100
Continue" to the client, before anything is forwarded (when the request
body is prefetched), whether or not the client expects one (eg. "Expect:
100-continue" or not).
But I agree that the proxy-interim-response == "RFC" is an issue too,
per se.
In fact I don't really see why any "100 Continue" response from the
backend should be forwarded to the client, since the client has already
received one during prefetch (from the http input filter, if expected).
When the (interim) response is about to be forwarded, the request has
already been read (fully), hence the client has nothing more to continue...
Forcing another "100 Continue" here (when proxy-interim-response ==
"RFC") is at least useless (it will be ignored), at worst not rfc
compliant (can a receiver send multiple "100 Continue"? when it has
everything already?).
IMHO, the root issue is that mod_proxy_http cannot be an expectation
proxy with its current implementation (forward all the request, then
forward all the response). It acts more as a server for the client and a
client for the backend, and hence should follow the related RFC parts
(not the ones for an expectation proxy, which I guess is what is
intended by the proxy-interim-response == "RFC").
So the 100-continue with the client should be a client<->proxy only
stuff (controlled by r->expecting_100), and the one with the backend
another proxy<->backend only stuff (with the interim responses being
eaten by the proxy), both should be handled separately.
Below is the patch for ap_proxy_create_hdrbrgd (attached too), but I
think a separate client<->proxy and proxy<->backend handling would be
better, I can try to propose it if you agree.
Regards,
Yann.
Index: modules/proxy/proxy_util.c
===================================================================
--- modules/proxy/proxy_util.c (revision 1541907)
+++ modules/proxy/proxy_util.c (working copy)
@@ -3126,7 +3126,7 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbrgd(apr_poo
apr_bucket *e;
int do_100_continue;
conn_rec *origin = p_conn->connection;
- const char *fpr1;
+ const char *fpr1, *expect;
proxy_dir_conf *dconf = ap_get_module_config(r->per_dir_config,
&proxy_module);
/*
@@ -3227,13 +3227,37 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbrgd(apr_poo
);
}
- /* Use HTTP/1.1 100-Continue as quick "HTTP ping" test
- * to backend
+ /* Use HTTP/1.1 100-Continue as quick "HTTP ping" test to backend.
+ * If a ping test was already tried with the same request, restore
+ * the original Expect header to avoid using the modified one with
+ * subsequent requests (the new backend may not be ping-able).
*/
+ expect = apr_table_get(r->notes, "proxy-ping-expect");
+ if (expect == NULL) {
+ expect = apr_table_get(r->headers_in, "Expect");
+ if (expect != NULL) {
+ apr_table_setn(r->notes, "proxy-ping-expect", expect);
+ }
+ else {
+ apr_table_setn(r->notes, "proxy-ping-expect", "\n");
+ }
+ }
+ else if (strcmp(expect, "\n") != 0) {
+ apr_table_setn(r->headers_in, "Expect", expect);
+ }
+ else {
+ apr_table_unset(r->headers_in, "Expect");
+ expect = NULL;
+ }
if (do_100_continue) {
- apr_table_mergen(r->headers_in, "Expect", "100-Continue");
- r->expecting_100 = 1;
+ if (!ap_find_token(r->pool, expect, "100-Continue")) {
+ apr_table_mergen(r->headers_in, "Expect", "100-Continue");
+ }
+ apr_table_setn(r->notes, "proxy-ping-100-continue", "1");
}
+ else {
+ apr_table_unset(r->notes, "proxy-ping-100-continue");
+ }
/* X-Forwarded-*: handling
*
Index: modules/proxy/mod_proxy_http.c
===================================================================
--- modules/proxy/mod_proxy_http.c (revision 1541907)
+++ modules/proxy/mod_proxy_http.c (working copy)
@@ -1537,10 +1537,12 @@ int ap_proxy_http_process_response(apr_pool_t * p,
* We need to set "r->expecting_100 = 1" otherwise origin
* server behaviour will apply.
*/
+ ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r,
+ "HTTP: received interim %d response", r->status);
+ if ((r->status != HTTP_CONTINUE) ||
+ !apr_table_get(r->notes, "proxy-ping-100-continue")) {
const char *policy = apr_table_get(r->subprocess_env,
"proxy-interim-response");
- ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r,
- "HTTP: received interim %d response", r->status);
if (!policy
|| (!strcasecmp(policy, "RFC") &&
((r->expecting_100 = 1)))) {
ap_send_interim_response(r, 1);
@@ -1552,6 +1554,7 @@ int ap_proxy_http_process_response(apr_pool_t * p,
ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r,
APLOGNO(01108)
"undefined proxy interim response policy");
}
+ }
}
/* Moved the fixups of Date headers and those affected by
* ProxyPassReverse/etc from here to ap_proxy_read_headers
[EOS]
Re: mod_proxy ping and 100-continue (was Re: NOTE: Intent to T&R
2.2.6 tomorrow)
Posted by "William A. Rowe Jr." <wm...@gmail.com>.
This is a once-per-request query, so a note shouldn't be a bad thing.
But I'm wondering if we need a multi-state (and eventually, fold that
into 2.6/3.0 req_req instead)?
Many users have requested that mod_proxy honor -configured- proxypass
backends' 100 responses and defer the 100 response to the client until
the backend is known to be alive.
For lots of reasons, this shouldn't be the default behavior, notably
the lag between the proxy and backend servers. But for an integrated
app hosting environment, the lag should be minimal and the stress on
httpd of reading-to-discard large post/upload sorts of requests when
auth is required or some other fatal error is encountered would be
worthwhile.
So we have the typical httpd-originated 100-continue vs. a
backend-originated 100-continue, and I'm not sure how the delta
between current-default and rfc behavior might factor into a third
mode.
On Fri, Apr 4, 2014 at 5:19 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Fri, Apr 4, 2014 at 7:52 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> Is there any way to accomplish w/o using notes? It's not that
>> they are especially slow, it's just that they aren't that fast
>> and, iirc, this could be a tight path.
>
> There surely is, but we can't use the proxy_conn_rec for this (it may
> change between calls for the load-balancing case).
> We could define ap_proxy_create_hdrbrgd_ex() which takes the saved
> "proxy-interim-response" env as argument (looked up once by the
> caller), or add a new request_rec field (...), but I think it's a bit
> (at least) overkill for a path where, anyway, expecting (and probably
> waiting for) a 100-continue will take much more time than a few
> apr_table ops.
>
> The simpler solution, IMHO, is to simply never forward 100-continue
> responses, the client has already got one when this happens.
> I don't really understand the purpose of "proxy-interim-response" ==
> "RFC" anyhow ("suppress" should be the only behaviour), I even think
> it is not RFC compliant (at least useless) to send multiple
> 100-continue...
>
> As said earlier, by pre-fetching the request body, mod_proxy can't be
> an expectation proxy: it should comply to the client part of the RFC
> wrt to the origin (which is the case), and to the server part of the
> RFC wrt the client (which "proxy-interim-response" breaks).
Re: mod_proxy ping and 100-continue (was Re: NOTE: Intent to T&R
2.2.6 tomorrow)
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Apr 4, 2014 at 7:52 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> Is there any way to accomplish w/o using notes? It's not that
> they are especially slow, it's just that they aren't that fast
> and, iirc, this could be a tight path.
There surely is, but we can't use the proxy_conn_rec for this (it may
change between calls for the load-balancing case).
We could define ap_proxy_create_hdrbrgd_ex() which takes the saved
"proxy-interim-response" env as argument (looked up once by the
caller), or add a new request_rec field (...), but I think it's a bit
(at least) overkill for a path where, anyway, expecting (and probably
waiting for) a 100-continue will take much more time than a few
apr_table ops.
The simpler solution, IMHO, is to simply never forward 100-continue
responses, the client has already got one when this happens.
I don't really understand the purpose of "proxy-interim-response" ==
"RFC" anyhow ("suppress" should be the only behaviour), I even think
it is not RFC compliant (at least useless) to send multiple
100-continue...
As said earlier, by pre-fetching the request body, mod_proxy can't be
an expectation proxy: it should comply to the client part of the RFC
wrt to the origin (which is the case), and to the server part of the
RFC wrt the client (which "proxy-interim-response" breaks).
Re: mod_proxy ping and 100-continue (was Re: NOTE: Intent to T&R
2.2.6 tomorrow)
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Apr 4, 2014 at 7:52 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> Is there any way to accomplish w/o using notes? It's not that
> they are especially slow, it's just that they aren't that fast
> and, iirc, this could be a tight path.
>
Simpler solution commited in r1588519.
We don't have to care about reentrance since r->expecting_100 will
never be 1 in this case.
Re: mod_proxy ping and 100-continue (was Re: NOTE: Intent to T&R 2.2.6 tomorrow)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Is there any way to accomplish w/o using notes? It's not that
they are especially slow, it's just that they aren't that fast
and, iirc, this could be a tight path.
On Apr 4, 2014, at 1:02 PM, Yann Ylavic <yl...@gmail.com> wrote:
> Hi,
>
> this is the day of resurrections :p
>
> I think I've got a simpler way to address this issue, that is, don't
> send unexpected 100-continue to clients due to proxy ping feature.
>
> Here is the patch.
> Once again, please object if you don't want me to commit this stuff.
>
> Reagrds,
> Yann.
>
> Index: modules/proxy/proxy_util.c
> ===================================================================
> --- modules/proxy/proxy_util.c (revision 1584652)
> +++ modules/proxy/proxy_util.c (working copy)
> @@ -3312,8 +3312,43 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbrgd(apr_poo
> * to backend
> */
> if (do_100_continue) {
> - apr_table_mergen(r->headers_in, "Expect", "100-Continue");
> - r->expecting_100 = 1;
> + const char *val;
> +
> + /* Since we may modify the original "proxy-interim-response" env but
> + * also come back here later with the same request (previous ping
> + * failure, load balancing recoverable error...), we use "\n" as the
> + * saved value when the original one is not defined, so that we can do
> + * the right thing (unset) to restore the env (later) in this case.
> + */
> + val = apr_table_get(r->notes, "proxy-interim-pong");
> + if (val == NULL) {
> + val = apr_table_get(r->subprocess_env, "proxy-interim-response");
> + if (val != NULL) {
> + apr_table_setn(r->notes, "proxy-interim-pong", val);
> + }
> + else {
> + apr_table_setn(r->notes, "proxy-interim-pong", "\n");
> + }
> + }
> + if (!r->expecting_100) {
> + /* Don't forward any "100 Continue" response if the client is
> + * not expecting it. */
> + val = "Suppress";
> + }
> + if (val && (val[0] != '\n' || val[1] != '\0')) {
> + apr_table_setn(r->subprocess_env, "proxy-interim-response", val);
> + }
> + else {
> + apr_table_unset(r->subprocess_env, "proxy-interim-response");
> + }
> +
> + /* Add the Expect header if not already there. */
> + val = apr_table_get(r->headers_in, "Expect");
> + if ((val == NULL)
> + || (strcasecmp(val, "100-Continue") != 0 // fast path
> + && !ap_find_token(r->pool, val, "100-Continue"))) {
> + apr_table_mergen(r->headers_in, "Expect", "100-Continue");
> + }
> }
>
> /* X-Forwarded-*: handling
> [EOS]
>
Re: mod_proxy ping and 100-continue (was Re: NOTE: Intent to T&R
2.2.6 tomorrow)
Posted by Yann Ylavic <yl...@gmail.com>.
Hi,
this is the day of resurrections :p
I think I've got a simpler way to address this issue, that is, don't
send unexpected 100-continue to clients due to proxy ping feature.
Here is the patch.
Once again, please object if you don't want me to commit this stuff.
Reagrds,
Yann.
Index: modules/proxy/proxy_util.c
===================================================================
--- modules/proxy/proxy_util.c (revision 1584652)
+++ modules/proxy/proxy_util.c (working copy)
@@ -3312,8 +3312,43 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbrgd(apr_poo
* to backend
*/
if (do_100_continue) {
- apr_table_mergen(r->headers_in, "Expect", "100-Continue");
- r->expecting_100 = 1;
+ const char *val;
+
+ /* Since we may modify the original "proxy-interim-response" env but
+ * also come back here later with the same request (previous ping
+ * failure, load balancing recoverable error...), we use "\n" as the
+ * saved value when the original one is not defined, so that we can do
+ * the right thing (unset) to restore the env (later) in this case.
+ */
+ val = apr_table_get(r->notes, "proxy-interim-pong");
+ if (val == NULL) {
+ val = apr_table_get(r->subprocess_env, "proxy-interim-response");
+ if (val != NULL) {
+ apr_table_setn(r->notes, "proxy-interim-pong", val);
+ }
+ else {
+ apr_table_setn(r->notes, "proxy-interim-pong", "\n");
+ }
+ }
+ if (!r->expecting_100) {
+ /* Don't forward any "100 Continue" response if the client is
+ * not expecting it. */
+ val = "Suppress";
+ }
+ if (val && (val[0] != '\n' || val[1] != '\0')) {
+ apr_table_setn(r->subprocess_env, "proxy-interim-response", val);
+ }
+ else {
+ apr_table_unset(r->subprocess_env, "proxy-interim-response");
+ }
+
+ /* Add the Expect header if not already there. */
+ val = apr_table_get(r->headers_in, "Expect");
+ if ((val == NULL)
+ || (strcasecmp(val, "100-Continue") != 0 // fast path
+ && !ap_find_token(r->pool, val, "100-Continue"))) {
+ apr_table_mergen(r->headers_in, "Expect", "100-Continue");
+ }
}
/* X-Forwarded-*: handling
[EOS]
mod_proxy ping and 100-continue (was Re: NOTE: Intent to T&R 2.2.6
tomorrow)
Posted by Yann Ylavic <yl...@gmail.com>.
I peek this message from another thread and create a new one, since
details may not be relevant in the T&R note.
On 11/12/2013 06:56 PM, William A. Rowe Jr. wrote:
> On Tue, 12 Nov 2013 11:48:16 -0500
> Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> I intend to T&R 2.2.26 tomorrow... post now if that's
>> an issue or problem...
> As I mentioned earlier, two additional patches should possibly be
> considered for protocol correctness. The first you shepherded into
> trunk, so I'm particularly interested in your thoughts on backporting
> this, Jim...
>
> http://svn.apache.org/viewvc?view=revision&revision=1524192
> http://svn.apache.org/viewvc?view=revision&revision=1524770
> (Note that the commit log message is missing patch attribution)
>
> A backport is attached, as best as I've figured from the trunk-modulo-
> 2.2 code path.
>
> The second is the 100-continue behavior, when proxy-interim-response is
> set to RFC. As Yann noted in a very long and winding message thread,
> the core http filter is pushing a 100 continue interim status, and then
> mod_proxy_http is pushing back yet another interim status response. The
> core status response must be suppressed on proxy-interim-response RFC
> requests.
>
> It's not clear where that discussion thread has ended up, or whether
> there is a usable patch to enforce this behavior. As you had the most
> to contribute to that thread, can you give us your thoughts on its
> current status, Jim?
Actually the issue I described does not depend on the
proxy-interim-response value: when a (positive) ping is configured for
the worker, mod_proxy_http (via ap_proxy_create_hdrbrgd) will set
r->expecting_100 which will cause the http input filter to push a "100
Continue" to the client, before anything is forwarded (when the request
body is prefetched), whether or not the client expects one (eg. "Expect:
100-continue" or not).
But I agree that the proxy-interim-response == "RFC" is an issue too,
per se.
In fact I don't really see why any "100 Continue" response from the
backend should be forwarded to the client, since the client has already
received one during prefetch (from the http input filter, if expected).
When the (interim) response is about to be forwarded, the request has
already been read (fully), hence the client has nothing more to continue...
Forcing another "100 Continue" here (when proxy-interim-response ==
"RFC") is at least useless (it will be ignored), at worst not rfc
compliant (can a receiver send multiple "100 Continue"? when it has
everything already?).
IMHO, the root issue is that mod_proxy_http cannot be an expectation
proxy with its current implementation (forward all the request, then
forward all the response). It acts more as a server for the client and a
client for the backend, and hence should follow the related RFC parts
(not the ones for an expectation proxy, which I guess is what is
intended by the proxy-interim-response == "RFC").
So the 100-continue with the client should be a client<->proxy only
stuff (controlled by r->expecting_100), and the one with the backend
another proxy<->backend only stuff (with the interim responses being
eaten by the proxy), both should be handled separately.
Below is the patch for ap_proxy_create_hdrbrgd (attached too), but I
think a separate client<->proxy and proxy<->backend handling would be
better, I can try to propose it if you agree.
Regards,
Yann.
Index: modules/proxy/proxy_util.c
===================================================================
--- modules/proxy/proxy_util.c (revision 1541907)
+++ modules/proxy/proxy_util.c (working copy)
@@ -3126,7 +3126,7 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbrgd(apr_poo
apr_bucket *e;
int do_100_continue;
conn_rec *origin = p_conn->connection;
- const char *fpr1;
+ const char *fpr1, *expect;
proxy_dir_conf *dconf = ap_get_module_config(r->per_dir_config,
&proxy_module);
/*
@@ -3227,13 +3227,37 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbrgd(apr_poo
);
}
- /* Use HTTP/1.1 100-Continue as quick "HTTP ping" test
- * to backend
+ /* Use HTTP/1.1 100-Continue as quick "HTTP ping" test to backend.
+ * If a ping test was already tried with the same request, restore
+ * the original Expect header to avoid using the modified one with
+ * subsequent requests (the new backend may not be ping-able).
*/
+ expect = apr_table_get(r->notes, "proxy-ping-expect");
+ if (expect == NULL) {
+ expect = apr_table_get(r->headers_in, "Expect");
+ if (expect != NULL) {
+ apr_table_setn(r->notes, "proxy-ping-expect", expect);
+ }
+ else {
+ apr_table_setn(r->notes, "proxy-ping-expect", "\n");
+ }
+ }
+ else if (strcmp(expect, "\n") != 0) {
+ apr_table_setn(r->headers_in, "Expect", expect);
+ }
+ else {
+ apr_table_unset(r->headers_in, "Expect");
+ expect = NULL;
+ }
if (do_100_continue) {
- apr_table_mergen(r->headers_in, "Expect", "100-Continue");
- r->expecting_100 = 1;
+ if (!ap_find_token(r->pool, expect, "100-Continue")) {
+ apr_table_mergen(r->headers_in, "Expect", "100-Continue");
+ }
+ apr_table_setn(r->notes, "proxy-ping-100-continue", "1");
}
+ else {
+ apr_table_unset(r->notes, "proxy-ping-100-continue");
+ }
/* X-Forwarded-*: handling
*
Index: modules/proxy/mod_proxy_http.c
===================================================================
--- modules/proxy/mod_proxy_http.c (revision 1541907)
+++ modules/proxy/mod_proxy_http.c (working copy)
@@ -1537,10 +1537,12 @@ int ap_proxy_http_process_response(apr_pool_t * p,
* We need to set "r->expecting_100 = 1" otherwise origin
* server behaviour will apply.
*/
+ ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r,
+ "HTTP: received interim %d response", r->status);
+ if ((r->status != HTTP_CONTINUE) ||
+ !apr_table_get(r->notes, "proxy-ping-100-continue")) {
const char *policy = apr_table_get(r->subprocess_env,
"proxy-interim-response");
- ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r,
- "HTTP: received interim %d response", r->status);
if (!policy
|| (!strcasecmp(policy, "RFC") &&
((r->expecting_100 = 1)))) {
ap_send_interim_response(r, 1);
@@ -1552,6 +1554,7 @@ int ap_proxy_http_process_response(apr_pool_t * p,
ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r,
APLOGNO(01108)
"undefined proxy interim response policy");
}
+ }
}
/* Moved the fixups of Date headers and those affected by
* ProxyPassReverse/etc from here to ap_proxy_read_headers
[EOS]
Re: NOTE: Intent to T&R 2.2.6 tomorrow
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Tue, 12 Nov 2013 11:48:16 -0500
Jim Jagielski <ji...@jaguNET.com> wrote:
> I intend to T&R 2.2.26 tomorrow... post now if that's
> an issue or problem...
As I mentioned earlier, two additional patches should possibly be
considered for protocol correctness. The first you shepherded into
trunk, so I'm particularly interested in your thoughts on backporting
this, Jim...
http://svn.apache.org/viewvc?view=revision&revision=1524192
http://svn.apache.org/viewvc?view=revision&revision=1524770
(Note that the commit log message is missing patch attribution)
A backport is attached, as best as I've figured from the trunk-modulo-
2.2 code path.
The second is the 100-continue behavior, when proxy-interim-response is
set to RFC. As Yann noted in a very long and winding message thread,
the core http filter is pushing a 100 continue interim status, and then
mod_proxy_http is pushing back yet another interim status response. The
core status response must be suppressed on proxy-interim-response RFC
requests.
It's not clear where that discussion thread has ended up, or whether
there is a usable patch to enforce this behavior. As you had the most
to contribute to that thread, can you give us your thoughts on its
current status, Jim?
And thanks for offering to RM - please remember not to leapfrog the
versions of autoconf/libtool, lest we potentially break configure
behavior on the more obscure platforms, and trigger incompatibilities
in configure.in which only occur on newer versions of autoconf.
Libtool 1.5.26 and autoconf 2.67 were used for 2.2.25 release; any later
1.5 libtool or 2.6x series autoconf aught to work but you would want to
pre- buildconf and review any newer versions before tagging.
I'm happy to RM with that same toolchain as I offered in the first place,
if that environment poses a headache for you. Only the two questions
above seemed relevant to me before moving on with this tag.
Cheers,
Bill