You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@organic.com> on 1996/02/11 08:35:11 UTC
votes on 1.0.2
Many thanks to Randy for pulling together the package. Of course, this
means that the quality of my votes is only as good as the quality of his
build, I didn't apply these one by one.
The config.in that Randy supplied didn't have mod_auth_anon and mod_alias_map
listed or included, by the way. Also, the Makefile didn't have listings
for buff.c or md5c.c, so mod_proxy wouldn't compile (well, it compiled,
but it had a ton of unresolved symbols). So, that needs to be fixed. On
with the votes and comments.
100b.os2_port.patch +1
looks fine to me - wish we could have a little more abstraction, but oh
well.
23a.mmap.patch +1
56.alias_userdir.patch +1
61a.preserve_redirect +1
62a.escape_html.patch +1
65b.new-make.tar.gz +1
buff.c and md5c.c were missing from makefile - mod_proxy?
Is this really necessary?
66.htaccess-cache +1
68b.strftime.patch +1
70c.LynxOS_port.patch +1
72.mod_imap_overhaul -1
72a.mod_imap_overhaul -1
Uh, my imagemaps don't work after this - in particular, relative
URL's in map files don't appear to get expanded when sent as a redirect
to the client (actually, aren't they supposed to be handled internally?)
I.e., I have an entry like "circle honey.htm 286,19 380,38" and what
comes back is "Location: http://honey.htm". Um.....
73a.mod_actions.patch +1
74.icons.patch +1
75.icons.tar.gz +1
76a.posix_wait4proces +1
77.user_name.patch +1
78.preserve_redirect +1
for now, but the part about "CGI must always redirect to GET" is kinda
bogus, and should be fixed. Redirect to GET only when given a 302 error
code. 301 or 303 should preserve method.
82.setsockopt_next 0
Hmm, why not just go to what NeXT needs, instead of an ifdef?
83.timefmt.patch -1
Obviated by 68b.
84b.timeout.patch +1
85.lost_conn.patch +1
86a.scoreboard_into_lo +1
87.rlimit_warning.patch +1
88.cookie_pstrcat.patch +1
89.minSpare.patch +1
90g.keepalive.patch +1
91.config_dns.patch +1
I'd like to see a runtime option to replace -DMAXIMUM_DNS too.
92.alias_htaccess.patch +1
93.opt_all_mv.patch -1
Will cause a lot of access.conf's out there to suddenly mean something
different than they currently do.
94.httpd_monitor.patc 0
Didn't test. If it works for others I'm happy.
95.mod_neg.useragent -1
I don't understand how it works, but I know that it's not enough
for a real solution for the problem. I think the solution is conditional
HTML using SGML marked sections, with a config file saying which entities
result in "true" for which regexps of user agents. At least, that's the
solution I'd hold out for.
96.hpux.RLIMIT.patch +1
97.proxy-02 +1
I have not tested this, but the changes it makes to the core server
seem to be alright.
98.errorlog.patch +1
99.bind.patch +1
Not tested, but the idea is good.
apache-msql-demo.1.0. +1
logresolve.c +1
put this in "support/" of course.
It would be nice if we could provide some nice, complete logfile
rotation and statistical analysis system
this wouldn't be any slower in perl, would it?
mod_alias_map.c
I smell creeping featuritis, but since it's a separate module I
suppose that's allowed. I'd like to see "Redirect", or whatever
its successor is, allow full Perl4 regexp's, i.e.
Translate /\/path1\/*\/object/\/path2\/\1\/object/i
Also, this sounds petty, but the handle of the module, "map_module", is
way too vague, it could be confused with the imagemap module or the
content-negotiation type map modules. Whoever builds this, please change
the handle to something with less chance of collision.
mod_auth_anon.c +1
mod_auth_db.c +1
mod_auth_msql.c +1
I didn't compile because I don't have msql.h, but I'm willing to trust
those who use it and say it works.
mod_cern_meta.c +1
mod_env.c +1
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: votes on 1.0.2
Posted by Jeremie Miller <jm...@mwci.net>.
Brian Behlendorf wrote:
>
> If it were distributed as a separate module, or a patch file in
> /support, I'd be happier. I'm just afraid of the Apache group formally
> sponsoring a mechanism which is abhorrent from a standards point
> of view (binary negotiation on user-agent, hey, I do it on our sites too).
> But it's clearly something people want, and if it means less people would
> have "you must be using netscape to view these pages!", I'll accept it,
> but not as a part of the core code. Make it mod_negotiation_ua.c
> or something.
>
> Brian
Great! Sounds like a good Idea. I patched it against a fresh mod_negotiation.c and
uploaded it to /httpd/patches/incoming. I forgot to put some documentation on it the
first time, so move the mod_negotiation_ua2.c to mod_negotiation_ua.c. It is a drop in
replacement for mod_negotiation.c. The main reason I wrote this patch is so that our
clients _don't_ have to tout "you must be using netscape to view these pages!", and many
seem to be pleased with it so far. If this can be voted into the /support directory,
great, otherwise it can be put in the contrib dir.
Jeremie Miller
jmiller@mwci.net
BTW, Does anyone know the current status of the HTTP/1.1 content negotiation, especially
in reference to feature negotiation?
Re: votes on 1.0.2
Posted by Brian Behlendorf <br...@organic.com>.
If it were distributed as a separate module, or a patch file in
/support, I'd be happier. I'm just afraid of the Apache group formally
sponsoring a mechanism which is abhorrent from a standards point
of view (binary negotiation on user-agent, hey, I do it on our sites too).
But it's clearly something people want, and if it means less people would
have "you must be using netscape to view these pages!", I'll accept it,
but not as a part of the core code. Make it mod_negotiation_ua.c
or something.
Brian
On Mon, 12 Feb 1996, Jeremie Miller wrote:
> Brian Behlendorf wrote:
> >
>
> > 95.mod_neg.useragent -1
> > I don't understand how it works, but I know that it's not enough
> > for a real solution for the problem. I think the solution is conditional
> > HTML using SGML marked sections, with a config file saying which entities
> > result in "true" for which regexps of user agents. At least, that's the
> > solution I'd hold out for.
>
>
> It works with the mod_negotiation type-map files...
> ===================================
> URI: foo
>
> URI: foo.netscape2.html
> Content-type: text/html
> User-Agent: Mozilla/2.0
>
> URI: foo.txt.html
> Content-type: text/html
> User-Agent: Lynx
>
> URI: foo.standard.html
> Content-type: text/html; qs=0.9
> ====================================
> by adding the "User-Agent" header.
>
> I agree that it is not the "ideal" solution, but it is something that works and can fill
> the need for this in the interim.
>
> Jeremie Miller
> jmiller@mwci.net
>
>
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: votes on 1.0.2
Posted by Jeremie Miller <jm...@mwci.net>.
Brian Behlendorf wrote:
>
> 95.mod_neg.useragent -1
> I don't understand how it works, but I know that it's not enough
> for a real solution for the problem. I think the solution is conditional
> HTML using SGML marked sections, with a config file saying which entities
> result in "true" for which regexps of user agents. At least, that's the
> solution I'd hold out for.
It works with the mod_negotiation type-map files...
===================================
URI: foo
URI: foo.netscape2.html
Content-type: text/html
User-Agent: Mozilla/2.0
URI: foo.txt.html
Content-type: text/html
User-Agent: Lynx
URI: foo.standard.html
Content-type: text/html; qs=0.9
====================================
by adding the "User-Agent" header.
I agree that it is not the "ideal" solution, but it is something that works and can fill
the need for this in the interim.
Jeremie Miller
jmiller@mwci.net
Re: conditional HTML
Posted by ra...@madhaus.utcs.utoronto.ca.
> Processing instructions are a little less ugly, but less well defined by
> SGML. Basically they are tags which begin with a ?, and it's left up to
> the browser or spec to specify what to do with them. I.e.
>
> <?IF cond="condition">
> <?ELSIF>
> <?ENDIF>
I have written a server-side html-embedded scripting language called
PHP/FI that is used by quite a few sites on the Net now. I by no means
think it should become any sort of standard, but I do think it serves
as a good example of what can be done with such a language.
I went back and forth on the question of what to use as the initiator
tag as well. I ended up going with the SGML PI tag, even though most
browsers have no clue what to do with them if they do manage to slip
through unparsed. Here is some example code which displays a list of
files in a table. The actual file information is read right out of
a directory with opendir() and readdir() calls in a while loop.
A regular expression match is done on the filenames to figure out if
they are valid (.gz or .zip) and an appropriate icon is used to
represent the file. Then at the bottom an RFC-1867 File Upload form
is presented and users who know the upload password may go ahead
and upload files directly to the upload directory. More information
on PHP/FI can be found at http://www.io.org/~rasmus if you are interested.
The site is currently being completely re-written and moved to
http://www.vex.net/php, so you may want to check there as well. The
actual file upload page is only on vex.net.
<?
$file_dir = "files";
opendir($file_dir);
$entry = readdir();
$i=0;
while($entry);
$dir[$i] = $entry;
$type[$i]=0;
if(reg_match(".*\.gz$",$entry));
$type[$i] = 1;
$i++;
elseif(reg_match(".*\.zip$",$entry));
$type[$i] = 2;
$i++;
endif;
$entry = readdir();
endwhile;
$num = $i>
<center><table border=2>
<?if($num==0); echo "<caption>No Files!</caption><p>";
elseif($num==1); echo "<caption>1 File</caption><p>";
else; echo "<caption>$num Files</caption><p>"; endif>
<tr><th></th><th>Filename</th><th>Size</th><th>Date</th>
<th>Description</th></tr>
<?$i=0;
while($num && $i < $num);
if($type[$i] == 1)>
<tr><td align=center>
<img src="/php/gifs/filegz.gif" hspace=2></td>
<?elseif($type[$i] == 2)>
<tr><td align=center>
<img src="/php/gifs/filezip.gif"></td>
<?endif>
<td align=center>
<?echo "<a href=\"/php/files/$dir[$i]\">$dir[$i]</a></td>";
echo "<th>";
echo fileSize("$file_dir/$dir[$i]");
echo "</th><th>";
echo Date("M d/y H:i:s",fileMtime("$file_dir/$dir[$i]"));
echo "</th>";
$fp = @fopen("$file_dir/$dir[$i].info","r");
echo "<td align=left>";
if($fp != -1);
$line = fgets($fp,100);
while($line);
echo $line;
$line = fgets($fp,100);
endwhile;
else;
echo "none";
endif;
echo "</td></tr>";
$i++;
endwhile;
echo "</table></center>">
<p><hr>
<center>
<form action="/php/receive.phtml"
enctype="multipart/form-data" method=POST>
Upload password: <input type="password" name="pw"><br>
<input type="hidden" name="MAX_FILE_SIZE" value="1000000">
Filename: <input type="file" name="filename"><br>
Description<br>
<textarea name="description" rows=3 cols=30></textarea><br>
<input type="submit" value=" Send File ">
</form></center>
Re: conditional HTML
Posted by Brian Behlendorf <br...@organic.com>.
On Sun, 11 Feb 1996, Dean Gaudet wrote:
> Should I clean up HotWired's conditional html code and submit it?
> It requires a patched Bison to even build it. It also has a scanner
> I'm not overly proud of. Last time I talked about it here I got the
> feeling you (plural) weren't interested in it... I'm fairly certain
> that the syntax bothers at least Brian :)
...
> I'm willing to give the code to someone else who has the time to
> change it to whatever you guys decide you want it to look like.
Here's my take. The lack of HTTP content negotiation to be able to deal
with microvariants within content types (i.e., new vendor-specific tags
to HTML) means that we will probably see some form of conditional HTML
that gets shipped to the client, where the conditional expansion
happens. This is much more friendly on servers (who then don't have to
do the user-agent comparison (thanks, microsoft!) and *especially*
friendly on caches, which then don't have to keep copies of html pages
tailored for every client in even the best case. Conditional HTML will
basically be a formalization of the functionality one sees with
<EMBED><NOEMBED> - a client is "aware" of a couple major feature sets it
supports, and can switch on those feature sets.
Content negotiation *will* be used to distinguish between HTML with the
conditional functionality, and regular old HTML, for purposes of
backwards compatibility. The most graceful thing to do for browser which
don't support conditional HTML is to have a module which parses it for
them, using a lookup table of browsers and known feature sets they
support.
What will this conditional HTML look like? Keeping HTML a conformant
application of SGML is still considered a Good Thing, so using special
tags like <if>, <else>, etc is not recommended. The two mechanisms in
SGML which could provide for this are marked sections or processing
instructions. Marked sections would look something like this (to switch
on, say, tables)
<![ %FEATURE.hasTables; [
<TABLE> .... </TABLE>
]]>
<![ %NOT.hasTables; [
<PRE> .... </PRE>
]]>
By default all entities beginning with "FEATURE" could resolve to false,
since in SGML unknown entities resolve to true. I have been assured by
SGML gurus that the regular "NOT", "AND", and "ELSIF" functionality can
be accomplished this way.
Processing instructions are a little less ugly, but less well defined by
SGML. Basically they are tags which begin with a ?, and it's left up to
the browser or spec to specify what to do with them. I.e.
<?IF cond="condition">
<?ELSIF>
<?ENDIF>
etc. The SGML purists don't like it as much because documents become
harder to parse (DTD's alone can't describe the proper semantics) so
having two different <BODY> tags would be illegal. Or maybe I have this
completely wrong, I don't know. I do know it's important to keep it
simple enough that people will want to use it, and PI's might be the best
bet.
Marc Hedlund and I are trying to get together people interested in
formulating a proposal... I think it would be best if the Apache group
did not endorse a particular conditional-HTML format until we have one
we're reasonably sure will be the one used client-side as well.
Otherwise we have a mess of people saying "we've been doing it this one
way for awhile now, we have thousands of documents in this format, we
don't want to switch!" Unless, of course, we could write a converter....
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: votes on 1.0.2
Posted by Dean Gaudet <dg...@hotwired.com>.
In article <Pi...@fully.organic.com> you write:
>95.mod_neg.useragent -1
> I don't understand how it works, but I know that it's not enough
> for a real solution for the problem. I think the solution is conditional
> HTML using SGML marked sections, with a config file saying which entities
> result in "true" for which regexps of user agents. At least, that's the
> solution I'd hold out for.
Should I clean up HotWired's conditional html code and submit it?
It requires a patched Bison to even build it. It also has a scanner
I'm not overly proud of. Last time I talked about it here I got the
feeling you (plural) weren't interested in it... I'm fairly certain
that the syntax bothers at least Brian :)
<if supports=property1>
<p>say hi to the browser that does property1
<endif>
<if expr> ... <elsif expr> ... <elsif expr> ... <else> ... <endif> is the
general format. expr can contain AND, OR, NOT and ()s.
It's configured with the UserAgent directive:
UserAgent /regexp/ property1 property2 ...
Using my stuff requires the following:
- whenever a change is required to the parser the person requires a patched
bison (well not really, I just wanted the full multithreading support
figuring you guys would want that... and there are bugs in the latest
bison that mess up its re-entrant features)
- the gnu regex library
I'm willing to give the code to someone else who has the time to
change it to whatever you guys decide you want it to look like.
Dean