Re: 1.2b1 status

[Randy Terbush <ra...@zyzzyva.com>]

> 
> Randy, are you still up for rolling the tarball on Sunday ? The choice
> of when is up to you.

Yes. I'll do it Sunday CST.

> Once we have that, those of us not using CVS should grab it and everyone
> should install and test it (as much as you can). There are still outstanding
> bugs but it's useful if we all start from the same source for the last week
> of pre-beta testing and reporting.
> 
> 
> What will Sunaday's version be called ?. Does it matter ?   1.2b0 ?

1.2b1

I figure that if it flies (as beta quality) we release it? No?



> Features:
> 	-=-=-=-=-=-=
> 	Sameer has offered a patch to do unbuffered CGI.
> 	Ben has said he supports the feature.
> 
> 	-=-=-=-=-=-=-=
> 
> 	searching domains
> 
> 	lots of arguments on both sides. Brian suggests putting it in
> 	http://www.apache.org/dist/contrib/patches/1.2/   ... seems like
> 	the only option now.
> 
> 	-=-=-=-=-=-=-=-
> 
> 	Jason:
> 	  Whoops.  I missed the feature freeze...
> 	  I had an update for support/suexec.c
> 	  The changes were minor, and we *could* run with the current version.
> 	  However, here are the changes that were made:
> 
> 	   * Version 0.1.0 - Jason A. Dour
> 	   *    First beta.  Removed HAVE_RLIMIT and related rlimit code
> 	   * now that the server handles the functionality.  Moved user-
> 	   * defined code to suexec.h.  Added "DON'T EDIT" warning in code.
> 	   * No more "security by obscurity"...comments added at each step.
> 
> 	  For the most part, the biggest change was the *removal* of 
> 	  HAVE_RLIMIT.  Other than that, it's mostly comments and a
> 	  "DON'T EDIT" warning.  The user-definable variables have been
> 	  moved to suexec.h to keep people from editing the code.  IMHO,
> 	  suexec.c should not be writable by default in the tarball...
> 
> 	  Are there enough votes out there to commit these changes?
> 
> Bugs:
> 	-=-=-=-=--=-
> 	The logic of timeouts seems to be somewhat screwed - keepalive
> 	timeouts may be used at the wrong moments, it seems to me.  [Ben]
> 
> 	-=-=-==-=-=-
> 
> 	HPUX 10.x compile fix patch.
> 
> 	-=-=-=-=-=-=
> 
> bug?	"Apache logs (error_log) 'no acceptable variant' (406)) twice".
> 
> 	Sorry the initial claim is wrong in general, not sure if this is
> 	a bug or a feature [robh] 
> 
> 	DirectoryIndex index.html index.forward
> 	Multiviews switched on
> 	files: index.html.en index.html.de index.forward
> 	browser set to accept say "fr".
> 
> 	before index.forward (an .asis file) internally redirects the
> 	request to index.html a 'no acceptable variant' is logged,
> 	it is logged again when index.html fails to find an
> 	acceptable language.
> 
> 	So what is apache looking for before the internal redirect from the
> 	.asis ?   If I remove index.forward from the equation, I get 1
> 	logged message plus a directory listing and a 200 response (yuck)
> 
> 	-=-=-=-=-=-
> 
> 	From: Roy
> 	The problem is that a request on /dir/ is internally redirected to
> 	/dir/index.html, which properly results in a 304 Not Modified.  However,
> 	the r->status is not updated to reflect new->status (and anything else
> 	that might need to be promoted).
> 
> 	we're still waiting for someone to speak up on whether it's a
> 	major problem or not.  I don't know that area of the code well
> 	enough, though I can't say that promotion of error code from
> 	sub-redirects has been a problem for me personally.  Again, flag
> 	it as a known bug is probably the best we can
> 	do here, unless someone wants to speak up.  [brian]
> 
> 	-=-=-=-=-=-=-=-=
> 
> 	1.2-dev still has this bug in it.  get_client_block needs to
> 	check for the -1 error case from the call to bread().
> 
> 	patch offered. positive feedback so far.
> 
> 	-=-=-=-=-=-=-=-=-
> 
> 	Roy's claim of CGI schitzo behavior and improper dealing with
> 	CONTENT_LENGTH.  This is a showstopper in my opinion until more
> 	voices are heard.
> 
> 	Roy offers 2 options:
> 	  a) Assume it is only for old scripts.  This requires changing mod_cgi
> 	    so that it rejects anything without a Content-Length (411 Length
> 	    Required) even if it is chunked, or at least anything that cannot
>             be read into a single buffer before execing the script.
> 
>           b) Assume it is for new scripts and that old scripts will just never
> 	    see the HTTP/1.1 input (after all, no sane client would chunk an
> 	    x-www-url-encoded form).  This requires changing get_client_block
> 	    so that it passes the chunk size and footer to the script. 
> 
> 	Jim voted for (b)
> 	Ed  voted for (a) 
> 
> 	Alexei says it's supposed to be this way.
> 
> 	+ other comments.
> 
> 
> Showstoppers (perhaps):
> 
> 	Roy's redirect bug, though he seems to be having 2nd thoughts now,
> 	probably not a showstopper.
> 
> 	?  get_client_block needs to check for the -1  (sounds nasty)
> 
> 	CGI dealing & CONTENT_LENGTH
> 
> 
> TODO:
> 
> 	now
> 		Prepare more documentation.
> 		Resolve all outstanding bugs (see above).
> 	Nov 24	Create last pre-beta tarball (Randy?)
> 		Test, test, test.
> 		Report back with positive as well as negative comments.
> 	Nov 30	Create 1.2b1 tarball.
> 	  "	Update CVS to reflect 1.2b1 release.
> 	Dec  1  Release 1.2b1.
> 	  "	Put documentation online if there is any.
> 	  "	Hand 1.2 management over.
> 

Re: 1.2b1 status

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

On Sat, 23 Nov 1996, Randy Terbush wrote:

> > What will Sunaday's version be called ?. Does it matter ?   1.2b0 ?
> 
> 1.2b1
> 
> I figure that if it flies (as beta quality) we release it? No?

Yes, but what if it doesn't? Then what do we call the one we release?
1.2b2? That just confuses people. 1.2b1? That just confuses *us*. I
imagine this as possibly a late alpha release, such as 1.2a1, or an
early beta release, 1.2b0 (what we did for 1.0 - we didn't do
something like this for 1.1, which is possibly why we had to release a
1.1.1 the next day - although we didn't have CVS, was to call it
1.0b0, then 1.0b0a, then 1.1b0b, and so forth).


-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/