Mailing List Archive

Issues for a beta release...
Apache 0.5.1 seems to be a reasonably stable piece of software, and if
we were working in isolation, it would be a fairly strong candidate
for beta 1. However, we aren't working in isolation, so a few issues
come up, if we're actually going to do that in the next few days,
mostly regarding how we relate to NCSA 1.4 (which may also be released
in pretty much the same time frame).

1) The whole forking/non-forking thing. As a side project, mention of
which has shown up here from time to time, I've been working on
integrating the non-forking stuff from NCSA 1.4 (basically, their
httpd.c) with Apache.

Our current nameserver cache has to go, unfortunately (it relies on
each process being handled by a new child which inherits a recent
copy of the parent's memory), but the rest of the code seems to
work OK. I've actually been running a non-forking Apache
configuration since Sunday, and aside from one untoward incident
when it ran out of file descriptors on a restart (since fixed), it
has given me no trouble --- in particular, I haven't seen the
mysterious core dumps which have been reported for the real 1.4.

(FWIW, Rob H. has reported a ~60-byte per transaction memory leak
in my non-forking Apache; however, when he tried to duplicate this
with the real 1.4, it blew up completely after fifty-odd requests.
Brandon --- you might want to look at this; it's a bit more serious
than the garden-variety memory leak Rob advertised it as when he
submitted the report).

Our options, as I see them ---

a) release a non-forking thing now, with promise of a forking
server to come "soon after NCSA releases 1.4".

b) wait until NCSA releases 1.4, and then release our code

Personally, I wouldn't feel comfortable releasing the forking code
yet --- for one thing, it would feel odd to be releasing 1.4 code
to the general public before they do (although it would be labeled
beta in both cases). However, it's possible that reasonable people
will disagree.

(Besides, I'd feel a bit more comfortable with letting it loose on
the general public if it had run on at least one fairly busy server
other than mine; either HotWired or Cardiff would be nice...).

2) Compatibility. Current versions (i.e., the *most* recent betas) of
1.4 have the following features which we *don't* support, or do
differently. Our current draft public docs page says we expect to
be plug-compatible with 1.4, so we have to deal with the following
somehow:

a) Some of the script variables we now both set on error redirects
have different names (ERROR_foo vs. REDIRECT_foo --- we have the
latter names because we set them as well when a script redirects
to another local script).

b) RefererLog, UserAgentLog --- I don't think these are a terribly
good idea, but if we really want to be plug compatible with 1.4,
we're stuck with them.

c) There's (experimental?) support for group annotation of some
sort --- so far, it seems to consist only of having an
annotation server named in the config files, and jamming its URL
into the MIME headers on returned documents. We may not even
want to support this until it's documented and stabilized, but
it's there.

Hope I haven't missed anything...

3) I really would like the APB code in our first public release.
(NB this may involve nontrivial coding --- most of my code looks
pretty much like, well, Apache, but httpd.c is taken more or less
from 1.4, and looks rather different. I think there is a 1.4
version of the APB patches out there, which might help adapting
it).

4) It would also be nice to do something about getting the nameserver
cache back in to the non-forking code, for when we release it,
whenever that is. I do have my old shared-memory code, which I've
since dinked a bit to be more portable, but I haven't had time to
test the revised version.

Any thoughts from anyone would be appreciated...

rst
Re: Issues for a beta release... [ In reply to ]
Rob T's ">"ed comments...

> a) release a non-forking thing now, with promise of a forking
> server to come "soon after NCSA releases 1.4".
>
> b) wait until NCSA releases 1.4, and then release our code

(a) is good for me. I'd like to see what impact non-forking has
on the Cardiff server first. That server has a nice spread of
httpd activities, as well as being close to it's maximum throughput
for long periods during the day.

I'll ask Robert Evans at Cardiff if he'd be willing to plug it. I think
he will, he knows it's in the pipeline.

> a) Some of the script variables we now both set on error redirects
> have different names (ERROR_foo vs. REDIRECT_foo --- we have the
> latter names because we set them as well when a script redirects
> to another local script).

I gave Brandon some info on this. He missed the thread in which
the reasons were given for the use of "REDIRECT_". We might be able
to converge on some agreed syntax.

> b) RefererLog, UserAgentLog --- I don't think these are a terribly
> good idea, but if we really want to be plug compatible with 1.4,
> we're stuck with them.

At worst we can look for them and warn the user they are being ignored.

> c) There's (experimental?) support for group annotation of some
> sort --- so far, it seems to consist only of having an
> annotation server named in the config files, and jamming its URL
> into the MIME headers on returned documents. We may not even
> want to support this until it's documented and stabilized, but
> it's there.

