On Thu, Nov 12, 2009 at 09:59, Arturo 'Buanzo' Busleiman
bua...@buanzo.com.ar 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 for their particular
On Thu, Nov 12, 2009 at 11:27, Rich Bowen rbo...@rcbowen.com 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 Wed, Nov 11, 2009 at 14:14, Akins, Brian brian.ak...@turner.com wrote:
On 11/10/09 6:20 PM, Greg Stein gst...@gmail.com 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 properly.
Then take all
On Wed, Nov 11, 2009 at 17:11, Jeff Trawick traw...@gmail.com 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
On Wed, Nov 11, 2009 at 20:09, Jeff Trawick traw...@gmail.com wrote:
On Wed, Nov 11, 2009 at 6:58 PM, Greg Stein gst...@gmail.com wrote:
On Wed, Nov 11, 2009 at 17:11, Jeff Trawick traw...@gmail.com wrote:
At present, whatever was in errno at the time the dav_error {} was
created is treated
On Wed, Nov 11, 2009 at 20:56, Rich Bowen rbo...@rcbowen.com 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
On Wed, Nov 11, 2009 at 15:00, Arturo 'Buanzo' Busleiman
bua...@buanzo.com.ar 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 things like lighttpd
On Wed, Nov 11, 2009 at 23:21, William A. Rowe Jr. wr...@rowe-clan.net 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
On Mon, Nov 9, 2009 at 18:47, Graham Leggett minf...@sharp.fm 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.
On Tue, Nov 10, 2009 at 11:14, Akins, Brian brian.ak...@turner.com wrote:
On 11/9/09 3:08 PM, Greg Stein gst...@gmail.com 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 poll
On Tue, Nov 10, 2009 at 12:01, Jim Jagielski j...@jagunet.com wrote:
On Nov 9, 2009, at 2:19 PM, Akins, Brian wrote:
On 11/9/09 2:06 PM, Greg Stein gst...@gmail.com wrote:
These issues are already solved by moving to a Serf core. It is fully
asynchronous.
Okay that's one convert, any others
On Tue, Nov 10, 2009 at 12:54, Graham Leggett minf...@sharp.fm 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 to say that in this theoretical httpd, the httpd
On Tue, Nov 10, 2009 at 16:33, Lieven Govaerts svn...@mobsol.be wrote:
On Tue, Nov 10, 2009 at 6:10 PM, Greg Stein gst...@gmail.com 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.
Now
On Tue, Nov 10, 2009 at 17:30, Akins, Brian brian.ak...@turner.com wrote:
On 11/10/09 1:56 PM, Greg Stein gst...@gmail.com 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 of network
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 s...@sfritsch.de wrote:
On Friday 23 October 2009, Stefan Fritsch wrote:
On Thursday 22 October 2009, Joe Orton wrote:
Is the performance
On Mon, Nov 9, 2009 at 08:14, s...@apache.org wrote:
Author: sf
Date: Mon Nov 9 13:14:07 2009
New Revision: 834049
URL: http://svn.apache.org/viewvc?rev=834049view=rev
Log:
Make PUT with DAV_MODE_WRITE_TRUNC create a temporary file first and, when the
transfer has been completed
On Mon, Nov 9, 2009 at 08:42, Stefan Fritsch s...@sfritsch.de wrote:
On Monday 09 November 2009, Greg Stein wrote:
On Mon, Nov 9, 2009 at 08:14, s...@apache.org wrote:
Author: sf
Date: Mon Nov 9 13:14:07 2009
New Revision: 834049
URL: http://svn.apache.org/viewvc?rev=834049view=rev
On Mon, Nov 9, 2009 at 14:21, Paul Querna p...@querna.org 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,
On Mon, Nov 9, 2009 at 15:21, Greg Stein gst...@gmail.com wrote:
On Mon, Nov 9, 2009 at 14:46, Stefan Fritsch s...@sfritsch.de 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
On Mon, Nov 9, 2009 at 16:19, Graham Leggett minf...@sharp.fm 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 pull them from a bucket. *Which* bucket
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 graham.dumple...@gmail.com
wrote:
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,
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 bri...@skife.org wrote:
Another suggestion from the lua mailing list, and not a bad one...
On Tue, Dec 16, 2008 at 5:53 PM, Jeff Pohlmeyer
yetanotherg...@gmail.com wrote:
Just a
On Wed, Jan 18, 2006 at 08:01:07PM -0500, Jorey Bump wrote:
...
So, please, take a few moments to decide amongst yourselves who
should have binding votes on mod_python (i.e., who has earned it),
...
I vote that Grisha gets all three votes. Benevolent dictatorship is the
Python way, after all.
on that?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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 totally fine with it, but I think you're a bit late in the cycle
for 2.2. The idea is to close
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/
; 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/
.
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/
separate files.
So: given that... I'm very supportive of a smaller default file.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
/httpd-mpm.conf
# Multi-language error messages
# Include @relsysconfdir@/extra/httpd-multilang-error.conf
--
Greg Stein, http://www.lyra.org/
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 results.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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/
. 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/
that thing should be made public. That's your
best solution.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
recent should be fine. For people using tarballs, it is
totally irrelevant.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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/
(UTIL).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
.
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
removed. The capability of code external
.
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 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 the
API would have disabled this feature
of the problem :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
with it :-)
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 we were not allowed to remove features
--
Greg Stein, http://www.lyra.org/
to fix things wherever they might be borken.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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/
the current state is.
Have you applied much thought to the issue yet?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
, 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/
. -- justin
AOL
Me too!
/AOL
--
Greg Stein, http://www.lyra.org/
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/
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 way to go ?
Nope. That is only about
it.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
end up helping things quite a bit.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
.
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/
--
Greg Stein, http://www.lyra.org/
. It is useful information for other people, too.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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 enough :-)
Cheers,
-g
--
Greg Stein, http
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/
?
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/
file.
I say httpd.
Agreed.
--
Greg Stein, http://www.lyra.org/
I think the people maintaining APR would prefer Python over Perl.
And the notion of well, now it doesn't build on my platform is quite
suspect. The output of the process (run at buildconf time) is
build-outputs.mk. Just copy that from *anywhere* to your target platform.
Cheers,
-g
--
Greg Stein
.
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 of the process (run at buildconf time) is
build
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/
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/
, 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/
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/
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/
the
redirect-carefully variable.
It's a matter of degree. Just how many 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/
--
Greg Stein, http://www.lyra.org/
. 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/
. Everything else is red tape.
Amen, brother!
--
Greg Stein, http://www.lyra.org/
);
}
__
Stas BekmanJAm_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
,
+ 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/
-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/
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 probably a
union of function pointer types.
Cheers,
-g
--
Greg Stein, http
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/
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/
);
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/
, 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/
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 author, but
definitely cause
do, and she loves me for it.
:-)
--
Greg Stein, http://www.lyra.org/
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/
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.
Cheers,
-g
--
Greg Stein, http
it publically available. Realize that it
is *already* available :-) (via CVS, ViewCVS, and I think rsync)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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/
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/
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/
;
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/
]]
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/
--
Greg Stein, http://www.lyra.org/
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/
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/
(ctx.bb, r, HTTP_MULTI_STATUS, doc ? doc-namespaces :
NULL);
--
Greg Stein, http://www.lyra.org/
): 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/
On Tue, Jun 17, 2003 at 11:33:48PM -0700, Justin Erenkrantz wrote:
--On Tuesday, June 17, 2003 7:49 PM -0700 Greg Stein [EMAIL PROTECTED]
wrote:
Hmm. It seems possible that deliver_report could fail before generating any
response. Thus, we want to test what the situation is, and deliver
data, then we need to just bail.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
...
--
Greg Stein, http://www.lyra.org/
. Not sure if the checks allow 1.5 or not. *shrug*
I'm a big +1 on falling back to 1.4.3 for the releases. The 1.5 stuff breaks
third party modules (like SVN) in certain build environments.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
...
Generally, the 64-bit problems that mod_dav has had focus around the dbm
'datum' datatype.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
101 - 200 of 483 matches
Mail list logo
