Mailing List Archive

Brian said,

> things in ncsa 1.5 and not in apache

> "KeepAlive" - is this worth implementing or should we just go fullgusto
> to HTTP-NG?

if there's a spec to aim at, it'd be worth having either or both.

> RedirectPermanent (issues a 301 code instead of a 302, since 301 is
> "permanent relocation" and 302 is "temporary relocation") Anyone know
> which browsers understand 301?

I think you can argue that all browsers understand "301", they just choose
not to do anything with it differently to a "302". We should use 301
where appropriate or the user chooses.

Last time, Brian Behlendorf uttered the following other thing:
>
>
> Since we're in the midst of bug fixing don't burn too much time on this,
> but here's a summary of some features we might want to think about
> implementing.
>
> things in ncsa 1.5 and not in apache
>
> MD5 and Kerberos 4/5 authentication - I think this is worth implementing,
> at least the MD5 stuff (exportability?)

As implemented in 1.5, this stuff should all be safely exportable. We
link with the Kerberos libraries, and don't do bulk encryption yet
(though we're working on it, and will have it available from an export
controlled server until we learn if its exportable). The MD5 is exportable
as its a one way hash.

> "KeepAlive" - is this worth implementing or should we just go fullgusto
> to HTTP-NG?

We implemented KeepAlive as hashed out with a number of people. Just
before the initial beta, however, and IETF draft "Session extension"
came out. We could probably switch to it with not too much difficulty
(it actually cuts out most of the headers on the secondary requests
down the pipe). I'd think that browsers would support this before NG,
but that's just a guess (the benefit of having browser teams).

> "AND" and "OR" constructs in access control - sounds useful, but I don't
> see a big need for it.

This was actually fairly widely requested, the number one use being
"if they are in this domain, let them in, if not ask for a password"

> RedirectPermanent (issues a 301 code instead of a 302, since 301 is
> "permanent relocation" and 302 is "temporary relocation") Anyone know
> which browsers understand 301?

All browsers should understand 30x (according to the HTTP/1.0 spec), but
we're hoping we can convince at least the Mosaic developers (and others)
to notice if the request came out of the hotlist or not, and ask the
user if he would like to update his hotlist to the new link. It could
also be used (especially in Apache) to log refereral fields to those
links so that someone could attempt to get them updated by hand.
This was started with changing the redirects the server does when adding
a / to the end of a directory requests, and we figured what the hey.

Do you know if AddType cgi_magic_type .cgi works in .htaccess files
under Apache? (including allowing POST to said scripts). With the
complete rewrite of Apache .8, its fairly probable, but I thought I'd
point it out as a check.

Brandon

--
Brandon Long (N9WUC) "I think, therefore, I am confused." -- RAW
Computer Engineering Run Linux '95. 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.

Do you know if AddType cgi_magic_type .cgi works in .htaccess files
under Apache? (including allowing POST to said scripts). With the
complete rewrite of Apache .8, its fairly probable, but I thought I'd
point it out as a check.

It appears to work in 0.8.x (my usual round of server tests includes
a test case) --- NB this works even in fairly old Apache releases, due
to changes made in a fairly early Apache release as part of the cleanups
done early on...

rst

>We implemented KeepAlive as hashed out with a number of people. Just
>before the initial beta, however, and IETF draft "Session extension"
>came out. We could probably switch to it with not too much difficulty
>(it actually cuts out most of the headers on the secondary requests
>down the pipe). I'd think that browsers would support this before NG,
>but that's just a guess (the benefit of having browser teams).

Argh! It isn't "the IETF draft", it's Alex's draft. The IETF draft
will be HTTP/1.1, since you cannot safely implement keep-alive
across a 1.0 proxy.

......Roy

> RedirectPermanent (issues a 301 code instead of a 302, since 301 is
> "permanent relocation" and 302 is "temporary relocation") Anyone know
> which browsers understand 301?
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

We're working on getting the Mosaic people to support it by updating
hotlists, informing the user, etc. We don't have have any firm
dates yet. One thing that came out of the discussions was that
they wanted to see the server returning it before they implemented
something on the browser side, so we went ahead an put it in. I believe
that support for it is on the Mosaic work plan.

Elizabeth(Beth) Frank
NCSA Server Development Team
efrank@ncsa.uiuc.edu