The old type of annotation system won't scale.
I don't think we should get involved in this unless we have to.

> 3) I really would like the APB code in our first public release.

whether or not it's had enough of a testing from us, I think we
should agree to bend the rules to let beta testers try it out.


robh
Re: Issues for a beta release... (NCSA PLEASE READ) [ In reply to ]
On Tue, 11 Apr 1995, Robert S. Thau wrote:
> Our options, as I see them ---
>
> a) release a non-forking thing now, with promise of a forking
> server to come "soon after NCSA releases 1.4".
>
> b) wait until NCSA releases 1.4, and then release our code

I would vote for a non-forking beta release, and then when we've got the
no-forking mechanism down pat (tested on a wide variety of platforms,
recoded to do a MP accept() model instead of serializing them, etc)
release that.

> Personally, I wouldn't feel comfortable releasing the forking code
> yet --- for one thing, it would feel odd to be releasing 1.4 code
> to the general public before they do (although it would be labeled
> beta in both cases). However, it's possible that reasonable people
> will disagree.

This is an intersting situation, and I hope someone from NCSA can respond
(hence my change to the subject line). Since our licenses are still very
similar, I think they have as much right to use *our* code as we do
*their*s, so I can't see how they would see this situation as anything
but collaborative. My opinion is that we shouldn't release anything with
the non-forking code until at least we hear back from them, but this is
based more on professional courtesy than any legal reason (NB: I'm not a
lawyer, etc etc...) (BTW, what does NB stand for?)

> (Besides, I'd feel a bit more comfortable with letting it loose on
> the general public if it had run on at least one fairly busy server
> other than mine; either HotWired or Cardiff would be nice...).

I can't promise anything, as this is my last week here, but I will *try*
and get a test run of the non-forking on hotwired before the end of the
week.

> 2) Compatibility. Current versions (i.e., the *most* recent betas) of
> 1.4 have the following features which we *don't* support, or do
> differently. Our current draft public docs page says we expect to
> be plug-compatible with 1.4, so we have to deal with the following
> somehow:
>
> a) Some of the script variables we now both set on error redirects
> have different names (ERROR_foo vs. REDIRECT_foo --- we have the
> latter names because we set them as well when a script redirects
> to another local script).

This local redirecting is still done through custom error messages
though, yes? So "ERROR_" might not be a bad name. I didn't realise when
I voted in favor of "REDIRECT_" that 1.4 had chosen the other way.... I
think semantically the first is more correct.

> b) RefererLog, UserAgentLog --- I don't think these are a terribly
> good idea, but if we really want to be plug compatible with 1.4,
> we're stuck with them.

Not hard to implement though. Compile-time option that's always set by
default?

> c) There's (experimental?) support for group annotation of some
> sort --- so far, it seems to consist only of having an
> annotation server named in the config files, and jamming its URL
> into the MIME headers on returned documents. We may not even
> want to support this until it's documented and stabilized, but
> it's there.

This, and b), could be labeled as "experimental" if we wished and not
supported. While we *must* be compatible with 1.3 (if for any other
reason so people can still use hoohoo.ncsa.uiuc.edu as documentation for
apache) I don't necessarily agree that we must be compatible with 1.4.
1.4 is much more a departure from its antecedent than 1.3 or even 1.2
was, so a lot of its "features" may get revamped in short order....

> 3) I really would like the APB code in our first public release.
> (NB this may involve nontrivial coding --- most of my code looks
> pretty much like, well, Apache, but httpd.c is taken more or less
> from 1.4, and looks rather different. I think there is a 1.4
> version of the APB patches out there, which might help adapting
> it).

The multi-host code? Yes, I definitely agree, we need it in our first
release. I already gave it a +1, and while it is true that I haven't
personally taken it and tested it, my vote of +1 is along the lines of
"I trust Cliff and Randy enough that if they have tested it sufficiently
to put their name on it, I believe them". I have seen the version of
this patched against 1.3 work for 3 months on www.organic.com (try
http://www.saturncars.com/) - I can't test that it works myself since
neither hotwired nor hyperreal are using that feature (which involves
setting up a second ethernet interface, and I don't know how to do that
on SGI's and I don't have spare IP numbers to do this on hyperreal.)
The most I can do is compile it on different platforms - if that works
and Cliff and Randy can absolutely verify its functionality let's do it.

Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/
Re: Issues for a beta release... [ In reply to ]
The single BIGGEST issue, in my mind, for a proper release is

<font size=12>DOCUMENTATION</font>

We simply have to have the /apache/ directory in top shape or no one's
going to take it seriously, or worse, all of us are going to get a flood
of email about how-to-do-this-or-that. We should point people to
hoohoo.ncsa when appropriate, but given that there could be
incompatibilities with 1.4 (custom logging and group annotation support
for example), we might have to do a lot of our own documentation for 1.3
features.

I know Randy has been doing a lot with the web pages, but I think
everyone should help by documenting the patches they've contributed.
Hopefully Randy can captain it from here and delegate other chores - even
with the time crunch this week I can help out.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/
Re: Issues for a beta release... [ In reply to ]
> I know Randy has been doing a lot with the web pages, but I think
> everyone should help by documenting the patches they've contributed.
> Hopefully Randy can captain it from here and delegate other chores - even
> with the time crunch this week I can help out.

The issue I kind of stopped with was "are we going to maintain a mail list"?
I can clean the mechanics of things up rather quickly once we make
that a final decision. I think a link to news:c.i.w.p is adequate,
but think that the mailing list is something that will need to be
done in the future.
Re: Issues for a beta release... (NCSA PLEASE READ) [ In reply to ]
> based more on professional courtesy than any legal reason (NB: I'm not a
> lawyer, etc etc...) (BTW, what does NB stand for?)

nota bene - observe well or note well.
Re: Issues for a beta release... [ In reply to ]
> The single BIGGEST issue, in my mind, for a proper release is
>
> <font size=12>DOCUMENTATION</font>

An idea that just occured to me as that since Apache is a collaborative
effort with anyone free to contribute, why not ask for help in
documenting all of Apache - httpd 1.3isms included.

So we could set up a list of topics that need to be documented, then
sit back and wait for people to join in :-)

It'll need some tidying up, but that's easier than writing stuff
from scratch. We could suggest a syntax/style for people to follow.

This could be their optional means of paying for Apache.

robh
Re: Issues for a beta release... [ In reply to ]
On Tue, 11 Apr 1995, Rob Hartill wrote:
> > The issue I kind of stopped with was "are we going to maintain a mail list"?
> > I can clean the mechanics of things up rather quickly once we make
> > that a final decision. I think a link to news:c.i.w.p is adequate,
> > but think that the mailing list is something that will need to be
> > done in the future.
>
> Can we just have a bugs@apache.org and suggestions@apache.org, both
> mapped to the same place ? either a private hypernews archive or
> directly to those willing to read and sometimes respond to the mail.

Again, the common-mailbox-on-hyperreal method would work best. I'll set
it up if I don't hear complaints within the next 24 hours - true, it
would only mean that those with hyperreal accounts can answer that mail,
but if you're serious enough about apache development that this is
something you're willing to do, I'm certainly willing to give you an
account to help out.

As for a public support "mailing list" - I oppose it on the basis of sheer
overload (too many subscribers, lots of bogus traffic), something that would
be much better dealt with in c.i.w.p or through direct mail. However, as
a compromise I will support setting up a moderated "apache-announcements"
list that apache users can subscribe to, and one of us posts to on a
semi-regular basis to keep people informed of the project and such.
And Randy, I know you offered to host a list like that, but I just have
the feeling it's a lot more work than you want to do (and more load than
you may want to put on one of your machines) to support a fully public
apache-support list. The traffic will probably be such that I won't read
it - I can barely keep up with new-httpd and still respond
intelligently. :)

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/
Re: Issues for a beta release... [ In reply to ]
> The issue I kind of stopped with was "are we going to maintain a mail list"?
> I can clean the mechanics of things up rather quickly once we make
> that a final decision. I think a link to news:c.i.w.p is adequate,
> but think that the mailing list is something that will need to be
> done in the future.

Can we just have a bugs@apache.org and suggestions@apache.org, both
mapped to the same place ? either a private hypernews archive or
directly to those willing to read and sometimes respond to the mail.

Replies to bugs and suggestions could be Cc'ed to the readers
of those addresses, thus warning everyone that the mail has been
processed. Most will be "Thank you, we will investigate this
ASAP" replies I hope.

Any other type of user feedback is fair game for c.i.w.providers, and
will, with a bit of luck, be snapped up by someone other than us, thus
saving us time.
Re: Issues for a beta release... [ In reply to ]
> Again, the common-mailbox-on-hyperreal method would work best. I'll set
> it up if I don't hear complaints within the next 24 hours - true, it
> would only mean that those with hyperreal accounts can answer that mail,
> but if you're serious enough about apache development that this is
> something you're willing to do, I'm certainly willing to give you an
> account to help out.

Works for me. Tell me what the account name is.

> As for a public support "mailing list" - I oppose it on the basis of sheer
> overload (too many subscribers, lots of bogus traffic), something that would
> be much better dealt with in c.i.w.p or through direct mail. However, as
> a compromise I will support setting up a moderated "apache-announcements"
> list that apache users can subscribe to, and one of us posts to on a
> semi-regular basis to keep people informed of the project and such.
> And Randy, I know you offered to host a list like that, but I just have
> the feeling it's a lot more work than you want to do (and more load than
> you may want to put on one of your machines) to support a fully public
> apache-support list. The traffic will probably be such that I won't read
> it - I can barely keep up with new-httpd and still respond
> intelligently. :)

I think you are correct. I'm bowing out on that offer.
Re: Issues for a beta release... (NCSA PLEASE READ) [ In reply to ]
Last time, Brian Behlendorf uttered the following other thing:
>
> On Tue, 11 Apr 1995, Robert S. Thau wrote:
> > Our options, as I see them ---
> >
> > a) release a non-forking thing now, with promise of a forking
> > server to come "soon after NCSA releases 1.4".
> >
> > b) wait until NCSA releases 1.4, and then release our code
>
> I would vote for a non-forking beta release, and then when we've got the
> no-forking mechanism down pat (tested on a wide variety of platforms,
> recoded to do a MP accept() model instead of serializing them, etc)
> release that.

I'd love to borrow that, if you get it working. It wasn't until after I'd
implemented the other that I thought about forking before the accept (I
just assumed it couldn't be done, show's what I know.) I was thinking of
trying something like have 5 servers with 5 children each, and wonder how that
would handle things, but I also hadn't considered the scheduling problem.
All I know is that the main problem I have with Netsite users is if the
number of servers is set too low, you get a very intolerable delay before you
get ANY response from the server at all. (I'm also assuming this can be fixed
by setting the number of servers higher).

Our webmaster (of www.ncsa) did some performance monitoring of 1.4 and
thought that the new approach didn't help that much, but I've noticed
it helps quite a bit on certain platforms, and may be more due to not the
speed at which they handle transactions but the fact they can handle the
transactions (a HP 715/50 at 15 transactions/second with 20 servers has
an uptime of .5 to 1.5, but is missing very few transactions, where as
with fewer servers, or none at all, the uptime skyrockets to 11 or so, and
it misses most of the transactions)

Sorry, I guess I'm trying to prove that it helps, at least as well as I can
tell. I'd also hate to see netsite on hoohoo, where we have this annoying
script that does an archie, and holds up a server until its done. Of course,
I don't know enough about the netsite model, they might just let the scripts
go (sorta like nph scripts) instead of hanging a server on it (yes, we know
the script should be nph, but it helped find a deficiency in 1.4, so we left
it)

> > Personally, I wouldn't feel comfortable releasing the forking code
> > yet --- for one thing, it would feel odd to be releasing 1.4 code
> > to the general public before they do (although it would be labeled
> > beta in both cases). However, it's possible that reasonable people
> > will disagree.

I hope to release the 1.4 (either general beta or for real) next week, but
I have this little thing called class (oh, and Easter too). If I can find
the problem that Rob had with 58 reloads killing the server, it should be
ready.

> This is an intersting situation, and I hope someone from NCSA can respond
> (hence my change to the subject line). Since our licenses are still very
> similar, I think they have as much right to use *our* code as we do
> *their*s, so I can't see how they would see this situation as anything
> but collaborative. My opinion is that we shouldn't release anything with
> the non-forking code until at least we hear back from them, but this is
> based more on professional courtesy than any legal reason (NB: I'm not a
> lawyer, etc etc...) (BTW, what does NB stand for?)

You're welcome to do what you will. I have no problem if you beat us to the
punch, after all, we didn't do anything for how many months? I think I've
mentioned before that give it a couple more months, and I expect Apache
to take over the position of httpd (except maybe for those who need free
support/hand holding which I'm sure you all don't wish to provide)

> > 2) Compatibility. Current versions (i.e., the *most* recent betas) of
> > 1.4 have the following features which we *don't* support, or do
> > differently. Our current draft public docs page says we expect to
> > be plug-compatible with 1.4, so we have to deal with the following
> > somehow:
> >
> > a) Some of the script variables we now both set on error redirects
> > have different names (ERROR_foo vs. REDIRECT_foo --- we have the
> > latter names because we set them as well when a script redirects
> > to another local script).
>
> This local redirecting is still done through custom error messages
> though, yes? So "ERROR_" might not be a bad name. I didn't realise when
> I voted in favor of "REDIRECT_" that 1.4 had chosen the other way.... I
> think semantically the first is more correct.

