Mailing List Archive

httpd patch B5 updated.
Patch : B5
Submitter : andrew@www.elsevier.co.uk/andrew@www.elsevier.co.uk
Sumary : XBITHACK not honored on (!--#include--)ed files
Version :
State : invote
Priority : 3
Keywords : XBITHACK, include
Have Code : No
Conflicts :
Description:

XBITHACK not honored on (!--#include--)ed files

--- andrew on Tue Mar 14 12;41;09 PST 1995 ---
Re: httpd patch B5 updated. [ In reply to ]
Which browser are you using? The scripts are workign for me :-/

Cliff

On Mar 14, 8:40pm, Andrew Wilson wrote:
} Subject: Re: httpd patch B5 updated.
}
} > Patch : B5
} > Submitter : andrew@www.elsevier.co.uk/andrew@www.elsevier.co.uk
} > Sumary : XBITHACK not honored on (!--#include--)ed files
} > Version :
} > State : invote
} > Priority : 3
} > Keywords : XBITHACK, include
} > Have Code : No
} > Conflicts :
} > Description:
} >
} > XBITHACK not honored on (!--#include--)ed files
} >
} > --- andrew on Tue Mar 14 12;41;09 PST 1995 ---
}
}
} Oh bogus,
}
} I've upped code, and even used the forms to POST that I'd used
} NCSA 1.3R as the base. If this scripting code isn't working can you just
} disable it (stop it spamming the new-httpd list, er, like I'm doing now...)
} til it's un b0rken?
}
} Cheers,
} Ay.
}
}-- End of excerpt from Andrew Wilson
Re: httpd patch B5 updated. [ In reply to ]
OK...email updates are still active. but not email submits. I did that
to keep someone from spamming the list. If you then go in and update,
mail will be sent to the list. It is trivial to change this
behavior to always send mail.


As for status, yes...some more complicated things are accepted. Even
some of the small changes that were in-vote were still being
discussed (SO_LINGER), while large ones (like the CERT) are
clearly needed hence accepted. (Accepted means, yes we will
do this)

It's all a function of complexity and priority.

Cliff
Re: httpd patch B5 updated. [ In reply to ]
>
> Just what the fsck is going on anyway?

it is getting messy. I still think we should all implemement one
patch at a time together. At the rate (and hours) some are working
we can probably manage a couple of patches a day. It's far too
easy to grab the next apache-pre and without knowing what's in it
or how it is supposed to work.

If this is acceptable to the rest of the group, I think we should
order the patches, and start a systematic processes of dicsussion,
implemenations and testing.

Why not stop adding new patches for now, and just properly process
the ones we have. Then accept more patches.


rob
Re: httpd patch B5 updated. [ In reply to ]
> but can we at
> least decide which patches are *completely* non-controversial and
> dispose of them now, so that discussion time is spent on topics where
> there's something to discuss?

Okay, let's start that now.

Most of the smaller patches in the apache-pre were easy enough to look
at and determine what they were doing. Some of the bigger ones were
less obvious, and the lack of a pointer to some documenation describing
the problem(s) being addressed, had me lost - all I could see was a huge
number of diff lines with not enough documentation.

I've only uploaded a couple of patches, but I've tried to over document
them so that it's easy to see what's changed and why.

robh
Re: httpd patch B5 updated. [ In reply to ]
> Agreed up to here.
>
> It might be a good idea to limit ourselves to:
>
> o Discussing NO MORE THAN 1 (say) patches at a time.
> o Not moving on to a 2nd patch till the previous one
> has been completely dealt with and signed off.
>
> This is where I have a problem. What with everybody's sleep/wake
> cycles being as off-kilter as they are, I have a hard time imagining a
> patch getting cleared in less than twenty-four hours. This means we'd
> spend the better part of a *month* just groveling over the existing
> patch list (especially considering how likely we'd be to lose time
> over weekends). That kind of delay isn't quite what came to my mind
> when Rob said "lights, camera, *action*". [Emphasis added ;-)].

I agree completely. I have enjoyed the pace of things personally.

How about maintaining an "Alpha" source tree, and a "Pre-Alpha"
source tree. We can apply the patches as they arrive to the
Pre-Alpha, and use it to test and evaluate these changes before
commiting/accepting them to the "Alpha" tree.
Re: httpd patch B5 updated. [ In reply to ]
> -- Randy's -Wall cleanups (though apparently he's removed them from the
> patch directory on hyperreal)

I did not remove these. But can supply a new copy if needed.
Re: httpd patch B5 updated. [ In reply to ]
On Tue, 14 Mar 1995, Rob Hartill wrote:
> > Just what the fsck is going on anyway?
>
> it is getting messy. I still think we should all implemement one
> patch at a time together. At the rate (and hours) some are working
> we can probably manage a couple of patches a day. It's far too
> easy to grab the next apache-pre and without knowing what's in it
> or how it is supposed to work.
>
> If this is acceptable to the rest of the group, I think we should
> order the patches, and start a systematic processes of dicsussion,
> implemenations and testing.
>
> Why not stop adding new patches for now, and just properly process
> the ones we have. Then accept more patches.

Okay, I apologize if my productivity spurt over the weekend has caused
problems, I just wanted to take rst's momentum and not let it fall
short - but it seemed like all the bug fixes were uncontroversial enough
(like the -Wall modifications) to merit testing it out. Finally I've
been doing all the patches by hand, and testing out each feature, to make
sure they've all happily worked together, as so far they have.

Here's the list of patches and slight modifications I've put into my
working copy. With the exception of http_mime_db.c (rst's content
negotiation) and a large chunk of http_alias (drtr's malloc() changes)
I've done all mods by hand and most were minor enough to be verifyable
that security holes shouldn't have been created.

implemented by RST into apache-pre.tar.Z:

PatchID Fixes:
B1 Cert scribbling hole (modified to require -DMEMHOGBUTSECURE by brian)
B2 SO_LINGER set on client sockets B3 Server always pauses 3 seconds for
scripts (configurable now with -DBABYKILLER)
B4 <!--#config timefmt --> not always working
B7 Allow directive redundant
B8 (integrated with P9)
P9 initgroups() done once per connection
P10 MIME headers read 1 character at a time (the patch list at
http://www.steam.com/~cliffs/httpd/list.cgi?id=10 suggests that
drtr and rst had different solutions, yet I see patch.drtr-read listed
as a patch in rst's apache-pre, so I presume he integrated the latter.)
P11 open_locale() and tzset() done once per connect
P12 Shared-memory name server cache (this works fine on BSDI and SGI as
as far as I can tell (i.e. it doesn't crash)).
B17 raise queue size in listen() (though this really should be a
compile-time option)
B18 Status; 302 should work, and doesn't

Now, the ones I've put in:

B22 drtr's Fix another stack scribbling hole
B23 AddType for *.cgi, *.shtml won't work in .htaccess
B24 Adds content-type negotiation
-- Custom error responses (httpd/patches/custom_error_responses_patch_E8.txt)
-- drtr's malloc() changes (httpd/patches/alias.patch)
-- roy's date patch for correct HTTP (date_patch.txt)
-- roy's patch for directory listings that use '..' instead of '../' (dir_patch.txt)
-- KEEPALIVE option on setsockopt for buggy PC clients
-- Randy's -Wall cleanups (though apparently he's removed them from the
patch directory on hyperreal)

For all the patches without official ID's I'll go create entries for
them. Cliff, if you want to re-add all those patches yourself to a build
you're making locally fine, but my build is in /export/apache/apache-pre
right now (not on the web site).

Finally, here's what I think the status is on the other patches:

B5 XBITHACK not honored on (!--#include--)ed files
Andrew, I couldn't find code for this - as soon as it's uploaded I'll
integrate it, sounds pretty simple
B6 access files written w/o O_APPEND (httpd/patches/log_patch.txt)
I tried putting this in and it caused core dumps when it went to
write, so I left it until later. a related patch
(httpd/patches/elog_patch.txt) should be discussed before
implemented - It also apparently doesn't have a patch ID.
no B13
P14 DBM-based user databases for HTTP authentication
(I haven't yet put this in as I want to make it more portable
and more generalizable - use both NDBM and GDBM, etc.)
E15 add new CGI variables
(There is only *one* new CGI variable I use and that is
DOCUMENT_ROOT - anyone contest to adding this? it should be
documented as *experimental*, of course, and not necessarily a
feature :)
E16 Allow any URL to invoke a script
Rob (Hartill), is this your *.doit patches? Is there a conflict between
this and content negotiation? I don't see any code...
B19 Embedded blanks in headers don't work
Rob (Thau), did you put this into apache-pre?
E20 Add multi-homed server support
This is not a minor patch, and has implementation questions - let's
deal with it after we deal with earlier patches.
O21 'Timeout' config setting missing from httpd.conf
Seems like a wishlist patch, but also doesn't sound too complex.

Anyways, I'll work on making this document sync with cliff's patch list.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/
Re: httpd patch B5 updated. [ In reply to ]
From: cliffs@steam.com (Cliff Skolnick)
Date: Tue, 14 Mar 1995 13:07:28 PST
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

Which browser are you using? The scripts are workign for me :-/

Cliff

They still don't display the patches sorted by category, and they
*still* aren't on hyperreal, so I can't write a script of my own which
gives me the view I want. Also, the status: values seem a bit random
--- the SO_LINGER patch, which is a fairly inoccuous bugfix as these
things go, is listed as 'invote', while some other more involved
patches are already 'accepted'.

(On the other hand, it is good to have some sort of database, and as
long as this is what we have, we ought to make a good-faith effort to
try to use it. I worry a bit about things like Brian's informal fix
to the http://foo:80/ business --- was that ever entered as a formal
patch? I'm not sure I see it).

rst

PS --- have the email updates ceased? I just got formal id's for
my addtype-directive fix and the content-negotiation code,
and didn't see an update for either one going to the list,
although they do now show up on the patches page. (I also
uploaded both to .../incoming, with the bug ID's as prefixes).
Re: httpd patch B5 updated. [ In reply to ]
I can answer on the pre- stuff; it really was something that I built
to give my own patches a smoke test, and released for the interest of
others. At the time, I was honestly expecting a formal build from
Cliff before next weekend, or I would have put more care into it.

(As to why I expected that, heck, most of the code was and is in hand,
and putting it together just isn't that complicated).

rst
Re: httpd patch B5 updated. [ In reply to ]
From: cliffs@steam.com (Cliff Skolnick)
Date: Tue, 14 Mar 1995 13:59:15 PST

As for status, yes...some more complicated things are accepted. Even
some of the small changes that were in-vote were still being
discussed (SO_LINGER), while large ones (like the CERT) are
clearly needed hence accepted. (Accepted means, yes we will
do this)

I'm not sure I understand --- the CERT patch is not large (one line);
further, it has been one of the more controversial ones --- I've
certainly seen more objections to it than I've seen to SO_LINGER.

As for SO_LINGER, there is no reason at all for this to be
controversial --- setting SO_LINGER causes *serious* problems on at
least SunOS and HP-UX, and probably other systems as well; also, the
CERN server and apparently NetSite both get along perfectly fine
without it.

It's all a function of complexity and priority.

Please elaborate.

Cliff

rst
Re: httpd patch B5 updated. [ In reply to ]
Date: Tue, 14 Mar 95 22:22:47 GMT
From: Andrew Wilson <andrew@www.elsevier.co.uk>

I agree entirely and I'd urge everyone to just slow down please.

So we need:

o An up-to-date patch list
o A deep breath
o Start at B1 and work down


Agreed up to here.

It might be a good idea to limit ourselves to:

o Discussing NO MORE THAN 1 (say) patches at a time.
o Not moving on to a 2nd patch till the previous one
has been completely dealt with and signed off.

This is where I have a problem. What with everybody's sleep/wake
cycles being as off-kilter as they are, I have a hard time imagining a
patch getting cleared in less than twenty-four hours. This means we'd
spend the better part of a *month* just groveling over the existing
patch list (especially considering how likely we'd be to lose time
over weekends). That kind of delay isn't quite what came to my mind
when Rob said "lights, camera, *action*". [Emphasis added ;-)].

I originally intended my first-cut patch list as a kind of group
ballot. Maybe it's too large to serve the purpose, but can we at
least decide which patches are *completely* non-controversial and
dispose of them now, so that discussion time is spent on topics where
there's something to discuss?

I'd really like to stay on target for an alpha of some form this
weekend if at *all* possible.

A patch's status should be one of submitted/being-discussed/dropped/accepted.

Focus some,
Ay.


rst
Re: httpd patch B5 updated. [ In reply to ]
Date: Tue, 14 Mar 1995 15:21:42 -0800 (PST)
From: Brian Behlendorf <brian@wired.com>

E16 Allow any URL to invoke a script
Rob (Hartill), is this your *.doit patches? Is there a conflict between
this and content negotiation? I don't see any code...

No, it's *my* *.doit patches, and there is very definitely a conflict
between that and content negotiation. In fact, the effect of these
patches is achieved by MultiViews requests which find *.cgi scripts,
so if content negotiation is in, than this is redundant.

B19 Embedded blanks in headers don't work
Rob (Thau), did you put this into apache-pre?

This has my name on it because I noted the bug report on Lusenet, and
made the bug entry, but I've never seen code to fix it. Doesn't seem
hard, though.

rst
Re: httpd patch B5 updated. [ In reply to ]
> Patch : B5
> Submitter : andrew@www.elsevier.co.uk/andrew@www.elsevier.co.uk
> Sumary : XBITHACK not honored on (!--#include--)ed files
> Version :
> State : invote
> Priority : 3
> Keywords : XBITHACK, include
> Have Code : No
> Conflicts :
> Description:
>
> XBITHACK not honored on (!--#include--)ed files
>
> --- andrew on Tue Mar 14 12;41;09 PST 1995 ---


Oh bogus,

I've upped code, and even used the forms to POST that I'd used
NCSA 1.3R as the base. If this scripting code isn't working can you just
disable it (stop it spamming the new-httpd list, er, like I'm doing now...)
til it's un b0rken?

Cheers,
Ay.
Re: httpd patch B5 updated. [ In reply to ]
> Which browser are you using? The scripts are workign for me :-/

Buh ;)

> Cliff

Netscape's 1.0N for UNIX, NOT the 1.1 beta.

Mmm,
Ay.
Re: httpd patch B5 updated. [ In reply to ]
> I worry a bit about things like Brian's informal fix
> to the http://foo:80/ business --- was that ever entered as a formal
> patch?

Nope, it has no official number, either in your scheme or the one Cliff is
working on.

Cliff, can you concentrate on getting an uptodate copy of the bug/improvement
list please. I've already lost track of just what the heck is meant to be going
on. Also what's the status of this pre-pre-pre release Apache stuff. It's
either a pre or it isn't surely? AND is the pre-pre-etc thing the same as
the thing Cliff is meant to be working on.

Just what the fsck is going on anyway?

Ay, ay ay!

Andrew Wilson URL: http://www.cm.cf.ac.uk/User/Andrew.Wilson/
Elsevier Science, Oxford Tel: +44 0865 843155
Re: httpd patch B5 updated. [ In reply to ]
> >
> > Just what the fsck is going on anyway?
>
> it is getting messy. I still think we should all implemement one
> patch at a time together. At the rate (and hours) some are working
> we can probably manage a couple of patches a day. It's far too
> easy to grab the next apache-pre and without knowing what's in it
> or how it is supposed to work.
>
> If this is acceptable to the rest of the group, I think we should
> order the patches, and start a systematic processes of dicsussion,
> implemenations and testing.
>
> Why not stop adding new patches for now, and just properly process
> the ones we have. Then accept more patches.
>
>
> rob


I agree entirely and I'd urge everyone to just slow down please.

So we need:

o An up-to-date patch list
o A deep breath
o Start at B1 and work down

It might be a good idea to limit ourselves to:

o Discussing NO MORE THAN 1 (say) patches at a time.
o Not moving on to a 2nd patch till the previous one
has been completely dealt with and signed off.

A patch's status should be one of submitted/being-discussed/dropped/accepted.

Focus some,
Ay.


ps. and no, I'm not just saying this cuz Rob used to buy me drinks ;)

[cuz he never did, the cheap *****!]
Re: httpd patch B5 updated. [ In reply to ]
> I originally intended my first-cut patch list as a kind of group
> ballot. Maybe it's too large to serve the purpose, but can we at
> least decide which patches are *completely* non-controversial and
> dispose of them now, so that discussion time is spent on topics where
> there's something to discuss?

Ok. If someone reposts the current patch list and marks EVERY patch as being
non-contraversial then we can just mail back the patches which any of us think
ARE contraversial and knock them off the list. One day's wait (for unfortunate
UK people who have a 9-5 7-12 job) will give you the non contraversial list which
could then be implemented immediately.

> rst

We COULD call it 'Frustration/0.1'. Er, mebbies.

Ay.
Re: httpd patch B5 updated. [ In reply to ]
Randy Terbush:

> I agree completely. I have enjoyed the pace of things personally.
>
> How about maintaining an "Alpha" source tree, and a "Pre-Alpha"
> source tree. We can apply the patches as they arrive to the
> Pre-Alpha, and use it to test and evaluate these changes before
> commiting/accepting them to the "Alpha" tree.

Mmm, that's what's happening at the moment. There's always going to be
a pre-alpha implicit in the 'test the patch before you comment on it' stage
the point is that there's no real-alpha, nor will there be until we get our act
together and stop dicking about with kuhl ideas. We have to stop, decide what we
can do fast, do it, and THEN we get our alpha. Then we get back to the fun.

There aren't enough people in this group to manage a two tiered source-tree
approach (let alone a single source tree). I think we've done enough to get a
real alpha, so lets do it.

o Can someone please post the current patch list so's we can tear out the
bit's we're worried about?

Cheers,
Ay.

Andrew Wilson URL: http://www.cm.cf.ac.uk/User/Andrew.Wilson/
Elsevier Science, Oxford Tel: +44 0865 843155
Re: httpd patch B5 updated. [ In reply to ]
On Mar 15, 10:49am, David Robinson wrote:
} Subject: Re: httpd patch B5 updated.
} I have some www bulletin board code that could be adapted for bug tracking;
} would it be of any use? It would only work if discussion of individual patches
} were actually done on the web, rather than by mail. It's written in C and
} would need a bit of hacking; does anyone want the code? (Cliff?)

I don't really want to hack other the code at this point...if someone else
does though, that would be cool. I'm still trying to learn the real
innards of the httpd server.

We should use the web, but as long as people can be well behaved, email
could be easily catagorized by subject and placed on the web automagically.
The group can decide after seeing the software.

}
} Ok, I'll set up a test server here, and you can try it out. You may
} not like the response you get to the UK though...

Is the software programmed to insult people with accents? Or does it just
look for the British spelling of words like "colour" and "organise" before
making fun of them. :-)

Send the URL when ready.

Cliff
Re: httpd patch B5 updated. [ In reply to ]
[lotsapatches]

> Finally, here's what I think the status is on the other patches:
>
> B5 XBITHACK not honored on (!--#include--)ed files
> Andrew, I couldn't find code for this - as soon as it's uploaded I'll
> integrate it, sounds pretty simple

Ewww! Ok, I'll up the patches AGAIN (*groan*) this time please no-one mess with
them, just put them in the right directory, and make sure they're there. They'll
turn up in incoming in about 10 minutes.



> Brian

Ay.

[what happened to the damned patches anyways?]
Re: httpd patch B5 updated. [ In reply to ]
I have some www bulletin board code that could be adapted for bug tracking;
would it be of any use? It would only work if discussion of individual patches
were actually done on the web, rather than by mail. It's written in C and
would need a bit of hacking; does anyone want the code? (Cliff?)

Ok, I'll set up a test server here, and you can try it out. You may
not like the response you get to the UK though...

David.