[determined by the platform's
> apr implemention]. Identified by Greg Stein.
Well, it was also intended to mean "root URI path". There is no parent for
http://example.com/. Similarly, there is no parent for
http://example.com/foo/bar/ when that Location maps to C:/
(yes, the latt
On Thu, Jan 24, 2002 at 08:42:05AM -0600, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <[EMAIL PROTECTED]>
> Sent: Thursday, January 24, 2002 4:09 AM
>...
> > Looking at the usage of 'finfo', this could be APR_FINFO_SIZE
>
> Yup, I had limited
> +if (fname_p != NULL)
> +*fname_p = NULL;
>}
*dirpath_p is not set in the 'else' branch.
Also note that no callers expect those values to be set to NULL. Given that
the paths have been processed by Apache already, it's a good bet they are
always valid.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
y on, so would like commentary from the
*real* old-timers... ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
v/propset/fs/1>";
> -#endif
>}
Same problem. The #ifndef should be restored unless/until you have the query
mechanism in place.
>...
> @@ -2077,16 +2110,8 @@
> what, phdr);
> (void) dav_fs_insert_prop(resource, DAV_PROPID_getetag,
> what, phdr);
> -
> -#ifndef WIN32
> -/*
> -** Note: this property is not defined on the Win32 platform.
> -** dav_fs_insert_prop() won't insert it, but we may as
> -** well not even call it.
> -*/
>(void) dav_fs_insert_prop(resource, DAV_PROPID_FS_executable,
> what, phdr);
> -#endif
And one more to put back.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
roll (say 24 hours).
+1 on Bill's suggestion.
And no, it wouldn't be funny tags. We'd just point the tag at a different
revision for that one file. For all intents and purposes, the fix is now
part of the 1.3.23 tag.
btw, Bill: you can/should still manually tag that .cvsignore to be correct.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
e with zero length buckets. I don't remember, and I
bet it doesn't exist now.
I say torch the damned thing. You're quite right: removing zero length
buckets is Bad Juju.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
> planning on adding some regex matching to some proxy functions,
> however, and I plan on doing so *only* via separate directives.
> Speak up now if this causes excess heartburn for anyone...
+1
+0 on torching the existing, overloaded forms. (and have Apache issue
warnings for a few releases
On Sat, Jan 12, 2002 at 09:25:30AM -0800, Brian Pane wrote:
> Greg Stein wrote:
>...
> >null parents are ugly. isn't there another pool that has the right lifetime
> >for that pool?
>
> There isn't a pool with the right lifetime in the current
> worker design
lifetime
for that pool?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
gt;
> "All right everyone! Step away from the glowing hamburger!"
--
Greg Stein, http://www.lyra.org/
s must be perfect before
we can let people play with it." Give them the info and let *them* decide.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
se this as an alpha then.
Who says we can't call it alpha? If that is what we want to call it, then
fine. We can also release it as "beta quality, but no binary builds this
time."
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
e requires an API change, then
let's give them the better code.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
to help put Emacs in the right stylistic mood? To wit,
It's all right with me! I already have all that set up by default, but it
doesn't hurt to put it into the file, too.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
he mode from the blocking.
Absolutely agree.
Whether you have two parameters, or a single param with bitfields... *shrug*
IMO, I like two params.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
"REPORT" and it
wouldn't ever respond to that method.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ot;objdump" (IIRC). I bet we can find a similar tool on all
platforms. If not, then we can hope there is a platform specific way to link
in all symbols, or that we don't need the hack, or that we can use a "pretty
close" AWK script.
Thoughts?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Thu, Dec 13, 2001 at 09:14:55PM -0500, Jeff Trawick wrote:
>...
> We already do link DSOs with -module, though we also throw on
> -export-dynamic as well, which doesn't seem appropriate.
Well, some modules export symbols for use by other modules. Maybe that is
why?
Cheers,
-g
they aren't intended for further linking.
Note that we should probably be linking the modules with libtool's -module
switch. It would be interesting to see if that prevents the installation of
the .la file.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
phase?
Seems reasonable to me. The intent was always to run that hook right before
the handling starts. It would let everything get set up in the request_rec,
and then people can make choices about whether to insert filters.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ry
If you patch the build in apr-util/xml/expat/, then I'll synchronize your
changes with the main Expat source control. That is: we can get the "right
flavor" in whatever fashion you choose.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ib])
> if test "x$ap_platform_runtime_link_flag" != "x"; then
> APR_ADDTO(LDFLAGS, [$ap_platform_runtime_link_flag${ap_zlib_Base}/lib])
>
>
>
--
Greg Stein, http://www.lyra.org/
If you really want to get anal:
if ((*tag == 'v' && strcmp(tag, "virtual") == 0)
|| ...
You can avoid a whole strcmp.
woo! (not)
Then again, you'd just be obfuscating the damned code for little overall
gain.
Cheers,
-g
On Fri, Dec 07, 2001 at 03:09:54AM -, [EMAIL PROTECTED] wrote
uot;, then the
8080 will appear in r->parse_uri.port. Of course, they could also lie on
that port and the server wouldn't know any better.
I'm not exactly sure what the right answer to this is. Kind of a fundamental
problem with Apache not able to get a port number for "this server
at was the case, then you'd
just send the brigade to the network rather than try to hold onto it.
Finally: since you probably know the size of your concat-buffer, then you
can allocate the heap bucket to be the proper size, rather than use a
default 8k heap bucket.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
bers around for use in the above
logic. But I still want to get a look at the stuff and see what's there.
I've got some particular experience with extended methods :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
from the
> reference-counted model to the transfer-of-ownership model. The latter
> doesn't require any locking.
Yah.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
apr_pool_t *p,
> + int transfer_ownership)
> +{
> +*new_mmap = (apr_mmap_t *)apr_palloc(p, sizeof(apr_mmap_t));
> +memcpy(*new_mmap, old_mmap, sizeof(apr_mmap_t));
> +(*new_mmap)->cntxt = p;
For the two dup() functions, you can use apr_pmemdup() to simplify this.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ust wanted to send out a word of caution:
don't use them as a crutch. They will most definitely become one if you let
them. THINK about your changes.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
all from CVS?
That isn't right.
-g
--
Greg Stein, http://www.lyra.org/
tter to do it
> after the client has received all of the data than during mainline request
> processing.
That is bogus, as has been pointed out. You have to close them sometime.
Doing it sooner rather than later means that you have more file descriptors
available for further processing in the request.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
hen say "get this patch." But we
gotta get more releases out into the public's hands.
2.0.16 was crap. Should people really be using that? Not a chance.
Give them 2.0.28.
-g
--
Greg Stein, http://www.lyra.org/
* the proxy code still refers to conn->client_socket
* perchild refers to conn->client_socket
-g
--
Greg Stein, http://www.lyra.org/
Unless I'm mistaken, some code got dropped from connection.c. In the current
CVS, it is at line 195. A call to apr_socket_close() and a return are
missing.
It looks like they disappeared when rev 1.87 was checked in.
Right/wrong?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
working *around* the issue when it should be *in charge*.
This change violates the very notion of an MPM being the piece of code
responsible for socket and worker handling.
I like the code changes for reducing the socket usage from Apache proper.
But removing it from the MPM isn't right.
Please explain :-(
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Oh, and I clipped out the quoted text. The core_create_conn should be
APR_HOOK_MIDDLE. There is no reason for it to be "last." The MIDDLE is the
standard one to use when you just need to pick something and have no
particular concerns about where it falls. The core_create_conn is "just
another" hook.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
d not know about the socket (only the core filters),
but the MPM definitely should. It is the beast which maps *sockets* to
*workers*. It has to know.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ect", "directories", and
"non-GET methods". That is a lot to put into a single name. I say forget
trying...
How about: redirect-carefully
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
you attach files or patches to a message, *ensure* they are
in text/plain format. You keep attaching them as application/octet-stream.
That is bad...
-g
--
Greg Stein, http://www.lyra.org/
the strcasecmp.
> It's still O(n), but the idea is to reduce the constant
> multiplier. (The checksum computation basically just
> packs the first four bytes of the string into an int and
> does some bit masking to normalize to all-uppercase.
The bit masking won't work on EBCDIC
do
instead." Of coures, they can veto your patch, but I'd wonder what
kind of technical justification they'd have for that :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
hem to change
their data type. Optimizing apr_table_t simply reduces their impetus to
change their code.
The apr_table_t is interesting in that it can keep multiple values for a
key. That is only really used for headers, and that can be best-solved by
using a new type.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ode; i.e. I
> > need to get some post data processing done in a handler in a module - and
> > want to do it properly -i.e. through the filter chain etc.
> >
> > Any place I can cut and paste this from :-)
> >
> > Dw
--
Greg Stein, http://www.lyra.org/
129,134 ****
> --- 129,138
> Sfio_t *sf_in;
> Sfio_t *sf_out;
> #endif
> +
> + void *callback_data;
> + void (*filter_callback)(BUFF *, const void *, int );
> +
> };
>
> #ifdef B_SFIO
--
Greg Stein, http://www.lyra.org/
d post the results.
Can we stop putting non-code commentary in the CVS logs? Three years from
now, that comment is going to be senseless...
If you want to comment on something, then wait for the commit message to hit
the mailer, then respond to it, to this mailing list, with your commentary.
Ch
through the
> brigade and convert any data we have into a single HEAP bucket
> that we know will survive clearing the request_rec.
> [Ryan Bloom, Justin Erenkrantz <[EMAIL PROTECTED]>,
> Cliff Woolley]
>
> --
> Sunitha Kumar
> http://www.cisco.com
>
--
Greg Stein, http://www.lyra.org/
onse_code_strings,
> sizeof(*conf->response_code_strings) * RESPONSE_CODES);
>}
> -
> +else
> +base->response_code_strings = NULL;
> +
>conf->d = new->d;
>conf->d_is_fnmatch = new->d_is_fnmatch;
>conf->d_components = new->d_components;
>
>
>
--
Greg Stein, http://www.lyra.org/
: ap_default_port(r) {
> r->proxyreq = PROXYREQ_PROXY;
> r->uri = r->unparsed_uri;
> r->filename = apr_pstrcat(r->pool, "proxy:", r->uri, NULL);
>
>
>
--
Greg Stein, http://www.lyra.org/
sed on
request boundaries)
But if a filter ever says bytes, then f->next *cannot* ever return more
than that amount.
IMO, we ought to fix mod_ssl and proxy before worrying about optimizing for
"return a nice amount".
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ry of /htdocs/ anymore (or at least it
> doesn't get installed there). That's the whole point.
Um... gotta ask Ken about this. He vetoed a change in this area.
If the change related to the veto hasn't been backed out, then we may have
to yank 1.3.21
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
pr_brigade_partition(ctx->b, *readbytes, &e);
> +
> /* Must do split before CONCAT */
>newbb = apr_brigade_split(ctx->b, e);
>APR_BRIGADE_CONCAT(b, ctx->b);
>
>
>
--
Greg Stein, http://www.lyra.org/
It must return a brigade with one byte of data, and/or an EOS
bucket. (that is: you could block and just return an EOS; you could also
return N bytes plus an EOS)
The non-blocking mode could return a zero length brigade.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
The ldap.conf shouldn't even be present. That isn't part of httpd-2.0 so why
is the config in there?
proxy.conf is a "whole" 20 lines or so. Splitting that out is just a damned
pain in the butt.
Please explain... this just doesn't seem right at all. Multiple configs are
nasty nasty nasty.
-g
--
Greg Stein, http://www.lyra.org/
rry I didn't notice this sooner... After the dust settles I'll
> adjust this section to deal with the new logic.
> --
> ===
>Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
> "A society that will trade a little liberty for a little order
>will lose both and deserve neither"
--
Greg Stein, http://www.lyra.org/
vor
of the builtin one? I don't see and can't imagine a use case for that.
(which is why I coded the selection this way)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
as fast as the people
> helping out. And, there's only one of me. =) -- justin
Well said.
I can happily contribute knowledge, but am so backed up on various projects
that helping with coding just falls further and further behind. (sigh)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
far beyond bogus
that we should not be building mod_ssl that way :-) Therefore, you have to
have some kind of buffer size for reading from the next filter.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ne.
> + * 1024 seems like a good number for now. */
> +*tempread = 1024;
*tempread ?? You might want to assign something to tempread first :-)
>...
> +pos = memchr(str, APR_ASCII_LF, len);
How about a new brigade function first?
I don't know much about the rest of how this filter works, but I am
seriously suspicious of the removal of the renegotiation code.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
libdl.so.2 => /lib/libdl.so.2 (0x400b7000)
> libexpat.so.0 => /home/dougm/ap/prefork/lib/libexpat.so.0
> (0x400ba000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x400e1000)
> libc.so.6 => /lib/libc.so.6 (0x400f7000)
> /lib/ld-linux.so.2 =
(readbytes==0), then it blindly
passes that to the next filter. Instead, it should ask f->next for BUFSIZE
bytes or somesuch, decode them, then parse a line out and return that.
"How did it work before?" Nobody ever asked it for readbytes==0 through
various happenstance circumstances. The API for input filters said that
somebody *could* do that, but it just didn't happen.
Can you say, "fragile" ? Thought so.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ing needs some pushback so each higher level filter can avoid
> hanging on to bytes it doesn't want or need, and push them back at a lower
> level filter that can keep them in their queue for the next transaction
> within the request or the next request within the connection.
At this point, we don't need any concept of pushback. A filter should return
up to what was asked and no more.
But I seriously doubt that is the problem here. I'm guessing that mod_ssl
was coded "knowing" that the brigade it got back from f->next was a socket
bucket. Or that the brigade had certain properties when reading from it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
nd saying
"back up" rather than seeing the target and saying "take the next two steps"
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
t as a
registry for them. it goes without saying that people won't have every
third party module, so each apache process would have *huge* holes, thus
wasting significant processor tables ]
Does that answer your questions? :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
t mod_ssl is just a big quagmire.
>
> That, or your input filtering changes were the big quagmire. Either way,
> that sure sounds like the interaction that broke ssl.
I'll lay good odds that it is in mod_ssl rather than the input filtering
changes. Even *if* it is the latter, at least we have a codebase that is
much more maintainable now.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ional query; I'm not sure that we'd rip it
out (there could still be people who don't regularly read this list); I
think the answer is to fix Configure to find the system lib when possible.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ons are Ned Freed and
> Patrik Faltstrom
- End forwarded message -
--
Greg Stein, http://www.lyra.org/
On Mon, Oct 01, 2001 at 03:51:07PM -, [EMAIL PROTECTED] wrote:
> wrowe 01/10/01 08:51:07
>
> Modified:modules/generators mod_status.c
> Log:
> Clean up some warnings by summing bytecounts into apr_off_t holders
> instead of ulongs.
Ah! Good stuff.
Ch
he headers, among many other things), then there
isn't a problem with adding the HTTP_IN filter.
If somebody wants to make protocol.c "pure", then they're going to have a
lot more to worry about than the HTTP_IN thing.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
n't been enough
> TIME to look at this HUGE/CRITICAL patch.
It *has* been reviewed. Given that we're in commit-then-review mode, and
that two people are fine with the patch, then it can/should go in. If
further problems are discovered in the patch, then they can be fixed in the
repository rather than before the patch is applied.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
s it going to be finalized too?
Note: modules/experimental/mod_ext_filter
That "experimental" in there means just that :-) ... it could be updated if
somebody wants to. Or it could remain the same... :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Thu, Sep 27, 2001 at 01:33:10AM +0200, Graham Leggett wrote:
> [EMAIL PROTECTED] wrote:
>
> > add the ProxyHTTPOverrideReturnedErrors directive documentation
>
> Would anyone object to me changing this to "ProxyErrorOverride" - the
> above directive is *way*
As a "Runtime", it can contain any kinds of functionality. And the
"Portable" is just an adjective.
Alternatively, if you have a "runtime to create portability" ... then yah:
your point would hold.
Just playing the devil's advocate :-)
I'm still in favo
On Wed, Sep 26, 2001 at 04:15:30PM -0700, Aaron Bannert wrote:
> On Wed, Sep 26, 2001 at 03:52:18PM -0700, Greg Stein wrote:
> > > FWIW, flood in httpd-test already has 80% of what Sander suggested.
> >
> > Sander and I already talked about stealing code from flood and m
On Wed, Sep 26, 2001 at 03:33:12PM -0700, Justin Erenkrantz wrote:
> On Wed, Sep 26, 2001 at 03:21:42PM -0700, Greg Stein wrote:
> > But that said, I'm am a BIG +1 on adding an http client library into the
> > ASF's APR project. Whether people want that to go into apr-u
don't see SVN switching away from it for 1.0. But
post 1.0, picking up the pipelining and the tight APR integration will be
big win. [unless apr-client somehow managed to stabilize really fast]
I just think that the ASF projects could use it, and I think getting a
nicely licensed, fully capable client library would be great.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
nesday 26 September 2001 02:14 pm, Sander Striker wrote:
> > Hi all,
> >
> > I wish to propose a new library: apr-client.
>...
--
Greg Stein, http://www.lyra.org/
ket_brigade *b, ap_input_mode_t
>mode, apr_off_t *readbytes)
Wow. This function seems like it is going to be dramatically simpler. Hard
to see through all of this mess, though :-)
I'm +1 on the patch, but with the caveat that *many* more comments need to
be added. There are still hacks all over the place (from before Justin's
patch, and at least one new one). I tried to comment the hacks before;
thankfully, Justin's patch removes most of those. But there are still more,
and we can't just let those slide...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
he files would
also need to be moved over to modules/proxy/Attic (with the similar care for
any overwrites).
Are we having fun yet? :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
y agree with Ryan. While some people may argue that isn't the
best thing for the code, it *is* the best thing for the group and the
community. And (IMO) that is at least as important as the code, if not more.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ngs to do with the brigades.
We're still refining their functionality. We've got architecture issues with
input filtering. And that is just one piece of the code.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
the way I see it...) -- justin
Cool. Me too :-)
Like I said, I was just hoping that your patch would not require all of this
extra work. That it could be applied as an incremental improvement. But,
alas... that doesn't seem to be the case. So the first step would be
adjusting the return amounts, then applying your patch.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Mon, Sep 24, 2001 at 11:58:40AM -0700, Justin Erenkrantz wrote:
> On Mon, Sep 24, 2001 at 01:32:02AM -0700, Greg Stein wrote:
> > Eww. No... just move the filter back to the connection and you're fine. We
> > can make it a request filter later on.
>
> Actually, you
ctx->state = BODY_NONE;
>...
> +/* We need to read the CRLF after the chunk. */
> +if ((rv = ap_getline(line, sizeof(line), f->r, 0)) < 0) {
> +return rv;
> +}
Is the BODY_NONE thing so that the ap_getline() recursion
r requests more from the lower-level input filter),
then we can move it to a request filter (which, as I mentioned before has
interesting properties).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Sun, Sep 23, 2001 at 09:27:58PM -0700, Ryan Bloom wrote:
> On Sunday 23 September 2001 09:21 pm, Greg Stein wrote:
>...
> > There is a create_request hook which inserts the HTTP_IN filter when the
> > request is created.
> >
> > This seems like a good idea: eac
On Sun, Sep 23, 2001 at 03:04:54PM -0700, Ryan Bloom wrote:
> On Sunday 23 September 2001 02:53 pm, Greg Stein wrote:
> > On Sun, Sep 23, 2001 at 08:33:07AM -0700, Ryan Bloom wrote:
> > > None of this can be committed until it has passed all of the tests in the
> > > pe
e.g. split a brigade at the newline point, and return the initial
brigade).
I need to review the code some more. As Justin pointed out, the massive
change to http_protocol.c makes that hard to review. Other notes may be
coming soon...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
> -
> > -APR_BRIGADE_INSERT_TAIL(b, eos);
> > -}
Somebody has to return an EOS somewhere.
Consider the highest-level input filter. How does it know when it has read
all of the data for the current request? It needs to see an EOS bucket.
I'll wait for the new patch and review again. All the formatting changes
were getting in the way.
But I really think the proper tack is to fix the amount-returned, and to
combine the HTTP_IN and DECHUNK filters.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Thu, Sep 20, 2001 at 07:54:22PM -0700, Ryan Bloom wrote:
> On Thursday 20 September 2001 05:48 pm, Greg Stein wrote:
...
> > Calling pop_cleanup() on every iteration is a bit much. Consider the
> > following patch:
>
> Why is it a bit much? I just took a quick look at
On Thu, Sep 20, 2001 at 07:02:58AM -0700, Ryan Bloom wrote:
> On Wednesday 19 September 2001 02:21 pm, Greg Stein wrote:
>...
> > They are not strictly LIFO. You can remove a cleanup and insert a new one
> > at any time. Let's say that the cleanup list looked like:
after* cleanup A finishes. If A wanted that, then
it could just calll B. But the most important part: all cleanups *do* get
run.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
re fine. Aaron must have posted an unescaped
version of the URL.
(go to a mod_mbox page and view the source...)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
t; But I think we also have concensus that the name shouldn't be "apache".
> "apache-httpd-2.x.x.tar.gz" seems better.
Agreed.
I am +0 on httpd-2... and +1 on apache-httpd-2...
btw, no dates in those either (a suggestion from otherbill). The version
number tells us what we need to know.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Wed, Sep 19, 2001 at 12:16:24PM -0700, Ryan Bloom wrote:
> On Wednesday 19 September 2001 11:37 am, William A. Rowe, Jr. wrote:
> > From: "Greg Stein" <[EMAIL PROTECTED]>
> > Sent: Wednesday, September 19, 2001 1:26 PM
>...
> > > The problem is cross-
On Wed, Sep 19, 2001 at 01:52:12PM -0400, Rodent of Unusual Size wrote:
> Greg Stein wrote:
> > It isn't a bug. Cleanups are for just wrapping things up,
> > not doing work.
>
> If that's the authoritative answer, then we need to provide
> a supported wa
On Wed, Sep 19, 2001 at 11:17:36AM -0500, William A. Rowe, Jr. wrote:
> From: "Ryan Bloom" <[EMAIL PROTECTED]>
> Sent: Wednesday, September 19, 2001 9:52 AM
>
>
> > On Tuesday 18 September 2001 06:09 pm, Greg Stein wrote:
> > > I agree with OtherBi
On Tue, Sep 18, 2001 at 06:33:14PM -0700, Aaron Bannert wrote:
> On Tue, Sep 18, 2001 at 06:01:35PM -0700, Greg Stein wrote:
>...
> > >...
> > > --- fdqueue.c 2001/09/18 21:14:18 1.6
> > > +++ fdqueue.c 2001/09/18 23:09:12 1.7
> > > @@ -
e
values are being discarded.
And generally, a discarded value isn't a Good Thing, so those (void) casts
leave markers for somebody to fix the code at some future time.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Tue, Sep 18, 2001 at 06:52:35AM -0400, Jeff Trawick wrote:
> Greg Stein <[EMAIL PROTECTED]> writes:
>
> > 2) move the ap_lingering_close inside ap_process_connection, then call it
> >from with ap_process_connection. This *almost* works. All MPMs have a
> >
401 - 500 of 583 matches
Mail list logo