We can very easily (er, I think) add these variables to local redirects as
well. Right now, I just did it the easy way (I copy them in die, before
the error message is called) but I could do it in process request, and
the just set a flag to actually send them to the script.

> > b) RefererLog, UserAgentLog --- I don't think these are a terribly
> > good idea, but if we really want to be plug compatible with 1.4,
> > we're stuck with them.
>
> Not hard to implement though. Compile-time option that's always set by
> default?

We need CLF II, obviously. These logs are only of minimal use, as is. I find
it kind of interesting to view the referer log, but the UserAgentLog is next
to useless (unless you care which browser is "winning"). With the addition
of the referer information to the error_log on access denied, its about all
that's needed for most people.

> > c) There's (experimental?) support for group annotation of some
> > sort --- so far, it seems to consist only of having an
> > annotation server named in the config files, and jamming its URL
> > into the MIME headers on returned documents. We may not even
> > want to support this until it's documented and stabilized, but
> > it's there.
>
> This, and b), could be labeled as "experimental" if we wished and not
> supported. While we *must* be compatible with 1.3 (if for any other
> reason so people can still use hoohoo.ncsa.uiuc.edu as documentation for
> apache) I don't necessarily agree that we must be compatible with 1.4.
> 1.4 is much more a departure from its antecedent than 1.3 or even 1.2
> was, so a lot of its "features" may get revamped in short order....

Basically, this was added now for the conference in Germany, but my feeling
is that its probably changed from the last version. I believe there now
exists a annotation server of some sort, but I'm not really up-to-date on
the whole thing (one of the other developers is handling that)

As for the next version, I think it will be a security release, with
support (hopefully) for digest authentication, maybe kerberos (they're still
working out the whole mess of export), maybe some other stuff (there isn't
an SSL server library, but that's another can of worms entirely)

> > 3) I really would like the APB code in our first public release.
> > (NB this may involve nontrivial coding --- most of my code looks
> > pretty much like, well, Apache, but httpd.c is taken more or less
> > from 1.4, and looks rather different. I think there is a 1.4
> > version of the APB patches out there, which might help adapting
> > it).
>
> The multi-host code? Yes, I definitely agree, we need it in our first
> release. I already gave it a +1, and while it is true that I haven't
> personally taken it and tested it, my vote of +1 is along the lines of
> "I trust Cliff and Randy enough that if they have tested it sufficiently
> to put their name on it, I believe them". I have seen the version of
> this patched against 1.3 work for 3 months on www.organic.com (try
> http://www.saturncars.com/) - I can't test that it works myself since
> neither hotwired nor hyperreal are using that feature (which involves
> setting up a second ethernet interface, and I don't know how to do that
> on SGI's and I don't have spare IP numbers to do this on hyperreal.)
> The most I can do is compile it on different platforms - if that works
> and Cliff and Randy can absolutely verify its functionality let's do it.

Someone has been shouting at us to include this in 1.4, but it was a little
late in the development cycle, and I have nothing to test it on locally.
(Or time to learn how to get it on, I guess). I might include it either
in a separate patch directory, or else as #defines, but I wouldn't bet on
it. Supposedly it patched into 1.4 with relative ease, but I haven't looked
personally.

By the way Rob, which machine (OS) did you run into that problem on (the 58
reloads), so I can start somewhere, or which access denied message appeared
in the error_log (was it always the same?) On 1.4b3-3, I did 657 reloads of
the same page from Solaris 2.4 and couldn't reproduce any problems last week,
(Well, ok, 1.4b4pre, or some such). Did you try moving the csd variable as
suggested?

Brandon

--
Brandon Long (N9WUC) "I think, therefore, I am confused." -- RAW
Computer Engineering Run Linux 1.1.xxx It's that Easy.
University of Illinois blong@uiuc.edu http://www.uiuc.edu/ph/www/blong
Don't worry, these aren't even my views.
Re: Issues for a beta release... [ In reply to ]
Hi, everybody!
> 1) The whole forking/non-forking thing. As a side project, mention of
> which has shown up here from time to time, I've been working on
> integrating the non-forking stuff from NCSA 1.4 (basically, their
> httpd.c) with Apache.
What I really would love to see implemented in WWW server is
multithreaded model. I wonder if you have ever considered this? I
realize that it restricts the variety of platforms you can run it at,
but it shall provide real performance boost on those selected
platforms. And one can do much more magic with cashing things, for
example one can cash web pages' mmaps and let kernel do "unplugged"
page-ins. I also realize it may require major recoding to make every
single procedure reentrant, but this won't hurt non-threaded platforms.
Has anyone got any idea on how much of the current code is reentrant?
Was it design goal from the beginning or none ever paid any attention to
it?
>
> Our current nameserver cache has to go, unfortunately (it relies on
> each process being handled by a new child which inherits a recent
> copy of the parent's memory), but the rest of the code seems to
> work OK.
I wonder if I can look at changes you've made. Or how do I get NCSA 1.4
if it's not possible?
>
> 3) I really would like the APB code in our first public release.
What's APB?
> (NB this may involve nontrivial coding --- most of my code looks
> pretty much like, well, Apache, but httpd.c is taken more or less
> from 1.4, and looks rather different. I think there is a 1.4
> version of the APB patches out there, which might help adapting
> it).

