You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/11/13 19:28:23 UTC
2.0.28-beta release?
I'm not sure what the policy is here (this is really up to Greg as
RM), but if 2.0.28 makes it to beta (which I think it has with
three +1s), can we add that patch that fixes the header filters
with ap_die into the beta tarball (modules/http/http_request.c)?
I know that we can't touch the 2.0.28-alpha tarball, but I seem
to recall someone saying we could touch the next-level tarball
(i.e. -beta).
This would resolve a problem that has been fixed and a bunch
of people have reviewed this (me, Ryan, and Cliff).
Just a thought. -- justin
Re: 2.0.28-beta release?
Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 13 November 2001 12:21 pm, William A. Rowe, Jr. wrote:
> From: "Ryan Bloom" <rb...@covalent.net>
> Sent: Tuesday, November 13, 2001 2:00 PM
>
> > On Tuesday 13 November 2001 11:28 am, William A. Rowe, Jr. wrote:
> > > I'd suggest that you checkout on APACHE-2_0_28, tag as
> > > APACHE-2_0_28_ALPHA for historical reasons, then we can add
> > > APACHE-2_0_28_BETA, etc.
> >
> > No, there is 2.0.28, period. There isn't a 2.0.28-alpha and 2.0.28-beta
> > code base. There is one 2.0.28 codebase. You could have different
> > versions if the alpha/beta distinction was in the code, but it isn't. It
> > is only in the tarball name.
>
> Exactly my the point in the following sentence, which you snipped;
>
> > > BTW - 1.3 had this great little minor rev field that always started at
> > > 100. Shame that's gone.
>
> I believe you eliminated this designator, no?
>
> I agree, no code twists after alpha tag until we get a decent versioning
> schema back.
>
> We know this one isn't GA quality (a much better beta, but no GA.) So it's
> pointless to fight over bitty fixes once we rolled the alpha tarball.
Yeah, we had that field, but we didn't do ANYTHING with it. Grep the entire
code base. The only place that macro is used is in the definition.
We have a decent versioning scheme. We have three version numbers,
Major, minor, and patch. Once a release is made, the code for that release
cannot be changed. Changing the code after a release is too confusing, because
it is almost impossible to keep track of which version you are using. If the release
isn't ready to be released, then you go to the next version.
Our problem, is that we have a bunch of perfectionists on this project. :-)
A beta doesn't need to be rock-solid, it just needs to be better than the last
beta. We could have released over 10 betas by now, but one thing or
another always makes us stop the release. If we would roll releases, and get
them into people's hands, the versioning scheme would work just fine. The
problem we are having, is that when we go to make a release, we are
incredibly concerned that there might be one small bug in it, so we keep
making changes after the tag was laid. This gets us right back to the problem
we were having in 1.3, where people are commiting code that hasn't been
well tested, and we are releasing it.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: not in CVS? (was: Re: 2.0.28-beta release?)
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Nov 13, 2001 at 03:51:22PM -0800, Ryan Bloom wrote:
> On Tuesday 13 November 2001 03:49 pm, Greg Stein wrote:
> > On Tue, Nov 13, 2001 at 04:08:09PM -0500, Greg Ames wrote:
> > >...
> > > As it turns out, the docs/conf/httpd-*.conf files also have post-tag
> > > changes. So changing/re-tagging them in cvs would be as complex as
> > > changing the code.
> >
> > WHAT? Are you saying that I cannot produce the 2.0.28 tarball from CVS?
> >
> > That isn't right.
>
> I would go even farther. That is completely bogus, and if it is true, then
> 2.0.28 must be dropped. This is why we shouldn't be making so many changes
> to a tag. Either the tag lives or dies once it has been laid. Small changes,
> fine. But we added like four or five bug fixes to 2.0.28.
Woah hold on...That's not what he's saying. The way I read that was
he wanted to simply apply the httpd-std.conf changes and bump the
tag, but since there have been other fixes since the the tag that
weren't intended to be included in 2.0.28, it wouldn't be feasible.
-aaron
Re: not in CVS? (was: Re: 2.0.28-beta release?)
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Ryan Bloom" <rb...@covalent.net>
Sent: Tuesday, November 13, 2001 5:51 PM
> On Tuesday 13 November 2001 03:49 pm, Greg Stein wrote:
> > On Tue, Nov 13, 2001 at 04:08:09PM -0500, Greg Ames wrote:
> > >...
> > > As it turns out, the docs/conf/httpd-*.conf files also have post-tag
> > > changes. So changing/re-tagging them in cvs would be as complex as
> > > changing the code.
> >
> > WHAT? Are you saying that I cannot produce the 2.0.28 tarball from CVS?
> >
> > That isn't right.
>
> I would go even farther. That is completely bogus, and if it is true, then
> 2.0.28 must be dropped. This is why we shouldn't be making so many changes
> to a tag. Either the tag lives or dies once it has been laid. Small changes,
> fine. But we added like four or five bug fixes to 2.0.28.
Guys ...
... everything that changed was prior to rolling the tarball
... Greg was trying to say that, to flip a patch into httpd-std.conf, he would
have to back out a couple of other changes, commit the 'comment out /error/'
patch, then reapply all the patches. Which is bogus, since that is what
branches are for.
... all of which is apropos of nothing, since we aren't patching .28
Bill
Re: not in CVS? (was: Re: 2.0.28-beta release?)
Posted by Greg Ames <gr...@remulak.net>.
Cliff Woolley wrote:
>
> On Tue, 13 Nov 2001, Ryan Bloom wrote:
>
> > On Tuesday 13 November 2001 03:49 pm, Greg Stein wrote:
> > > On Tue, Nov 13, 2001 at 04:08:09PM -0500, Greg Ames wrote:
> > > >...
> > > > As it turns out, the docs/conf/httpd-*.conf files also have post-tag
> > > > changes. So changing/re-tagging them in cvs would be as complex as
> > > > changing the code.
> > >
> > > WHAT? Are you saying that I cannot produce the 2.0.28 tarball from CVS?
> > > That isn't right.
> >
> > I would go even farther. That is completely bogus, and if it is true, then
> > 2.0.28 must be dropped.
>
> Whoa nelly... I interpreted GregA's statement to mean that there have been
> commits to httpd-*.conf in 2.0.29-dev (which is in fact the case) which
> means it's non-trivial to commit a single-line change and bump the tag
> (you either have to revert, retag, and recommit or branch, retag, and
> merge).
Yeah, what Cliff said.
What I was trying to get across was that it is just as complex to bump
config file fixes in CVS as it is to bump code fixes at this point, if
we were going to allow any changes into the tarballs between alpha and
beta. The consensus appears to be that the tarballs don't change except
in name.
The tarballs are recreatable from CVS, assuming you use the
httpd_roll_release script and do the renames.
Greg
Re: not in CVS? (was: Re: 2.0.28-beta release?)
Posted by Cliff Woolley <cl...@yahoo.com>.
On Tue, 13 Nov 2001, Ryan Bloom wrote:
> On Tuesday 13 November 2001 03:49 pm, Greg Stein wrote:
> > On Tue, Nov 13, 2001 at 04:08:09PM -0500, Greg Ames wrote:
> > >...
> > > As it turns out, the docs/conf/httpd-*.conf files also have post-tag
> > > changes. So changing/re-tagging them in cvs would be as complex as
> > > changing the code.
> >
> > WHAT? Are you saying that I cannot produce the 2.0.28 tarball from CVS?
> > That isn't right.
>
> I would go even farther. That is completely bogus, and if it is true, then
> 2.0.28 must be dropped.
Whoa nelly... I interpreted GregA's statement to mean that there have been
commits to httpd-*.conf in 2.0.29-dev (which is in fact the case) which
means it's non-trivial to commit a single-line change and bump the tag
(you either have to revert, retag, and recommit or branch, retag, and
merge).
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: not in CVS? (was: Re: 2.0.28-beta release?)
Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 13 November 2001 03:49 pm, Greg Stein wrote:
> On Tue, Nov 13, 2001 at 04:08:09PM -0500, Greg Ames wrote:
> >...
> > As it turns out, the docs/conf/httpd-*.conf files also have post-tag
> > changes. So changing/re-tagging them in cvs would be as complex as
> > changing the code.
>
> WHAT? Are you saying that I cannot produce the 2.0.28 tarball from CVS?
>
> That isn't right.
I would go even farther. That is completely bogus, and if it is true, then
2.0.28 must be dropped. This is why we shouldn't be making so many changes
to a tag. Either the tag lives or dies once it has been laid. Small changes,
fine. But we added like four or five bug fixes to 2.0.28.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
RE: 2.0.28-beta release?
Posted by Joshua Slive <jo...@slive.ca>.
> From: gregames@Mail.MeepZor.Com [mailto:gregames@Mail.MeepZor.Com]On
>> > Let's just get this out the door ;)
>
> Sounds great. I can go ahead & rename & move tarballs.
> /httpd.apache.org/dist/httpd/README.html needs some updating, no matter
> where we decide to track the issues.
Hey, you're the release manager, right?
We all have suggestions, but someone needs to just go do it. As the release
manager, you have the authority to pick what you think will work best and
just go for it.
(Not that that will prevent us from bitching about it later ;-)
Joshua.
Re: 2.0.28-beta release?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Tue, 13 Nov 2001, Greg Ames wrote:
> Several people have mentioned release notes. Where does it exist? Is
> this the paragraph in /httpd.apache.org/dist/httpd/README.html about the
> release?
Last time I RM'ed, I just kept a running list in an email that I sent out
once or twice a day while we were in the process of testing the release,
and then I sent that same list out to the current-testers when I announced
to them and I would have sent it also to the announce list if we'd gone
beta with that release (probably should've <sigh>). From there, putting
it in the README.html is not a bad idea and/or the known issues webpage
Joshua mentioned.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.28-beta release?
Posted by Greg Ames <gr...@remulak.net>.
"William A. Rowe, Jr." wrote:
>
> From: "Greg Ames" <gr...@remulak.net>
> Sent: Tuesday, November 13, 2001 3:08 PM
>
> > How about this? comment out the ErrorDocument 401 lines in the
> > docs/conf/httpd-*.conf files, along with a comment line or two saying
> > that a patch exists, inside the tarballs. Re-roll, re-sign, rename as
> > beta, leave cvs alone.
> >
>
> No... leave them alone entirely. Add a comment to the release notes that
> this would be suggested for complex configurations, especially if authorization
> is applied to <Location /> or <Location /error>.
Several people have mentioned release notes. Where does it exist? Is
this the paragraph in /httpd.apache.org/dist/httpd/README.html about the
release?
We have already identified problems with:
* 401 ErrorDocuments,
* r-proxy, and
* DSOs on Darwin
and it's only been a day so far. We can't put everything that comes up
in the future in that paragraph.
> Let's just get this out the door ;)
Sounds great. I can go ahead & rename & move tarballs.
/httpd.apache.org/dist/httpd/README.html needs some updating, no matter
where we decide to track the issues.
Greg
Re: 2.0.28-beta release?
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Greg Ames" <gr...@remulak.net>
Sent: Tuesday, November 13, 2001 3:08 PM
> How about this? comment out the ErrorDocument 401 lines in the
> docs/conf/httpd-*.conf files, along with a comment line or two saying
> that a patch exists, inside the tarballs. Re-roll, re-sign, rename as
> beta, leave cvs alone.
>
No... leave them alone entirely. Add a comment to the release notes that
this would be suggested for complex configurations, especially if authorization
is applied to <Location /> or <Location /error>.
If we get a report, close it with this explanation. If we get more, close
them as dups.
Let's just get this out the door ;)
Bill
not in CVS? (was: Re: 2.0.28-beta release?)
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 13, 2001 at 04:08:09PM -0500, Greg Ames wrote:
>...
> As it turns out, the docs/conf/httpd-*.conf files also have post-tag
> changes. So changing/re-tagging them in cvs would be as complex as
> changing the code.
WHAT? Are you saying that I cannot produce the 2.0.28 tarball from CVS?
That isn't right.
-g
--
Greg Stein, http://www.lyra.org/
Re: 2.0.28-beta release?
Posted by Greg Ames <gr...@remulak.net>.
"William A. Rowe, Jr." wrote:
>
> From: "Ryan Bloom" <rb...@covalent.net>
> Sent: Tuesday, November 13, 2001 2:00 PM
>
> > On Tuesday 13 November 2001 11:28 am, William A. Rowe, Jr. wrote:
> > >
> > > I'd suggest that you checkout on APACHE-2_0_28, tag as APACHE-2_0_28_ALPHA
> > > for historical reasons, then we can add APACHE-2_0_28_BETA, etc.
> >
> > No, there is 2.0.28, period. There isn't a 2.0.28-alpha and 2.0.28-beta
> > code base. There is one 2.0.28 codebase. You could have different versions
> > if the alpha/beta distinction was in the code, but it isn't. It is only in the tarball
> > name.
> I agree, no code twists after alpha tag until we get a decent versioning schema back.
> We know this one isn't GA quality (a much better beta, but no GA.) So it's pointless
> to fight over bitty fixes once we rolled the alpha tarball.
As it turns out, the docs/conf/httpd-*.conf files also have post-tag
changes. So changing/re-tagging them in cvs would be as complex as
changing the code.
How about this? comment out the ErrorDocument 401 lines in the
docs/conf/httpd-*.conf files, along with a comment line or two saying
that a patch exists, inside the tarballs. Re-roll, re-sign, rename as
beta, leave cvs alone.
Otherwise, we probably should document the bug somewhere. If
"somewhere" is a file inside the tarball, why not just make the change
in the sample configs and be done with it?
Greg
Re: 2.0.28-beta release?
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Ryan Bloom" <rb...@covalent.net>
Sent: Tuesday, November 13, 2001 2:00 PM
> On Tuesday 13 November 2001 11:28 am, William A. Rowe, Jr. wrote:
> >
> > I'd suggest that you checkout on APACHE-2_0_28, tag as APACHE-2_0_28_ALPHA
> > for historical reasons, then we can add APACHE-2_0_28_BETA, etc.
>
> No, there is 2.0.28, period. There isn't a 2.0.28-alpha and 2.0.28-beta
> code base. There is one 2.0.28 codebase. You could have different versions
> if the alpha/beta distinction was in the code, but it isn't. It is only in the tarball
> name.
Exactly my the point in the following sentence, which you snipped;
> > BTW - 1.3 had this great little minor rev field that always started at 100.
> > Shame that's gone.
I believe you eliminated this designator, no?
I agree, no code twists after alpha tag until we get a decent versioning schema back.
We know this one isn't GA quality (a much better beta, but no GA.) So it's pointless
to fight over bitty fixes once we rolled the alpha tarball.
Bill
Re: 2.0.28-beta release?
Posted by Austin Gonyou <au...@coremetrics.com>.
Beta means bugs, but as few bugs as you can manage. Also bugs which are
out in the release should be known to a certain degree and bugs from the
previous release being fixed in the subsequent release/releases. That
said, As far as I can tell, 2.0.28 is beta material. Just my simple
minded $0.02
On Tue, 2001-11-13 at 17:02, Greg Stein wrote:
> On Tue, Nov 13, 2001 at 12:00:31PM -0800, Ryan Bloom wrote:
> > On Tuesday 13 November 2001 11:28 am, William A. Rowe, Jr. wrote:
> > > From: "Greg Ames" <gr...@remulak.net>
> > > Sent: Tuesday, November 13, 2001 12:56 PM
> >...
> > > > that file, do the PITA dance with the CHANGES file, probably do a
> little
> > > > testing, re-roll, rename the tarballs as beta. What do others
> think? I
> > > > could note that this happened in the CHANGES file since I have to
> mess
> > > > with it anyway.
> > >
> > > I'd suggest that you checkout on APACHE-2_0_28, tag as
> APACHE-2_0_28_ALPHA
> > > for historical reasons, then we can add APACHE-2_0_28_BETA, etc.
> >
> > No, there is 2.0.28, period. There isn't a 2.0.28-alpha and
> 2.0.28-beta
> > code base. There is one 2.0.28 codebase. You could have different
> versions
> > if the alpha/beta distinction was in the code, but it isn't. It is
> only in the tarball
> > name.
>
> I'm with Ryan. 2.0.28 is exactly that. alpha and beta are
> *designations*.
> They are not code changes.
>
> 2.0.28 should be buildable from the label. If the CHANGES file was
> modified
> *outside* of that, then we have a problem.
>
> Ship the damned code. This is a BETA for crying out loud. We don't need
> to
> weasel patches in. "oh, just this one little fix." Fuck that. Beta means
> bugs. Beta means that we have a list of issues for people to be
> concerned
> with. Beta means people may have platform-specific problems. Beta is not
> GA.
>
> +1 on beta. Get a release out the door. Christ almighty... what's it
> take
> around here? The new release process was intended to get tarballs *out*
> to
> people. Not to be held up in a bunch of snippy little bug fix this, bug
> fix
> that. Ship it out with bugs. Call it alpha if it doesn't feel right.
> Call it
> beta if it feels good.
>
> If an ErrorDocument doesn't work in one case, then tell people "too bad.
> don't do that". If the server dies with a particular subrequest executed
> from some wonky CGI-provided SSI document, then say "get this patch."
> But we
> gotta get more releases out into the public's hands.
>
> 2.0.16 was crap. Should people really be using that? Not a chance.
>
> Give them 2.0.28.
>
> -g
>
> --
> Greg Stein, http://www.lyra.org/
--
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com
Re: 2.0.28-beta release?
Posted by Bill Stoddard <bi...@wstoddard.com>.
> >
> > No, there is 2.0.28, period. There isn't a 2.0.28-alpha and 2.0.28-beta
> > code base. There is one 2.0.28 codebase. You could have different versions
> > if the alpha/beta distinction was in the code, but it isn't. It is only in the
tarball
> > name.
>
> I'm with Ryan. 2.0.28 is exactly that. alpha and beta are *designations*.
> They are not code changes.
>
> 2.0.28 should be buildable from the label. If the CHANGES file was modified
> *outside* of that, then we have a problem.
>
> Ship the damned code. This is a BETA for crying out loud. We don't need to
> weasel patches in. "oh, just this one little fix." Fuck that. Beta means
> bugs. Beta means that we have a list of issues for people to be concerned
> with. Beta means people may have platform-specific problems. Beta is not GA.
>
> +1 on beta. Get a release out the door. Christ almighty... what's it take
> around here? The new release process was intended to get tarballs *out* to
> people. Not to be held up in a bunch of snippy little bug fix this, bug fix
> that. Ship it out with bugs. Call it alpha if it doesn't feel right. Call it
> beta if it feels good.
>
> If an ErrorDocument doesn't work in one case, then tell people "too bad.
> don't do that". If the server dies with a particular subrequest executed
> from some wonky CGI-provided SSI document, then say "get this patch." But we
> gotta get more releases out into the public's hands.
>
> 2.0.16 was crap. Should people really be using that? Not a chance.
>
> Give them 2.0.28.
>
> -g
>
+++++1 :-)
Bill
Re: 2.0.28-beta release?
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 13, 2001 at 12:00:31PM -0800, Ryan Bloom wrote:
> On Tuesday 13 November 2001 11:28 am, William A. Rowe, Jr. wrote:
> > From: "Greg Ames" <gr...@remulak.net>
> > Sent: Tuesday, November 13, 2001 12:56 PM
>...
> > > that file, do the PITA dance with the CHANGES file, probably do a little
> > > testing, re-roll, rename the tarballs as beta. What do others think? I
> > > could note that this happened in the CHANGES file since I have to mess
> > > with it anyway.
> >
> > I'd suggest that you checkout on APACHE-2_0_28, tag as APACHE-2_0_28_ALPHA
> > for historical reasons, then we can add APACHE-2_0_28_BETA, etc.
>
> No, there is 2.0.28, period. There isn't a 2.0.28-alpha and 2.0.28-beta
> code base. There is one 2.0.28 codebase. You could have different versions
> if the alpha/beta distinction was in the code, but it isn't. It is only in the tarball
> name.
I'm with Ryan. 2.0.28 is exactly that. alpha and beta are *designations*.
They are not code changes.
2.0.28 should be buildable from the label. If the CHANGES file was modified
*outside* of that, then we have a problem.
Ship the damned code. This is a BETA for crying out loud. We don't need to
weasel patches in. "oh, just this one little fix." Fuck that. Beta means
bugs. Beta means that we have a list of issues for people to be concerned
with. Beta means people may have platform-specific problems. Beta is not GA.
+1 on beta. Get a release out the door. Christ almighty... what's it take
around here? The new release process was intended to get tarballs *out* to
people. Not to be held up in a bunch of snippy little bug fix this, bug fix
that. Ship it out with bugs. Call it alpha if it doesn't feel right. Call it
beta if it feels good.
If an ErrorDocument doesn't work in one case, then tell people "too bad.
don't do that". If the server dies with a particular subrequest executed
from some wonky CGI-provided SSI document, then say "get this patch." But we
gotta get more releases out into the public's hands.
2.0.16 was crap. Should people really be using that? Not a chance.
Give them 2.0.28.
-g
--
Greg Stein, http://www.lyra.org/
Re: 2.0.28-beta release?
Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 13 November 2001 11:28 am, William A. Rowe, Jr. wrote:
> From: "Greg Ames" <gr...@remulak.net>
> Sent: Tuesday, November 13, 2001 12:56 PM
>
> > Justin Erenkrantz wrote:
> > > I know that we can't touch the 2.0.28-alpha tarball, but I seem
> > > to recall someone saying we could touch the next-level tarball
> > > (i.e. -beta).
> >
> > hmmmm...that's an interesting idea. I like it! I would bump the tag on
> > that file, do the PITA dance with the CHANGES file, probably do a little
> > testing, re-roll, rename the tarballs as beta. What do others think? I
> > could note that this happened in the CHANGES file since I have to mess
> > with it anyway.
>
> I'd suggest that you checkout on APACHE-2_0_28, tag as APACHE-2_0_28_ALPHA
> for historical reasons, then we can add APACHE-2_0_28_BETA, etc.
No, there is 2.0.28, period. There isn't a 2.0.28-alpha and 2.0.28-beta
code base. There is one 2.0.28 codebase. You could have different versions
if the alpha/beta distinction was in the code, but it isn't. It is only in the tarball
name.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2.0.28-beta release?
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Greg Ames" <gr...@remulak.net>
Sent: Tuesday, November 13, 2001 12:56 PM
> Justin Erenkrantz wrote:
> >
> > I know that we can't touch the 2.0.28-alpha tarball, but I seem
> > to recall someone saying we could touch the next-level tarball
> > (i.e. -beta).
>
> hmmmm...that's an interesting idea. I like it! I would bump the tag on
> that file, do the PITA dance with the CHANGES file, probably do a little
> testing, re-roll, rename the tarballs as beta. What do others think? I
> could note that this happened in the CHANGES file since I have to mess
> with it anyway.
I'd suggest that you checkout on APACHE-2_0_28, tag as APACHE-2_0_28_ALPHA
for historical reasons, then we can add APACHE-2_0_28_BETA, etc.
BTW - 1.3 had this great little minor rev field that always started at 100.
Shame that's gone.
Bill
Re: 2.0.28-beta release?
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Greg Ames" <gr...@remulak.net>
Sent: Tuesday, November 13, 2001 1:06 PM
> Greg Ames wrote:
>
> > hmmmm...that's an interesting idea. I like it! I would bump the tag on
> > that file,
>
> crap... I just looked at viewcvs. There's been two other changes to
> that file since the tag, one of which probably hit multiple files. It's
> starting too sound risky to pull in the patch.
Then branch already (that one file), for goodness sakes, using APACHE_2_0_28
as the branch identifier, APACHE_2_0_28_A1 as the original file, and now
APACHE_2_0_28_B1 as the new tag.
How on earth do you suppose CHANGES or STATUS could ever be appropriately marked
without a branch on those two files?
> Why don't we go with commenting out the 401 error document, and include
> the patch in the release notes?
No nevermind here if either the fix, or the warning goes in.
Re: 2.0.28-beta release?
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Nov 13, 2001 at 02:06:03PM -0500, Greg Ames wrote:
> crap... I just looked at viewcvs. There's been two other changes to
> that file since the tag, one of which probably hit multiple files. It's
> starting too sound risky to pull in the patch.
>
> Why don't we go with commenting out the 401 error document, and include
> the patch in the release notes?
++1
We've got to get this out to more people and replace 2.0.16/18. Beta
testers can deal with Release Notes and Bug databases quite well.
There will be more bugs. What makes this a beta right now is that it
is obviously an improvement over the prior beta.
-aaron (who thinks we should release betas more often)
Re: 2.0.28-beta release?
Posted by Greg Ames <gr...@remulak.net>.
Greg Ames wrote:
> hmmmm...that's an interesting idea. I like it! I would bump the tag on
> that file,
crap... I just looked at viewcvs. There's been two other changes to
that file since the tag, one of which probably hit multiple files. It's
starting too sound risky to pull in the patch.
Why don't we go with commenting out the 401 error document, and include
the patch in the release notes?
Greg
Re: 2.0.28-beta release?
Posted by Greg Ames <gr...@remulak.net>.
Justin Erenkrantz wrote:
>
> I'm not sure what the policy is here (this is really up to Greg as
> RM), but if 2.0.28 makes it to beta (which I think it has with
> three +1s), can we add that patch that fixes the header filters
> with ap_die into the beta tarball (modules/http/http_request.c)?
I don't know what the policy is either. I've been trying to come up
with a method of including that fix in some way that wouldn't confuse
people or cause harm.
> I know that we can't touch the 2.0.28-alpha tarball, but I seem
> to recall someone saying we could touch the next-level tarball
> (i.e. -beta).
hmmmm...that's an interesting idea. I like it! I would bump the tag on
that file, do the PITA dance with the CHANGES file, probably do a little
testing, re-roll, rename the tarballs as beta. What do others think? I
could note that this happened in the CHANGES file since I have to mess
with it anyway.
I'm assuming that Austin's build problem isn't a showstopper. He's on
Linux, right?
Greg
Re: 2.0.28-beta release?
Posted by Greg Ames <gr...@remulak.net>.
"Roy T. Fielding" wrote:
>
> On Tue, Nov 13, 2001 at 10:28:23AM -0800, Justin Erenkrantz wrote:
> > I'm not sure what the policy is here (this is really up to Greg as
> > RM), but if 2.0.28 makes it to beta (which I think it has with
> > three +1s), can we add that patch that fixes the header filters
> > with ap_die into the beta tarball (modules/http/http_request.c)?
>
> Patches like that should be added to
>
> www.apache.org/dist/httpd/patches/apply_to_2.0.28/
>
> with a description at the top of the file.
done.
Greg
Re: 2.0.28-beta release?
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Tue, Nov 13, 2001 at 10:28:23AM -0800, Justin Erenkrantz wrote:
> I'm not sure what the policy is here (this is really up to Greg as
> RM), but if 2.0.28 makes it to beta (which I think it has with
> three +1s), can we add that patch that fixes the header filters
> with ap_die into the beta tarball (modules/http/http_request.c)?
Patches like that should be added to
www.apache.org/dist/httpd/patches/apply_to_2.0.28/
with a description at the top of the file.
....Roy
Re: 2.0.28-beta release?
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Nov 13, 2001 at 10:28:23AM -0800, Justin Erenkrantz wrote:
> I'm not sure what the policy is here (this is really up to Greg as
> RM), but if 2.0.28 makes it to beta (which I think it has with
> three +1s), can we add that patch that fixes the header filters
> with ap_die into the beta tarball (modules/http/http_request.c)?
>
> I know that we can't touch the 2.0.28-alpha tarball, but I seem
> to recall someone saying we could touch the next-level tarball
> (i.e. -beta).
This is Greg's call, but I'm pretty opposed to touching a beta for
any reason. Roll another version if it's got problems, and include
a known_issues or release_notes file with the older tarball.
-aaron
Re: 2.0.28-beta release --coredumps
Posted by Greg Ames <gr...@remulak.net>.
Ian Holsman wrote:
> I'll try to get a dump file on my solaris box.
> (no idea why linux isn't giving me a core)
Getting coredumps on Linux has been problematic here too. If you're
using a threaded MPM, switching to prefork or a 2.4.x kernel can help,
and of course ulimit -c and permissions.
Greg
Re: 2.0.28-beta release --coredumps
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Tue, Nov 13, 2001 at 12:49:50PM -0800, Ian Holsman wrote:
> > yep... I can get coredumps via this method.
> > but it doesn't dump core on solaris.
> > it serves a page weirdly, like the mod-include
> > is putting the buckets into the bridgade in the wrong order.
> >
> > This only happens when both the main file and the included file are
> > r-proxied.
>
> Something funny is happening here. Will try to look tonight.
>
> Would you be okay if Greg included something along the lines of
> "ProxyPass directives may not work with included files. We are
> researching this." in a Known Problems section of the 2.0.28
> release notes?
>
> We *really* need to get this out as a beta and 2.0.29 isn't
> releasable any time soon.
>
I agree. I am still +1 for 2.0.28 beta. Document the known problems and move on. If 2.0.28
doesn;t go out, we will be next year getting a beta out.
> beta != bug-free. -- justin
>
Re: 2.0.28-beta release --coredumps
Posted by Marc Slemko <ma...@znep.com>.
On Tue, 13 Nov 2001, Aaron Bannert wrote:
> On Tue, Nov 13, 2001 at 08:44:40PM -0800, Marc Slemko wrote:
> > because we don't have a bug database that can support this in a
> > sufficient manner.
>
> Can we do this with Bugzilla? Pier?
bugzilla can deal with certain parts of this, and is one option for
building a system on top of, but by itself bugzilla is missing a lot
of things and is extremely annoying for certain things.
Ending up with a better bugdb isn't a matter of installing some
software and saying "have at it", but requires figuring out what
we need and how to get that out of the software, what we want, what
the migration path is, getting a consensus on how the software should
be used, etc.
Re: 2.0.28-beta release --coredumps
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Nov 13, 2001 at 08:44:40PM -0800, Marc Slemko wrote:
> because we don't have a bug database that can support this in a
> sufficient manner.
Can we do this with Bugzilla? Pier?
-aaron
Re: 2.0.28-beta release --coredumps
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 14/11/2001 04:44 am, "Marc Slemko" <ma...@znep.com> wrote:
> On Tue, 13 Nov 2001, Ryan Bloom wrote:
>
>> How about we just put the known issues in the bug database? We already
>> tell people to look there, and we can close them immediately, as fixed in
>> CVS.
>
> because we don't have a bug database that can support this in a
> sufficient manner.
>
> Release showstoppers should be in a bug database too.
>
> Most of the status file should be too.
>
> But they aren't because we don't have the bug database to do that
> in a way that people can buy into and that is pratical to use.
Can't remember who asked me about that (probably Aaron?) but folks, if you
want to have a go on BugZilla, you're more than welcome to... It sucks
badly, but less than GNATS... Check it out http://nagoya.apache.org/bugzilla
Pier
Re: 2.0.28-beta release --coredumps
Posted by Marc Slemko <ma...@znep.com>.
On Tue, 13 Nov 2001, Ryan Bloom wrote:
> How about we just put the known issues in the bug database? We already
> tell people to look there, and we can close them immediately, as fixed in
> CVS.
because we don't have a bug database that can support this in a
sufficient manner.
Release showstoppers should be in a bug database too.
Most of the status file should be too.
But they aren't because we don't have the bug database to do that
in a way that people can buy into and that is pratical to use.
Re: 2.0.28-beta release --coredumps
Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 13 November 2001 01:21 pm, Greg Ames wrote:
> Ian Holsman wrote:
> > On Tue, 2001-11-13 at 12:55, Justin Erenkrantz wrote:
> > > On Tue, Nov 13, 2001 at 12:49:50PM -0800, Ian Holsman wrote:
> > > > yep... I can get coredumps via this method.
> > > > but it doesn't dump core on solaris.
> > > > it serves a page weirdly, like the mod-include
> > > > is putting the buckets into the bridgade in the wrong order.
> > > >
> > > > This only happens when both the main file and the included file are
> > > > r-proxied.
> > >
> > > Something funny is happening here. Will try to look tonight.
> > >
> > > Would you be okay if Greg included something along the lines of
> > > "ProxyPass directives may not work with included files. We are
> > > researching this." in a Known Problems section of the 2.0.28
> > > release notes?
> >
> > Yeah... I'm +1 on a beta.
> >
> > can you include a line like
> > "Including a remote file from another remote file via mod-include does
> > not currently work" in the known problems.
>
> cool.
>
> How about a "httpd-2.0.28-beta.known.issues" file in
> /httpd.apache.org/dist/httpd/ ? Then anyone with write permissions can
> update it, if other stuff happens to pop up in the future.
How about we just put the known issues in the bug database? We already
tell people to look there, and we can close them immediately, as fixed in
CVS.
Otherwise, you are telling people to look in two locations, and we have a
hard enough time getting them to look in one.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2.0.28-beta release --coredumps
Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 13 November 2001 01:50 pm, Cliff Woolley wrote:
> On Tue, 13 Nov 2001, Greg Ames wrote:
> > > Why not use the STATUS file?
> >
> > It lives either inside the tarball or in CVS. Once we make beta
> > tarballs available, we can't be mucking with them. Maybe I'm wrong, but
> > I wouldn't expect everybody who might want to use a beta to also use our
> > CVS.
>
> Besides, we don't distribute the STATUS file. It gets deleted by the roll
> script.
I doubt everybody who uses a beta also uses CVS. That is most likely true
for an alpha, but not a beta.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2.0.28-beta release --coredumps
Posted by Cliff Woolley <cl...@yahoo.com>.
On Tue, 13 Nov 2001, Greg Ames wrote:
> > Why not use the STATUS file?
>
> It lives either inside the tarball or in CVS. Once we make beta
> tarballs available, we can't be mucking with them. Maybe I'm wrong, but
> I wouldn't expect everybody who might want to use a beta to also use our
> CVS.
Besides, we don't distribute the STATUS file. It gets deleted by the roll
script.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.28-beta release --coredumps
Posted by Greg Ames <gr...@remulak.net>.
Bill Stoddard wrote:
>
> Why not use the STATUS file?
It lives either inside the tarball or in CVS. Once we make beta
tarballs available, we can't be mucking with them. Maybe I'm wrong, but
I wouldn't expect everybody who might want to use a beta to also use our
CVS.
> > > can you include a line like
> > > "Including a remote file from another remote file via mod-include does
> > > not currently work" in the known problems.
> >
> > cool.
> >
> > How about a "httpd-2.0.28-beta.known.issues" file in
> > /httpd.apache.org/dist/httpd/ ? Then anyone with write permissions can
> > update it, if other stuff happens to pop up in the future.
Greg
Re: 2.0.28-beta release --coredumps
Posted by Bill Stoddard <bi...@wstoddard.com>.
Why not use the STATUS file?
Bill
----- Original Message -----
From: "Greg Ames" <gr...@remulak.net>
To: <de...@httpd.apache.org>
Sent: Tuesday, November 13, 2001 4:21 PM
Subject: Re: 2.0.28-beta release --coredumps
> Ian Holsman wrote:
> >
> > On Tue, 2001-11-13 at 12:55, Justin Erenkrantz wrote:
> > > On Tue, Nov 13, 2001 at 12:49:50PM -0800, Ian Holsman wrote:
> > > > yep... I can get coredumps via this method.
> > > > but it doesn't dump core on solaris.
> > > > it serves a page weirdly, like the mod-include
> > > > is putting the buckets into the bridgade in the wrong order.
> > > >
> > > > This only happens when both the main file and the included file are
> > > > r-proxied.
> > >
> > > Something funny is happening here. Will try to look tonight.
> > >
> > > Would you be okay if Greg included something along the lines of
> > > "ProxyPass directives may not work with included files. We are
> > > researching this." in a Known Problems section of the 2.0.28
> > > release notes?
> >
> > Yeah... I'm +1 on a beta.
> >
> > can you include a line like
> > "Including a remote file from another remote file via mod-include does
> > not currently work" in the known problems.
>
> cool.
>
> How about a "httpd-2.0.28-beta.known.issues" file in
> /httpd.apache.org/dist/httpd/ ? Then anyone with write permissions can
> update it, if other stuff happens to pop up in the future.
>
> Greg
>
RE: 2.0.28-beta release --coredumps
Posted by Joshua Slive <jo...@slive.ca>.
> From: gregames@Mail.MeepZor.Com [mailto:gregames@Mail.MeepZor.Com]On
> Behalf Of Greg Ames
> How about a "httpd-2.0.28-beta.known.issues" file in
> /httpd.apache.org/dist/httpd/ ? Then anyone with write permissions can
> update it, if other stuff happens to pop up in the future.
I suggest httpd-site/info/known_bugs.html which already exists (although it
hasn't been updated since 1.3.4). Feel free to wipe it clean, then link it
in from the README in dist. It is already linked from
http://httpd.apache.org/bug_report.html.
We can also drop patches in
http://httpd.apache.org/dist/httpd/patches/
Joshua.
Re: 2.0.28-beta release --coredumps
Posted by Greg Ames <gr...@remulak.net>.
Ian Holsman wrote:
>
> On Tue, 2001-11-13 at 12:55, Justin Erenkrantz wrote:
> > On Tue, Nov 13, 2001 at 12:49:50PM -0800, Ian Holsman wrote:
> > > yep... I can get coredumps via this method.
> > > but it doesn't dump core on solaris.
> > > it serves a page weirdly, like the mod-include
> > > is putting the buckets into the bridgade in the wrong order.
> > >
> > > This only happens when both the main file and the included file are
> > > r-proxied.
> >
> > Something funny is happening here. Will try to look tonight.
> >
> > Would you be okay if Greg included something along the lines of
> > "ProxyPass directives may not work with included files. We are
> > researching this." in a Known Problems section of the 2.0.28
> > release notes?
>
> Yeah... I'm +1 on a beta.
>
> can you include a line like
> "Including a remote file from another remote file via mod-include does
> not currently work" in the known problems.
cool.
How about a "httpd-2.0.28-beta.known.issues" file in
/httpd.apache.org/dist/httpd/ ? Then anyone with write permissions can
update it, if other stuff happens to pop up in the future.
Greg
Re: 2.0.28-beta release --coredumps
Posted by Ian Holsman <ia...@cnet.com>.
On Tue, 2001-11-13 at 12:55, Justin Erenkrantz wrote:
> On Tue, Nov 13, 2001 at 12:49:50PM -0800, Ian Holsman wrote:
> > yep... I can get coredumps via this method.
> > but it doesn't dump core on solaris.
> > it serves a page weirdly, like the mod-include
> > is putting the buckets into the bridgade in the wrong order.
> >
> > This only happens when both the main file and the included file are
> > r-proxied.
>
> Something funny is happening here. Will try to look tonight.
>
> Would you be okay if Greg included something along the lines of
> "ProxyPass directives may not work with included files. We are
> researching this." in a Known Problems section of the 2.0.28
> release notes?
Yeah... I'm +1 on a beta.
can you include a line like
"Including a remote file from another remote file via mod-include does
not currently work" in the known problems.
>
> We *really* need to get this out as a beta and 2.0.29 isn't
> releasable any time soon.
>
> beta != bug-free. -- justin
agreed.
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 344-2608
Re: 2.0.28-beta release --coredumps
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Nov 13, 2001 at 12:49:50PM -0800, Ian Holsman wrote:
> yep... I can get coredumps via this method.
> but it doesn't dump core on solaris.
> it serves a page weirdly, like the mod-include
> is putting the buckets into the bridgade in the wrong order.
>
> This only happens when both the main file and the included file are
> r-proxied.
Something funny is happening here. Will try to look tonight.
Would you be okay if Greg included something along the lines of
"ProxyPass directives may not work with included files. We are
researching this." in a Known Problems section of the 2.0.28
release notes?
We *really* need to get this out as a beta and 2.0.29 isn't
releasable any time soon.
beta != bug-free. -- justin
Re: 2.0.28-beta release --coredumps
Posted by Ian Holsman <ia...@cnet.com>.
On Tue, 2001-11-13 at 12:14, Justin Erenkrantz wrote:
> On Tue, Nov 13, 2001 at 03:07:00PM -0500, Jeff Trawick wrote:
> > If you're starting httpd as root on Solaris, I don't think you're
> > gonna get core dumps. End of story. (I'd be thrilled to be proven
> > wrong!!! Please!!!!!!!). There is no sort of system control on
> > Solaris to let a process that switched form uid=0 coredump.
>
> man coreadm
>
yep... I can get coredumps via this method.
but it doesn't dump core on solaris.
it serves a page weirdly, like the mod-include
is putting the buckets into the bridgade in the wrong order.
This only happens when both the main file and the included file are
r-proxied.
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 344-2608
Re: 2.0.28-beta release --coredumps
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Nov 13, 2001 at 12:14:34PM -0800, Justin Erenkrantz wrote:
> Anything and everything that coredumps gets captured. We get
> a bunch of segfaults from nscd on Solaris 8. =) And, it captures
> all of the setuid segfaults from httpd just fine. -- justin
It even grabs things like suexec, which aren't normally dumped for
obvious reasons. Very handy indeed.
-aaron
Re: 2.0.28-beta release --coredumps
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Nov 13, 2001 at 04:19:07PM -0500, Jeff Trawick wrote:
> too cool! (I dunno where I heard otherwise... whatever :) )
>
> by the way... if anybody knows of any decent web page on coredumps
> (like general issues of file permissions, ulimit; or system-dependent
> issues like coreadm on Solaris or the kern.sugid_coredump variable on
> FreeBSD) I'd love to see it
Starting point:
http://dev.apache.org/debugging.html
I've got a rewrite in place for the new httpd site, but I need
the time to finish off the rest of the site (minor nitpicks) and
switch httpd.apache.org over to it.
If you have more info, patches are welcomed - I can fit it into
the new layout, etc, etc. -- justin
Re: 2.0.28-beta release --coredumps
Posted by Dirk-Willem van Gulik <di...@covalent.net>.
On 13 Nov 2001, Jeff Trawick wrote:
> > global core file pattern: /coredumps/core.%f.%p
> > init core file pattern: /coredumps/init-core.%f.%p
Be *very* carefull about putting the pid in the coredump string on a
production machine. You may run out of diskspace quicker than you expect.
Dw
Re: 2.0.28-beta release --coredumps
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> On Tue, Nov 13, 2001 at 03:07:00PM -0500, Jeff Trawick wrote:
> > If you're starting httpd as root on Solaris, I don't think you're
> > gonna get core dumps. End of story. (I'd be thrilled to be proven
> > wrong!!! Please!!!!!!!). There is no sort of system control on
> > Solaris to let a process that switched form uid=0 coredump.
>
> man coreadm
>
> % coreadm
> global core file pattern: /coredumps/core.%f.%p
> init core file pattern: /coredumps/init-core.%f.%p
> global core dumps: enabled
> per-process core dumps: enabled
> global setid core dumps: enabled
> per-process setid core dumps: enabled
> global core dump logging: enabled
>
> Anything and everything that coredumps gets captured. We get
> a bunch of segfaults from nscd on Solaris 8. =) And, it captures
> all of the setuid segfaults from httpd just fine. -- justin
too cool! (I dunno where I heard otherwise... whatever :) )
by the way... if anybody knows of any decent web page on coredumps
(like general issues of file permissions, ulimit; or system-dependent
issues like coreadm on Solaris or the kern.sugid_coredump variable on
FreeBSD) I'd love to see it
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: 2.0.28-beta release --coredumps
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Nov 13, 2001 at 03:07:00PM -0500, Jeff Trawick wrote:
> If you're starting httpd as root on Solaris, I don't think you're
> gonna get core dumps. End of story. (I'd be thrilled to be proven
> wrong!!! Please!!!!!!!). There is no sort of system control on
> Solaris to let a process that switched form uid=0 coredump.
man coreadm
% coreadm
global core file pattern: /coredumps/core.%f.%p
init core file pattern: /coredumps/init-core.%f.%p
global core dumps: enabled
per-process core dumps: enabled
global setid core dumps: enabled
per-process setid core dumps: enabled
global core dump logging: enabled
Anything and everything that coredumps gets captured. We get
a bunch of segfaults from nscd on Solaris 8. =) And, it captures
all of the setuid segfaults from httpd just fine. -- justin
Re: 2.0.28-beta release --coredumps
Posted by Jeff Trawick <tr...@attglobal.net>.
Ian Holsman <ia...@cnet.com> writes:
> On Tue, 2001-11-13 at 11:08, Justin Erenkrantz wrote:
> > On Tue, Nov 13, 2001 at 11:04:04AM -0800, Ian Holsman wrote:
> > > I'm getting a coredump with proxy & linux ;(
>
> Ok..
> no coredump with solaris.
If you're running with a threaded MPM, try my fix committed to
apr/threadproc/unix/signals.c yesterday to stop blocking synchronous
signals. That got coredumps to start working for me on Solaris 8
using worker MPM.
If you're starting httpd as root on Solaris, I don't think you're
gonna get core dumps. End of story. (I'd be thrilled to be proven
wrong!!! Please!!!!!!!). There is no sort of system control on
Solaris to let a process that switched form uid=0 coredump.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: 2.0.28-beta release --coredumps
Posted by Ian Holsman <ia...@cnet.com>.
On Tue, 2001-11-13 at 11:08, Justin Erenkrantz wrote:
> On Tue, Nov 13, 2001 at 11:04:04AM -0800, Ian Holsman wrote:
> > I'm getting a coredump with proxy & linux ;(
Ok..
no coredump with solaris.
but the page is still foobar.
1. it shows the headers
2. it shows the 2nd half of the page before the 1st part ;(
(tested against a r-proxy server running httpd2.26)
> >
> > Scenario:
> > R-proxy server BEA-Weblogic 5.1.0 Sp10
> >
> > <Location /x>
> > ProxyPass http://appserver
> > </Location>
> > </location /y>
> > ProxyPass http://appserver
> > </location>
>
> What if you do:
>
> <Location /x>
> ProxyPass http://appserver/
> </Location>
>
> or even:
>
> ProxyPass /x http://appserver/
>
> IIRC, the / is significant. We could beef up the URL parsing
> semantics though to make it more robust. -- justin
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 344-2608
Re: 2.0.28-beta release --coredumps
Posted by Ian Holsman <ia...@cnet.com>.
On Tue, 2001-11-13 at 11:08, Justin Erenkrantz wrote:
> On Tue, Nov 13, 2001 at 11:04:04AM -0800, Ian Holsman wrote:
> > I'm getting a coredump with proxy & linux ;(
> >
> > Scenario:
> > R-proxy server BEA-Weblogic 5.1.0 Sp10
> >
> > <Location /x>
> > ProxyPass http://appserver
> > </Location>
> > </location /y>
> > ProxyPass http://appserver
> > </location>
>
> What if you do:
>
> <Location /x>
> ProxyPass http://appserver/
> </Location>
>
my bad.. that is what I had (the trailing slash)
anyway..same result ;(
(Oh..) I also have
SetOutputFilter INCLUDES
in the main part of the config
> or even:
>
> ProxyPass /x http://appserver/
>
> IIRC, the / is significant. We could beef up the URL parsing
> semantics though to make it more robust. -- justin
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 344-2608
Re: 2.0.28-beta release --coredumps
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Nov 13, 2001 at 11:04:04AM -0800, Ian Holsman wrote:
> I'm getting a coredump with proxy & linux ;(
>
> Scenario:
> R-proxy server BEA-Weblogic 5.1.0 Sp10
>
> <Location /x>
> ProxyPass http://appserver
> </Location>
> </location /y>
> ProxyPass http://appserver
> </location>
What if you do:
<Location /x>
ProxyPass http://appserver/
</Location>
or even:
ProxyPass /x http://appserver/
IIRC, the / is significant. We could beef up the URL parsing
semantics though to make it more robust. -- justin
Re: 2.0.28-beta release --coredumps
Posted by Ian Holsman <ia...@cnet.com>.
I'm getting a coredump with proxy & linux ;(
Scenario:
R-proxy server BEA-Weblogic 5.1.0 Sp10
<Location /x>
ProxyPass http://appserver
</Location>
</location /y>
ProxyPass http://appserver
</location>
page is something like
<!--#include "/y/1.html">
1 2 3 4 ... (8k worth of crud)
doing a simple GET
I'll try to get a dump file on my solaris box.
(no idea why linux isn't giving me a core)
On Tue, 2001-11-13 at 10:28, Justin Erenkrantz wrote:
> I'm not sure what the policy is here (this is really up to Greg as
> RM), but if 2.0.28 makes it to beta (which I think it has with
> three +1s), can we add that patch that fixes the header filters
> with ap_die into the beta tarball (modules/http/http_request.c)?
>
> I know that we can't touch the 2.0.28-alpha tarball, but I seem
> to recall someone saying we could touch the next-level tarball
> (i.e. -beta).
>
> This would resolve a problem that has been fixed and a bunch
> of people have reviewed this (me, Ryan, and Cliff).
>
> Just a thought. -- justin
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 344-2608
Re: 2.0.28-beta release?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Tue, 13 Nov 2001, Justin Erenkrantz wrote:
> Wouldn't anything that calls ap_die be affected?
Possibly. I'd have to look into it more.
> I don't care much as the problem is fixed in HEAD, so at the
> very least, we can include the diff in the release notes.
+1.
> I'm not sure what the ErrorDocument 401 has to do with this, but
> I didn't really understand how to reproduce this bug. -- justin
One possible way (there may be others):
<Location />
AuthType Basic
AuthName "Some Pretty Cool Stuff"
AuthUserFile /tmp/blah
require user joe
</Location>
Then do a GET / HTTP/1.0 and you're hosed.
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.28-beta release?
Posted by sterling <st...@covalent.net>.
I can't think of another case - but there could be one.
The simplest way to produce this problem is just turn some kind of
auth on in <Location /> - then the 401 error document will be protected
and you will get an error within ap_die -
sterling
On Tue, 13 Nov 2001, Justin Erenkrantz wrote:
> On Tue, Nov 13, 2001 at 01:47:01PM -0500, Cliff Woolley wrote:
> > If we're willing to touch the tarball at all, a less obtrusive change
> > might be to just comment out the .html.var line for ErrorDocument 401 in
> > the default config file, which also fixes (works around) the problem (I
> > tested it). But I'm also willing to just document in the release notes
> > that if you want to use mod_auth, you need to comment that line out for
> > now.
>
> Wouldn't anything that calls ap_die be affected? Or, am I
> misunderstanding this bug?
>
> I don't care much as the problem is fixed in HEAD, so at the
> very least, we can include the diff in the release notes.
>
> I'm not sure what the ErrorDocument 401 has to do with this, but
> I didn't really understand how to reproduce this bug. -- justin
>
>
Re: 2.0.28-beta release?
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Nov 13, 2001 at 01:47:01PM -0500, Cliff Woolley wrote:
> If we're willing to touch the tarball at all, a less obtrusive change
> might be to just comment out the .html.var line for ErrorDocument 401 in
> the default config file, which also fixes (works around) the problem (I
> tested it). But I'm also willing to just document in the release notes
> that if you want to use mod_auth, you need to comment that line out for
> now.
Wouldn't anything that calls ap_die be affected? Or, am I
misunderstanding this bug?
I don't care much as the problem is fixed in HEAD, so at the
very least, we can include the diff in the release notes.
I'm not sure what the ErrorDocument 401 has to do with this, but
I didn't really understand how to reproduce this bug. -- justin
RE: 2.0.28-beta release?
Posted by Joshua Slive <jo...@slive.ca>.
> From: Cliff Woolley [mailto:cliffwoolley@yahoo.com]
> But I'm also willing to just document in the release notes
> that if you want to use mod_auth, you need to comment that line out for
> now.
+1
and +1 for beta.
Incidentally, I think I've turned around 180 degrees on having those
errordocs in by default. I think we should comment them out for GA release.
They have been great for catching bugs, but what we release as 2.0 gold
should have the simplest and safest configuration as its default.
Joshua.
Re: 2.0.28-beta release?
Posted by sterling <st...@covalent.net>.
You just need to comment out the 401 error document -
sterling
On Tue, 13 Nov 2001, Cliff Woolley wrote:
> On Tue, 13 Nov 2001, Justin Erenkrantz wrote:
>
> > I'm not sure what the policy is here (this is really up to Greg as
> > RM), but if 2.0.28 makes it to beta (which I think it has with
> > three +1s), can we add that patch that fixes the header filters
> > with ap_die into the beta tarball (modules/http/http_request.c)?
> >
> > I know that we can't touch the 2.0.28-alpha tarball, but I seem
> > to recall someone saying we could touch the next-level tarball
> > (i.e. -beta).
> >
> > This would resolve a problem that has been fixed and a bunch
> > of people have reviewed this (me, Ryan, and Cliff).
>
> If we're willing to touch the tarball at all, a less obtrusive change
> might be to just comment out the .html.var line for ErrorDocument 401 in
> the default config file, which also fixes (works around) the problem (I
> tested it). But I'm also willing to just document in the release notes
> that if you want to use mod_auth, you need to comment that line out for
> now.
>
> [PS: Do _all_ of the errordocument .html.var lines need to be commented
> out for the workaround to be effective? I didn't try any of the other
> errors, because I'd've expected httpd-test to fail miserably if any of the
> others besides 401 (and maybe 403) were affected by this, and it didn't.]
>
> --Cliff
>
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
>
>
>
Re: 2.0.28-beta release?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Tue, 13 Nov 2001, Justin Erenkrantz wrote:
> I'm not sure what the policy is here (this is really up to Greg as
> RM), but if 2.0.28 makes it to beta (which I think it has with
> three +1s), can we add that patch that fixes the header filters
> with ap_die into the beta tarball (modules/http/http_request.c)?
>
> I know that we can't touch the 2.0.28-alpha tarball, but I seem
> to recall someone saying we could touch the next-level tarball
> (i.e. -beta).
>
> This would resolve a problem that has been fixed and a bunch
> of people have reviewed this (me, Ryan, and Cliff).
If we're willing to touch the tarball at all, a less obtrusive change
might be to just comment out the .html.var line for ErrorDocument 401 in
the default config file, which also fixes (works around) the problem (I
tested it). But I'm also willing to just document in the release notes
that if you want to use mod_auth, you need to comment that line out for
now.
[PS: Do _all_ of the errordocument .html.var lines need to be commented
out for the workaround to be effective? I didn't try any of the other
errors, because I'd've expected httpd-test to fail miserably if any of the
others besides 401 (and maybe 403) were affected by this, and it didn't.]
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA