On Jun 4, 2010, at 4:32 PM, "Akins, Brian"
wrote:
On 6/4/10 7:30 PM, "Paul Querna" wrote:
Are you using LuaJIT 2? The performance numbers its putting up
seemed
very impressive.
Yes and meh...
bummer.
The most iteresting thing in this space since VCL was created is the
devel
On 06/05/2010 12:51 AM, Igor Galić wrote:
Not a terribly interesting read, but we are seriously considering just
using
straight C with some helper functions and macros as the "config" for
one of
our projects.
And, for the record I was wrong in the past - yes, async is the
answer...
I've been
Changing the semantics of Accept-Encoding / Content-Encoding is likely out of
scope for HTTPbis; I have a hard time believing it wouldn't make existing
implementations non-conformant, which we can really only do if there's a
serious security or interoperability concern.
OTOH I think it would be
On 6/4/10 7:30 PM, "Paul Querna" wrote:
> Are you using LuaJIT 2? The performance numbers its putting up seemed
> very impressive.
Yes and meh...
--
Brian Akins
On Fri, Jun 4, 2010 at 3:21 PM, Akins, Brian wrote:
> All of you folks who have to answer user questions, go ahead and ready your
> hate mail :)
>
> I've been playing some with Varnish (long story) and lots of people seem to
> like it. The config "language" (VCL) is just a thin wrapper on top of
> All of you folks who have to answer user questions, go ahead and ready
> your
> hate mail :)
This is not a hate-mail (:
> I've been playing some with Varnish (long story) and lots of people
> seem to
> like it. The config "language" (VCL) is just a thin wrapper on top of
> C.
> Heck, you can
On Jun 4, 2010, at 1:23 PM, Graham Leggett wrote:
> "CTR is fine for all normal fixes. RTC is always preferred for major code
> refactorings."
>
> I ask you this: What constitutes "a modest new feature"? It's not a fix. It's
> not a major code refactoring. But modest new features have been stron
All of you folks who have to answer user questions, go ahead and ready your
hate mail :)
I've been playing some with Varnish (long story) and lots of people seem to
like it. The config "language" (VCL) is just a thin wrapper on top of C.
Heck, you can just write C inline.
Also, I do a good bit w
On Friday 04 June 2010, Stefan Fritsch wrote:
> which are either pure bug fixes or pretty trivial. I will create a
> new patch series without these soon, hopefully tomorrow.
The next iteration is at
http://people.apache.org/~sf/per-module-loglevel-v5/
I have included Rainer's and Joe's correcti
On 6/4/2010 4:47 PM, Stefan Fritsch wrote:
>
> Since we are only initializing a pointer into the module struct, it
> really does not matter if the module_index changes or not. If the
> module is not reloaded, the address of the module struct stays the
> same. If the module is reloaded, the poin
On Friday 04 June 2010, William A. Rowe Jr. wrote:
> This seems to be a very good solution, and the fact that their are
> no constructor-time calls to initialize this should avoid any
> platform quirks.
>
> My only question is; are we assured to have the same module_index
> reassigned on each conf
On 04 Jun 2010, at 6:06 PM, William A. Rowe Jr. wrote:
All individuals are invited to chime in when a proposal is raised,
and to
invest the time in reviewing the proposal. That includes non
committers.
There are no "tiers", except for contributor, committer, and project
committee
member
04.06.2010 16:00, Nick Kew ???(??):
The answer is, yes you can and should use APR pools.
To translate this answer: no, there is no hook invoked, when a module
should clean-up... Thanks.
What about the rest of my question -- about the sequence of post_config
hook invocations?
-mi
On Fri, 04 Jun 2010 15:36:22 -0400
"Mikhail T." wrote:
> My module, at least, is using some external libraries, so I can't rely
> on the apr_pools for clean-ups. How do I know, when to free-up the
> resources I've allocated?
I'm guessing that's the crux of your question.
The answer is, yes yo
Hello!
Various sources suggest, the hook can be called several times -- could
someone summarize those times for the record?
For example, it appears, that upon start-up the hook is called once to
"check the syntax" and then again -- for real. Mod-developers can check
by recording previous inv
On Jun 4, 2010, at 9:07 AM, Igor Galić wrote:
> n.b.: I only have commit on docs, so I couldn't actually put that in place
Committed in r951477. Thanks for going through these.
S.
--
Sander Temme
scte...@apache.org
PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A
> Index: STATUS
> ===
> --- STATUS (revision 951346)
> +++ STATUS (working copy)
> @@ -153,10 +153,10 @@
> it, so that the server won't be slow down too much.
>
>* RFC 2616 violations.
> -Closed PRs: 1
On 6/4/2010 9:35 AM, Graham Leggett wrote:
> On 04 Jun 2010, at 2:51 AM, Jeff Trawick wrote:
>
>>
>> This has been done countless times by numerous people in this
>> successful decade, in spite of, and even for the continued viability
>> of, the C-T-R policy.
>
> This creates an artificial "two t
On Fri, Jun 4, 2010 at 10:35 AM, Graham Leggett wrote:
> On 04 Jun 2010, at 2:51 AM, Jeff Trawick wrote:
>
> +1 for the continued, and perhaps more widespread, voluntary soliciting of
>> approval in advance for changes which add new modules or other significant
>> new function, or make other wid
On 04 Jun 2010, at 4:15 PM, Plüm, Rüdiger, VF-Group wrote:
IMHO it does not (at least according to the comments and the code
looks like
to follow these):
This is only present on trunk, and this needs to be fixed too. The
problem we saw was in httpd v2.2.
implementation (mod_disk_cache)
On 2010-06-04 at 06:00, Igor Galić wrote:
> Hey folks,
>
> I've gone through the list of RFC violation PRs in the STATUS file and here's
> the summary:
Thanks for doing this.
On 2010-06-03 at 22:28, "William A. Rowe Jr." wrote:
> Not because of binary compatibility, but because users have certain
> expectations when they move from x.y.15 to x.y.16 that nothing much
> has changed, it's just lots of fixes. And if your backport ideas
> include a lot of config changes, w
On 04 Jun 2010, at 2:51 AM, Jeff Trawick wrote:
+1 for the continued, and perhaps more widespread, voluntary
soliciting of approval in advance for changes which add new modules
or other significant new function, or make other widespread changes,
or change prerequisites in a meaningful way,
On 04 Jun 2010, at 2:55 AM, William A. Rowe Jr. wrote:
If there is not positive feedback from two reviewers, this code
does not
belong in trunk/. As a committer, you are *free* to create your own
sandboxes in svn to demonstrate code changes, if that helps
attract the
necessary review.
Wh
> -Original Message-
> From: Graham Leggett
> Sent: Freitag, 4. Juni 2010 15:44
> To: dev@httpd.apache.org
> Subject: Re: svn commit: r951222 - in /httpd/httpd/trunk:
> CHANGES modules/cache/mod_disk_cache.c
>
> On 04 Jun 2010, at 7:27 AM, Ruediger Pluem wrote:
>
> > Why is this need
On 04 Jun 2010, at 7:27 AM, Ruediger Pluem wrote:
Why is this needed? mod_cache itself does not allow partial content
to be cached
and even if this does not work it should be fixed there and not in
one of the
storage providers.
mod_cache does allow a 206 to be cached, it is up to the cache
On Fri, Jun 4, 2010 at 6:10 AM, "Plüm, Rüdiger, VF-Group"
wrote:
[...]
> Isn't that what Transfer-Encoding is designed for?
Yes, and in fact if we were talking about a brand new protocol, I'd
probably argue in favor of putting the compression specifier in the
Transfer-Encoding. I think a change
> -Original Message-
> From: Brian Pane [mailto:brianp...@gmail.com]
> Sent: Freitag, 4. Juni 2010 14:39
> To: dev@httpd.apache.org
> Subject: Re: canned deflate conf in manual -- time to drop
> the NS4/vary?
>
> On Fri, Jun 4, 2010 at 2:18 AM, Mark Nottingham wrote:
> [...]
> > It's
On Jun 4, 2010, at 1:58 AM, Ruediger Pluem wrote:
> On 04.06.2010 01:51, Graham Leggett wrote:
>> On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote:
>>
>>> It would be, but it's necessary. The ASF is a collaborative environment;
>>> unreviewed code should not released, even when the author
On Fri, Jun 4, 2010 at 2:18 AM, Mark Nottingham wrote:
[...]
> It's not a bug in the implementations, it's a grey area in 2616 that HTTPbis
> has since worked to resolve;
> http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147
By my reading of the attachments in that ticket, servers (including
On Jun 3, 2010, at 12:58 PM, Stefan Fritsch wrote:
> On Thursday 03 June 2010, Sander Temme wrote:
>> On Jun 3, 2010, at 7:15 AM, Jim Jagielski wrote:
PHP should largely move to FastCGI, so module compatibility
should not be a problem. Any idea about other popular modules?
WSGI?
On Fri, Jun 04, 2010 at 01:40:42PM +0200, "Plüm, Rüdiger, VF-Group" wrote:
> >memset(l->module_levels, val, total_modules +
> > DYNAMIC_MODULE_LIMIT);
>
> Hm, module_levels is int[] and memset works byte wise.
Doh. Sorry, yes, ignore me there.
> -Original Message-
> From: Joe Orton
> Sent: Freitag, 4. Juni 2010 13:29
> To: dev@httpd.apache.org
> Subject: Re: Per-module / per-dir loglevel configuration version 4
>
> On Wed, Jun 02, 2010 at 10:42:44PM +0200, Stefan Fritsch wrote:
> > The patch is at
> >
> > http://people.
On Wed, Jun 02, 2010 at 10:42:44PM +0200, Stefan Fritsch wrote:
> The patch is at
>
> http://people.apache.org/~sf/per-module-loglevel-v4/ ,
This looks good to me. Kudos for taking on such a task. It's kind of
hard to review the individual patches with fixes-on-fixes separated out,
or t
Adam Hasselbalch Hansen wrote:
Thomas, Peter wrote:
-Original Message-
From: Adam Hasselbalch Hansen [mailto:a...@one.com] Sent: Tuesday, May
25, 2010 7:06 AM
To: dev@httpd.apache.org
Subject: Re: mod_ssl, SNI and dynamic virtual hosts
So what I'm attempting to get feedback on is wheth
Hey folks,
I've gone through the list of RFC violation PRs in the STATUS file and here's
the summary:
15852 resolved fixed
15859 resolved fixed
15861 resolved fixed
15864 resolved invalid
15865 resolved remind (must)
15866 new (MUST), looks like it's fixed in trunk
15868 needinfo (MUST)
15869 re
On 04/06/2010, at 6:51 PM, toki...@aol.com wrote:
>
> I think you need to do a reboot on your definition of 'anecdotal'.
Good for you.
> The thread above was a focused discussion about what ACTUALLY
> happens if you try to 'Vary:' on 'User-Agent' in the real world
> these days accompanied by s
> Mark Nottingham wrote...
>
> On 02/06/2010, at 9:00 AM, toki...@aol.com wrote:
>
> > > Sergey wrote...
> > > That's new to me that browsers don't cache stuff that has Vary only on
> > > Accept-Encoding - can you post some statistics or describe the test you
> > > ran?
> >
> > Test results and
38 matches
Mail list logo