Andy.
Re: Issues for a beta release... (NCSA PLEASE READ) [ In reply to ]
> By the way Rob, which machine (OS) did you run into that problem on (the 58
> reloads), so I can start somewhere, or which access denied message appeared
> in the error_log (was it always the same?) On 1.4b3-3, I did 657 reloads of
> the same page from Solaris 2.4 and couldn't reproduce any problems last week,
> (Well, ok, 1.4b4pre, or some such). Did you try moving the csd variable as
> suggested?

HP 712/80 running HPsUX, compiled with gcc.

[Tue Apr 11 14:56:21 1995] httpd: authorization required for /usr/local/httpd/ht
docs/ but not configured
[Tue Apr 11 14:56:22 1995] httpd: authorization required for /usr/local/httpd/ht
docs/ but not configured
[Tue Apr 11 14:56:24 1995] httpd: authorization required for /usr/local/httpd/ht
docs/ but not configured
[Tue Apr 11 14:56:25 1995] httpd: authorization required for /usr/local/httpd/ht
docs/ but not configured


"csd" ? I never saw that suggestion.

You might want to consider mailing people who report bugs, directly.
I hope Apache doesn't get into a position where people have to
poll a URL to check for answers.

I'll have to hotlist the NCSA problem page one of these days.
Re: Issues for a beta release... [ In reply to ]
> Our options, as I see them ---
>
> a) release a non-forking thing now, with promise of a forking
> server to come "soon after NCSA releases 1.4".
>
> b) wait until NCSA releases 1.4, and then release our code

I would go for option b).

I don't see any advantage in rushing out a non-forking server. Apache 0.5.1
is quite competetive already. The code needs changing in a lot of areas, and
I'd rather these were done slowly, rather than all in one go.
Also, I'm not sure the NCSA approach is the best way to go.
Finally, I have yet to be convinced that a reliable non-forking deamon
can ever use malloc for per-connection data. (Except in a very limited,
alloca()-like manner.) Otherwise, how do you prove that garbage does not
build up?


>2) Compatibility. Current versions (i.e., the *most* recent betas) of
> 1.4 have the following features which we *don't* support, or do
> differently. Our current draft public docs page says we expect to
> be plug-compatible with 1.4, so we have to deal with the following
> somehow:

I don't think we need be compatible with 1.4, only 1.3.

David.
Re: Issues for a beta release... [ In reply to ]
This is a semi-official response to your issues relating
to the NCSA httpd (semi because I periodically get overruled
by Joseph).

<I've cut only the relevant comments from rst's msg)
> From: rst@ai.mit.edu (Robert S. Thau)
> Date: Tue, 11 Apr 95 18:15:25 EDT
> To: new-httpd@hyperreal.com
> Subject: Issues for a beta release...
>
> NCSA 1.4 (which may also be released
> in pretty much the same time frame).

We had hoped to release 1.4 this week in time for the Web conference
in Germany. Unfortunately things didn't work out that way. Right
now we're looking at next week.

> 2) Compatibility. Current versions (i.e., the *most* recent betas) of
> 1.4 have the following features which we *don't* support, or do
> differently. Our current draft public docs page says we expect to
> be plug-compatible with 1.4, so we have to deal with the following
> somehow:
>
> b) RefererLog, UserAgentLog --- I don't think these are a terribly
> good idea, but if we really want to be plug compatible with 1.4,
> we're stuck with them.

The RefererLog and UserAgentLog have been heavily requested by
groups trying to find ways to organize the information on the
Web. There are several research groups working on building
maps of to and from links and studying the way people use the web.
They need refer and user agent information. I urge you to support
some form of this.

