On Thu, Nov 12, 2009 at 11:27, Rich Bowen wrote:
>
> On Nov 12, 2009, at 11:12 , Nick Kew wrote:
>
>> Ken Dreyer wrote:
>>>
>>> (another user's perspective)
>>> At my work (US. Geological Survey) we try to discourage webmasters
>>> from using server-side imagemaps, since they are not Section 508
>
On Thu, Nov 12, 2009 at 09:59, Arturo 'Buanzo' Busleiman
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Greg Stein wrote:
>> Apache remains the broad solution, but for narrow requirements, people
>> will select something that is easier to handle
On Wed, Nov 11, 2009 at 23:21, William A. Rowe Jr. wrote:
> Rich Bowen wrote:
>> Don't you think that maybe it's time to drop mod_imagemap and mod_cern_meta?
>>
>> "there is already a large number of CERN users who can exploit this module."
>>
>> Seriously?
>
> LOL
>
> FWIW I know of one customer
On Wed, Nov 11, 2009 at 15:00, Arturo 'Buanzo' Busleiman
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Greg Stein wrote:
>> Right. But they don't have the depth/breadth of modules like we do.
>
> ... yet. Keep going, but if there are great
On Wed, Nov 11, 2009 at 20:56, Rich Bowen wrote:
> Don't you think that maybe it's time to drop mod_imagemap and mod_cern_meta?
> "there is already a large number of CERN users who can exploit this module."
> Seriously?
I say "hell yes".
And my response to a user would be "you want that? fine. i
On Wed, Nov 11, 2009 at 20:09, Jeff Trawick wrote:
> On Wed, Nov 11, 2009 at 6:58 PM, Greg Stein wrote:
>> On Wed, Nov 11, 2009 at 17:11, Jeff Trawick wrote:
>>> At present, whatever was in errno at the time the dav_error {} was
>>> created is treated as an ap
On Wed, Nov 11, 2009 at 17:11, Jeff Trawick wrote:
> At present, whatever was in errno at the time the dav_error {} was
> created is treated as an apr_status_t by ap_log_rerror().
>
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200211.mbox/%3c20021101033848.b29...@lyra.org%3e
>
> dav_error
On Wed, Nov 11, 2009 at 14:14, Akins, Brian wrote:
> On 11/10/09 6:20 PM, "Greg Stein" wrote:
>
>> I'd like to see a few "network" threads multiplexing all the writing
>> to clients.
>
> That's what I meant. I just didn't state it pro
On Tue, Nov 10, 2009 at 17:30, Akins, Brian wrote:
> On 11/10/09 1:56 PM, "Greg Stein" wrote:
>
>
>> But some buckets might be performing gzip or SSL encryption. That
>> consumes CPU within the network thread.
>
> You could just run x times CPU cores number o
On Tue, Nov 10, 2009 at 16:33, Lieven Govaerts wrote:
> On Tue, Nov 10, 2009 at 6:10 PM, Greg Stein wrote:
>...
>> You have 10k buckets representing the response for 10k clients. The
>> core loop reads the response from the bucket, and writes that to the
>> network.
&g
On Tue, Nov 10, 2009 at 12:54, Graham Leggett wrote:
> Greg Stein wrote:
>
>>> Who is "you"?
>>
>> Anybody who reads from a bucket. In this case, the core network loop
>> when a client connection is ready for writing.
>
> So would it be correct
On Tue, Nov 10, 2009 at 12:01, Jim Jagielski wrote:
> On Nov 9, 2009, at 2:19 PM, Akins, Brian wrote:
>> On 11/9/09 2:06 PM, "Greg Stein" wrote:
>>
>>> These issues are already solved by moving to a Serf core. It is fully
>>> asynchronous.
>>
&g
On Tue, Nov 10, 2009 at 11:14, Akins, Brian wrote:
> On 11/9/09 3:08 PM, "Greg Stein" wrote:
>
>> 2) If you have 10,000 client connections, and some number of sockets
>> in the system ready for read/write... how do you quickly determine
>> *which* buckets to p
On Mon, Nov 9, 2009 at 18:47, Graham Leggett wrote:
>...
>> When you read from a serf bucket, it will return however much you ask
>> for, or as much as it has without blocking. When it gives you that
>> data, it can say "I have more", "I'm done", or "This is what I had
>> without blocking".
>
> Wh
On Mon, Nov 9, 2009 at 16:19, Graham Leggett wrote:
> Greg Stein wrote:
>> These issues are already solved by moving to a Serf core. It is fully
>> asynchronous.
>>
>> Backend handlers will no longer "push" bits towards the network. The
>> core will &
On Mon, Nov 9, 2009 at 15:21, Greg Stein wrote:
> On Mon, Nov 9, 2009 at 14:46, Stefan Fritsch wrote:
>> On Monday 09 November 2009, Greg Stein wrote:
>>> >> Why did you go with a format change of the DAVLockDB? It is
>>> >> quite possible that people will
On Mon, Nov 9, 2009 at 14:46, Stefan Fritsch wrote:
> On Monday 09 November 2009, Greg Stein wrote:
>> >> Why did you go with a format change of the DAVLockDB? It is
>> >> quite possible that people will miss that step during an
>> >> upgrade. You c
On Mon, Nov 9, 2009 at 14:21, Paul Querna wrote:
>...
> I agree in general, a serf-based core does give us a good start.
>
> But Serf Buckets and the event loop definitely do need some more work
> -- simple things, like if the backend bucket is a socket, how do you
> tell the event loop, that a wo
On Mon, Nov 9, 2009 at 13:59, Graham Leggett wrote:
> Akins, Brian wrote:
>
It works really well for proxy.
>>> Aka "static data" :)
>>
>> Nah, we proxy to fastcgi php stuff, http java stuff, some horrid HTTP perl
>> stuff, etc (Full disclosure, I wrote the horrid perl stuff.)
>
> Doesn't mat
On Mon, Nov 9, 2009 at 08:42, Stefan Fritsch wrote:
> On Monday 09 November 2009, Greg Stein wrote:
>> On Mon, Nov 9, 2009 at 08:14, wrote:
>> > Author: sf
>> > Date: Mon Nov 9 13:14:07 2009
>> > New Revision: 834049
>> >
>> > URL: htt
On Mon, Nov 9, 2009 at 08:14, wrote:
> Author: sf
> Date: Mon Nov 9 13:14:07 2009
> New Revision: 834049
>
> URL: http://svn.apache.org/viewvc?rev=834049&view=rev
> Log:
> Make PUT with DAV_MODE_WRITE_TRUNC create a temporary file first and, when the
> transfer has been completed successfully, m
Sorry for missing earlier messages; I don't follow httpd as closely as before.
See my replies below:
On Mon, Nov 9, 2009 at 06:28, Stefan Fritsch wrote:
> On Friday 23 October 2009, Stefan Fritsch wrote:
>> On Thursday 22 October 2009, Joe Orton wrote:
>> > > Is the performance improvement of in
On a phone, so pls excuse my brevity...
I think a lot of your discussion can be easily passed off to Apache Thrift.
Let it handle all the message passing to external procceses, and its
provided multi-language support.
On Nov 5, 2009 4:31 PM, "Graham Dumpleton"
wrote:
2009/11/5 Graham Leggett :
I think it would be a bad idea to tie it to a specific version.
On Tue, Dec 16, 2008 at 19:59, Brian McCallister wrote:
> Another suggestion from the lua mailing list, and not a bad one...
>
> On Tue, Dec 16, 2008 at 5:53 PM, Jeff Pohlmeyer
> wrote:
>> Just a thought...
>>
>> The Apache PHP modu
Yeah, that can be confusing with the natural language directives/concepts.
mod_script_lua
mod_embedded_lua (me likee this one)
I'm also fine with just taking mod_lua. mod_luau doesn't seem bad, and
I don't think there'd be typos: the directives would probably be
LuaSomething anyways.
Cheers,
-g
s
today]. What are the group's thoughts on that?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
inity (for a collection; depth infinity on
a member must be ignored), then it uses the old entry points.
You're going to be doing a good bit of monkeying around with the control
flow to get this one-shot vtable entry to work. Doable, yes, but probably
not as straight-forward as you intended...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
d_dav API/ABI change into httpd
> trunk. We're not talking about a lot of code here. If others agree,
> I can start posting patches.
>
> (Greg Stein, I assume you're okay with this too? I think it was your
> idea to bump mod_dav in the first place...)
Oh, I'm total
moved past the "single static file
website". We already have a lot of documentation. Admittedly, it doesn't
describe scenarios like yours, but I'll venture to guess that you're in
the few-percent case. I'm more than happy to have our doc folks
concentrating on the other 97% :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
VER figure out which file a given
configuration was in. I always had to search, then edit.
We've been to the "multiple .conf world" before. It sucked. We pulled
everything back into a single .conf to get the hell outta there.
Small examples are fine. The default configuration should remain as a
single .conf file.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
owserMatch was trying to detect. Or maybe this one:
Mozilla/2.0 (compatible; MSIE 3.0; Update a; AK; Windows 95) via proxy
gateway CERN-HTTPD/3.0 libwww/2.17
Given that it appears to be proxied, then I'm betting the keepalive is
totally fine.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
27;t mind
> keeping them if they make up even 1/100 of a percent of the trafic, but it
> seems silly to keep these extra regexes on every single request if these
> clients don't exist anymore in the wild.
I'll take a look at some logs tomorrow, and mail back with some
to handle request spikes
> -# MaxSpareThreads: Maximum number of idle threads per process
> -# MaxRequestsPerChild: Maximum number of connections per server process
> -
> - StartServers 2
> -MinSpareThreads5
> -MaxSpareThreads 10
> -MaxRequestsPerChild0
> -
>
> #
> # Listen: Allows you to bind Apache to specific IP addresses and/or
> @@ -701,9 +601,12 @@
>
> # Supplemental configuration
> #
> -# The configuration files in the extra/ directory can be included
> +# The configuration files in the @relsysconfdir@/extra/ directory can be
> included
> # to add extra features, or you may simply copy their contents
> # here and change as necessary.
> +
> +# Server-Pool Size Regulation (MPM specific)
> +# Include @relsysconfdir@/extra/httpd-mpm.conf
>
> # Multi-language error messages
> # Include @relsysconfdir@/extra/httpd-multilang-error.conf
>
--
Greg Stein, http://www.lyra.org/
nges could involve one
or more of N separate files.
So: given that... I'm very supportive of a smaller default file.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
> continue to use 'Apache.exe' when you look at www.apache.org and
> consider what the foundation's become.
>
> So can I have a quick vote before beta to rename our program to
> 'httpd.exe' on Windows, matching our Unix builds?
>
> Bill
--
Greg Stein, http://www.lyra.org/
or example. It is too invasive with our
APIs. And if it is referring to one of those functions via defining
CORE_PRIVATE, then it rightly deserves a thrashing.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
n a risk of you use them.
If you *do* need something hidden by CORE_PRIVATE, then bring it up along
with a rationale for why that thing should be made public. That's your
best solution.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
;m -1 veto on any config changes that
> require such 'recent' versions. Suggesting this is the best
> version to use is sufficient.
For *who* ??? For developers using source from version control, then
the most recent should be fine. For people using tarballs, it is
totally irrelevant.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
that builds on basic infra that is
located in APR(UTIL).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
am. Apps
will always get coded for one back-end or another. If they are
independent, then they're using the database in very light ways.
That's alright, but it is also very rare. Most apps are very tied to a
database, even if they use a "common API".
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
just left
the darned fp in there. Wasn't worth it to me.
Thanks,
-g
--
Greg Stein, http://www.lyra.org/
-)
But no... if somebody happens to get the desire to fix it by 2.2, then
great. If nobody does, then great.
On Mon, Nov 29, 2004 at 09:19:04PM +0200, Graham Leggett wrote:
> Greg Stein wrote:
>
> >Yes, we can change the API (that was allowed going from 1.3 to 2.0),
> >but w
od_perl is my favorite whipping boy, so it'll serve just fine as a
demo of the problem :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Mon, Nov 29, 2004 at 01:54:18PM -0500, Geoffrey Young wrote:
> Justin Erenkrantz wrote:
> > --On Monday, November 29, 2004 10:41 AM -0800 Greg Stein
> > <[EMAIL PROTECTED]> wrote:
> >
> >> but we were not allowed to remove features. Removing the fp from t
nd take over the parsing
process. That sucks. It means we have to keep exposing a file pointer
(somewhere) if we want to remain feature-compatible.
Yes, we can change the API (that was allowed going from 1.3 to 2.0),
but we were not allowed to remove features. Removing the fp from the
API would have disabled this "feature" in mod_perl, among others.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Mon, Nov 29, 2004 at 04:20:21PM +0100, Andr? Malo wrote:
> * Greg Stein <[EMAIL PROTECTED]> wrote:
>
> > > https://ssl.bulix.org/projects/rici/file/apache/mod_comment.c?rev=49
> >
> > That module uses a feature of the configuration parser that should be
&g
like mod_comment. It uses a feature that I dearly
wish to see removed from httpd.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
he ASF, so it makes some sense for them to
be able to fix things wherever they might be borken.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ink it
should operate.
I'm with Ryan on calling that macro wrong, and just tossing it. We tossed
its use from SVN a long time ago and just relied on the ==0 contract.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
he processes can
see what the "current" state is.
Have you applied much thought to the issue yet?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
x27;t consider it realistic, but that's [just] me.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
necessarily viable.
All the data is there, but the copy requires a "recovery" before it is
useful. Thus, an rsync of the raw files doesn't really work.
Not to mention that the files change even without any commits occurring.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
migrated over
> >>to subversion.
> >
> >I'm +1 on it.
>
> +1. -- justin
Me too!
--
Greg Stein, http://www.lyra.org/
On Fri, Apr 30, 2004 at 11:29:45AM +0530, Amit Athavale wrote:
> Greg Stein wrote:
>...
> >My POV has been (for a LONG while now): the DAV repository is private to
> >the web server and the mod_dav module. Don't let local users near it.
>
> May be DAV ACL is the wa
, and we even
force the package to do extra legawork (-DBIG_SECURITY_HOLE) if they want
that.
So given all the push against running as root, why would the server grow a
lot of functionality to run in that particular mode of operation?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
web server and the mod_dav module. Don't let local users near it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
t WiX be looked at. It might
end up helping things quite a bit.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
e random guy in the Python
community. When Guido replied with, effectively, "oh, shut the hell up.
Greg's contributed more to the Python community than you have (I don't
even know who you are), so you have no standing to harsh on him." Okay,
maybe not that quote, but close enoug
ED] please ignore.
Don't apologize. It is useful information for other people, too.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
about it being a free world, as the
> courts have yet to decide that one.)
>
> Cheers,
> Geoff
>
> PS: Smile, boys will be Boies.
>
> --
> Geoff Thorpe
> [EMAIL PROTECTED]
> http://www.geoffthorpe.net/
--
Greg Stein, http://www.lyra.org/
ing headers).
If code needs to *query* to figure out what is going on, then I would
posit that it has not been correctly hooked into the Apache processing.
If you have a concrete example of something that needs to query the state,
then we can examine whether it should hook into the processing
differently. I bet there is a different hook or approach that can avoid a
query of the state.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
hould the modules be content with the EOC bucket ?
>
> I don't think we'd need a new hook. -- justin
Rather than a finish_connection hook, I'd just suggest that people attach
cleanups to the connection pool.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ith a licence header added to the new file.
>
> I say httpd.
Agreed.
--
Greg Stein, http://www.lyra.org/
.py can build NetWare
build bits for you. I'm not familiar with the NetWare build system, but
will look at those custom Makefiles that you have checked in. We should be
able to do something.
Please let me know where your pain points are now.
Thanks,
-g
--
Greg Stein, http://www.lyra.org/
efile vs dsp)).
The gen-uri-delim was effectively a separate change, and that one forgot
about EBCDIC and also created a pain for Brad's NetWare build.
I'm working on a solution for the former, and have a solution
(to-be-coded) for the latter.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
gen_uri_delims.c (to simplify the overall build process), I had
not thought about EBCDIC. Jeff reminded me, so my fix was to fix apr_uri
rather than poke at the gen-uri stuff.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
On Fri, Feb 20, 2004 at 06:12:07PM +0100, Sander Striker wrote:
> > From: Greg Stein [mailto:[EMAIL PROTECTED]
> > Sent: Friday, February 20, 2004 6:00 PM
>
> > And the notion of "well, now it doesn't build on my platform" is quite
> > suspect. The output
x27;t right: it only
wants SUBDIR/unix/ for when SUBDIR/os2/ is not specified. So I've got some
logic to rework.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
-outputs.mk. Just copy that from *anywhere* to your target platform.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
think that if we ever 'officially' release those modules, we
> can relicense them at that time. -- justin
I'd like to see those modules pulled into one big-ass SVN repository with
all the rest of the HTTPD PMC's code.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
project generates these files, so I intend to follow that model). For now,
it is just starting: it got rid of the recursive make crap. But there is a
lot more that it can do.
So no... switching to a shell script would not be beneficial, as it would
cut off future capabilities.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ny clients are broken, and what
percentage of traffic do they represent? The redirect-carefully was put in
because of a great many, popular clients were borken.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ting it updated.
Thanks,
-g
--
Greg Stein, http://www.lyra.org/
ommits something bad. Everything else is red tape.
Amen, brother!
--
Greg Stein, http://www.lyra.org/
ssibly suspect.
The brigrade structure is allocated in a pool, along with a cleanup. The
*buckets* might get returned to memory when the brigade is cleared, but
the brigade itself won't.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
JAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
Greg Stein, http://www.lyra.org/
sent_pw ? sent_pw : "\'none\'");
>}
Hmm. This is taking input from the request and dropping it right into the
log. I don't recall what our policy is around there. Do we need to escape
it in any way? (e.g. remove newlines)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
ead:1.13 install-tpf.html
That should do the trick. When using 'cvs admin', it isn't a bad idea to
make a backup of the ,v file just in case; a little flub-fingering can
really mess up the file.
(of course, I happen to know a version control system that doesn't allow
people to move ,v files straight out of the Attic ... :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
iler error in Metrowerks. I can #ifdef it based
> > on the compiler or is there a better way?
>
> Revert. I'll live with the warning.
Hm. That isn't ideal either. The problem is that we jam a bunch of
different types of functions into that one slot. The "ideal" is p
ike
size, last modification date, etc.
For metadata, I don't know that you really want to look at mod_dav,
though. Those interfaces are not very clean / easy to figure out. Given
that some metadata is computed on the fly, I would suggest an accessor
function rather than representing metadata as a hash table. To keep the
system general, I would suggest a 'const char *' for the name, and a
binary ptr/len pair for the value.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
so the
reader doesn't mistake the code for a multi-line conditional ]
Note: I'm not desiring to raise a debate or change the style. Merely
supporting the notion that a line of almost-whitespace should occur after
the multi-line conditional.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
he end of a conditional. It isn't as obvious with
your example, but if you have something like:
if (some_function_call(with, arguments, out, the wazoo) ||
another_function_call(with, more, arguments))
{
vs
if (some_function_call(with, arguments, out, the wazoo)
|| another_function_call(with, more, arguments))
{
The latter is much easier to quickly read/parse.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
R_HOOK_MIDDLE);
> #endif
> ap_hook_translate_name(x_translate_handler, NULL, NULL, APR_HOOK_MIDDLE);
> +ap_hook_map_to_storage(x_map_to_storage_handler, NULL,NULL, APR_HOOK_MIDDLE);
> ap_hook_header_parser(x_header_parser_handler, NULL, NULL, APR_HOOK_MIDDLE);
> ap_hook_check_user_id(x_check_user_id, NULL, NULL, APR_HOOK_MIDDLE);
> ap_hook_fixups(x_fixer_upper, NULL, NULL, APR_HOOK_MIDDLE);
--
Greg Stein, http://www.lyra.org/
t even want to know what a woody extension is
I do, and she loves me for it.
:-)
--
Greg Stein, http://www.lyra.org/
On Wed, Sep 10, 2003 at 10:27:42AM -0400, [EMAIL PROTECTED] wrote:
> Greg Stein wrote:
>
> > ap_rput* should be torched as well.
>
> what about simplicity? how many lines of code are required for an alternative?
Yes, the ap_r* functions are a bit simpler for the module auth
> ISTR there was a vote before my time on this issue. Anyone? -- justin
ap_rput* should be torched as well. The filter functions should be used
instead with r->output_filters.
Tossing the ap_rput* functions would also get rid of the OUTPUT_WRITE
filter stuff, which would be quite nice.
Ch
On Sun, Aug 31, 2003 at 09:39:39AM -0700, Justin Erenkrantz wrote:
> I'd like to axe ap_{setup|should|get}_block in future releases (i.e. 2.1+).
+1 ... absolutely zero pushback from this camp :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
he revision history publically available.
It is *totally* fine to make it publically available. Realize that it
is *already* available :-) (via CVS, ViewCVS, and I think rsync)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
est_rec there. How about:
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
"Encountered FakeBasicAuth spoof: %s", username);
Providing the request means that you get more information in the error_log.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
; else wants to do it).
>
> I envision tagging somewhere next (mid) week, following
> release 1 or 2 weeks after that.
>
> I encourage people to take a look at STATUS in the 2.0
> branch to review and vote.
>
> Thanks,
>
> Sander
--
Greg Stein, http://www.lyra.org/
of reason to put non-public stuff into its header.
But still... it wasn't entirely fair to say that mod_rewrite.h was the only
offender :-)
Splitting out a dav_private.h would be very nice...
Now where's that Round Tuit that I had...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
{
> - length += nbytes;
> apr_md5_update(&context, buf, nbytes);
> +nbytes = sizeof(buf);
>}
That indentation looks funny. Did a TAB character get in there?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
core()
>[Joe Schaefer <[EMAIL PROTECTED]>]
>
> In the CVS commit message, put "Brian Pane, Paul J. Reder" in the
> "Reviewed by:" field.
Well, given that Paul committed it, I'd assume the review is implicit :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
. doesn't the caller know when and if he
should clean up? So there shouldn't be a need for a flag...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
> +1. -- justin
+1 here, also.
Altho... I would prefer to see that stuff moved to httpd_private.h and just
not include that file into our public docs (nor install it).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
clear.
>
> Thanks.
>
--
Greg Stein, http://www.lyra.org/
08:29:12AM -0700, Rasmus Lerdorf wrote:
> > > That's what the perchild mpm is for. You can't do this with prefork.
> >
> > perchild is not working.
> > you should use muxmpm instead.
> >
> > cu
--
Greg Stein, http://www.lyra.org/
ropfind, dav_method_report): if the dav
> provider throws an error in the middle of streaming a response, have
> mod_dav log an error and abort the connection.
>...
--
Greg Stein, http://www.lyra.org/
multistatus(ctx.bb, r, HTTP_MULTI_STATUS, doc->namespaces);
> +dav_begin_multistatus(ctx.bb, r, HTTP_MULTI_STATUS, doc ? doc->namespaces :
> NULL);
--
Greg Stein, http://www.lyra.org/
On Wed, Jun 18, 2003 at 12:03:50AM -0700, Justin Erenkrantz wrote:
> --On Tuesday, June 17, 2003 11:49 PM -0700 Greg Stein <[EMAIL PROTECTED]>
> wrote:
>
> >Definitely possible. But we have no better measure to detect that some
> >output has been generated. Once *so
101 - 200 of 583 matches
Mail list logo