In 1.5 we're going to revisit the configuration and format of these
log files. I plan on setting up a HyperNews page for discussion of
this and other 1.5 feature requests/changes as soon and 1.4 is
officially released. I'll post an announcement about the page to
this mailing list when it is available.

If you have better ideas on a format for this information we'd like
to hear them.

> c) There's (experimental?) support for group annotation of some
> sort --- so far, it seems to consist only of having an
> annotation server named in the config files, and jamming its URL
> into the MIME headers on returned documents. We may not even
> want to support this until it's documented and stabilized, but
> it's there.

Yes, it's experimental. I'm not even sure this is going to be an
advertised feature. It was required for a demo at the Web Conference
in Germany this week, so we added it to the beta. It may be in your
interest to wait and add this as a patch later once all the details
are finalized here.

> 3) I really would like the APB code in our first public release.

NCSA will not be supporting this in Release 1.4. We aren't sure
whether or not we'll be supporting this in 1.5.

Elizabeth Frank
efrank@ncsa.uiuc.edu
Re: Issues for a beta release... (NCSA PLEASE READ) [ In reply to ]
On Wed, 12 Apr 1995, Beth Frank wrote:
> Note on the documentation... it is going to be moving when the 1.4
> official docs are available. The 1.3 docs will remain only as long as
> we have 1.3 binaries available on the ftp server (which will probably
> be for a long time.). Just don't count on us keeping the documentation
> around forever. It should be easy enough to give copies of our old
> documentation to you if/when we decide to delete it, if you still need
> them.

Okay, cool. Ideally we can set up our documentation to point to enough
of your documentation on hoohoo to make the point that these servers are
still quite similar in configuration and set up, but at some point we may
diverge to the point where that dosn't make sense. But I don't see that
happening until Apache 2.0 or NCSA httpd 2.0, whichever comes first :)

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/
Re: Issues for a beta release... [ In reply to ]
On Wed, 12 Apr 1995, Beth Frank wrote, quoting Brandon:
> > As for the next version, I think it will be a security release, with
> > support (hopefully) for digest authentication, maybe kerberos (they're still
> > working out the whole mess of export), maybe some other stuff (there isn't
> > an SSL server library, but that's another can of worms entirely)
>
> I'm fairly sure digest authentication is in, Kerberos support of
> authentication is in, Kerberos support of encryption and bulk encryption
> depend on legal issues which need to be resolved, SSL support will
> only be included if the powers that be force us to...
> (As my arm is being twisted... "No, no, no, SSL is the wrong way
> to do it..." :^)

What about S-HTTP, with hooks to either/both PGP or Terisa's libshttp?
Isn't that the long term solution everyone should be working towards?

Digest authentication is definitely needed - Eric at Spyglass gave us a
reference here to code he's written for NCSA's httpd that does that plus
the proposed HTTP extension mechanism (roy - is that a part of the 1.1
proposal?), which can be found at
<URL:http://www.ics.uci.edu/pub/ietf/http/draft-kristol-http-extensions-00.txt>.

I'd support your nonsupport of SSL :)

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/
Re: Issues for a beta release... (NCSA PLEASE READ) [ In reply to ]
> From owner-new-httpd@hyperreal.com Tue Apr 11 19:03:25 1995
> From: Brian Behlendorf <brian@wired.com>
> To: new-httpd@hyperreal.com
> Cc: new-httpd@hyperreal.com
> Subject: Re: Issues for a beta release... (NCSA PLEASE READ)
>
> This is an intersting situation, and I hope someone from NCSA can respond
> (hence my change to the subject line). Since our licenses are still very
> similar, I think they have as much right to use *our* code as we do
> *their*s, so I can't see how they would see this situation as anything
> but collaborative. My opinion is that we shouldn't release anything with
> the non-forking code until at least we hear back from them, but this is
> based more on professional courtesy than any legal reason (NB: I'm not a
> lawyer, etc etc...) (BTW, what does NB stand for?)

I'm bringing this to the attention of the powers that be. (Sorry, I
don't get to make decisions about copyright :^) I may not be able to
have an answer for you until next week. (Vacation time...)

RE: ERROR_ vs. REDIRECT_
Brandon has the final word on this issue. If you can convince him
it needs to be changed. OK... PROVIDED it happens BEFORE the Beta
test period ends. Once it goes out in the official release we are
NOT changing the names.

> . While we *must* be compatible with 1.3 (if for any other
> reason so people can still use hoohoo.ncsa.uiuc.edu as documentation for
> apache) I don't necessarily agree that we must be compatible with 1.4.
> 1.4 is much more a departure from its antecedent than 1.3 or even 1.2
> was, so a lot of its "features" may get revamped in short order....

Note on the documentation... it is going to be moving when the 1.4
official docs are available. The 1.3 docs will remain only as long as
we have 1.3 binaries available on the ftp server (which will probably
be for a long time.). Just don't count on us keeping the documentation
around forever. It should be easy enough to give copies of our old
documentation to you if/when we decide to delete it, if you still need
them.

Elizabeth Frank
efrank@ncsa.uiuc.edu
Re: Issues for a beta release... (NCSA PLEASE READ) [ In reply to ]
> From owner-new-httpd@hyperreal.com Tue Apr 11 22:50:33 1995
> Subject: Re: Issues for a beta release... (NCSA PLEASE READ)
> To: new-httpd@hyperreal.com
> Date: Tue, 11 Apr 1995 22:54:10 -0500 (CDT)
> From: Brandon Long <blong@uiuc.edu>
>
> I hope to release the 1.4 (either general beta or for real) next week

Uh, Brandon - it IS in general beta. The only restriction on who
can pick up a copy of the beta is that they let us know who they are
(ie register). We don't even check to see if they are lying about
their Email address.

> As for the next version, I think it will be a security release, with
> support (hopefully) for digest authentication, maybe kerberos (they're still
> working out the whole mess of export), maybe some other stuff (there isn't
> an SSL server library, but that's another can of worms entirely)

I'm fairly sure digest authentication is in, Kerberos support of
authentication is in, Kerberos support of encryption and bulk encryption
depend on legal issues which need to be resolved, SSL support will
only be included if the powers that be force us to...
(As my arm is being twisted... "No, no, no, SSL is the wrong way
to do it..." :^)

Elizabeth Frank
efrank@ncsa.uiuc.edu
Re: Issues for a beta release... [ In reply to ]
On Apr 12, 12:02pm, Brian Behlendorf wrote:
} Subject: Re: Issues for a beta release...
> From: Brian Behlendorf <brian@wired.com>
> To: new-httpd@hyperreal.com
> Subject: Re: Issues for a beta release...
>
> What about S-HTTP, with hooks to either/both PGP or Terisa's libshttp?
> Isn't that the long term solution everyone should be working towards?
}-- End of excerpt from Brian Behlendorf

The security experts here at NCSA strongly believe that SHTTP is the
way to go. Due to resource limitations I don't feel we can implement
both SSL and SHTTP in the requested timeframes. I'm pushing for SHTTP
support over SSL as the better implementation. I'm not saying saying
NCSA will never support SSL, I'm just not willing to put it into the
httpd schedule yet.

Elizabeth Frank
efrank@ncsa.uiuc.edu
Re: Issues for a beta release... [ In reply to ]
The word from the powers that be at NCSA on Apache releasing
NCSA code before we do is:

As long as you don't imply that NCSA is in any way responsible
for supporting Apache code, and Brandon and I don't object,
NCSA doesn't have any objections. I believe Brandon has already
said it's OK and I don't have any problem with it. So go ahead
and do whatever you think is reasonable.

Elizabeth Frank
efrank@ncsa.uiuc.edu
Re: Issues for a beta release... [ In reply to ]
On Wed, 12 Apr 1995, Elizabeth Frank wrote:
> The security experts here at NCSA strongly believe that SHTTP is the
> way to go. Due to resource limitations I don't feel we can implement
> both SSL and SHTTP in the requested timeframes. I'm pushing for SHTTP
> support over SSL as the better implementation. I'm not saying saying
> NCSA will never support SSL, I'm just not willing to put it into the
> httpd schedule yet.

Cool - maybe sufficient pressure could be applied to Terisa to make
a public reference implementation available (a la SSL - while I agree
that SSL might not be the right technology, I do applaud Netscape for
having the cojones to release that). An appeal to the Cypherpunks could
be made to build a binding to PGP, which would open its use up to a wider
community, unless the NSA had something to say about that....

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/
Re: Issues for a beta release... [ In reply to ]
Brian said:

> What about S-HTTP, with hooks to either/both PGP or Terisa's libshttp?
> Isn't that the long term solution everyone should be working towards?

Not necessarily. The last visible draft of SHTTP had more errors in it
than I'd ever want to see in a security draft. I don't think anything
is a "long term solution" yet.

> Digest authentication is definitely needed - Eric at Spyglass gave us a
> reference here to code he's written for NCSA's httpd that does that plus
> the proposed HTTP extension mechanism (roy - is that a part of the 1.1
> proposal?),

Not yet. It is too verbose and attempts to override the existing
extension mechanisms inherent in the protocol.

.......Roy