On 03/14/2007 09:14 PM, Jim Jagielski wrote:
> As a rough proof of concept, I refactored the design,
Ahh, and I was wondering myself why I could not find Joe's
concerns. I read your refactored code :-).
> allowing for the pattern matching and substitution to be
> done as soon as we have a "line
On Wed, Mar 14, 2007 at 06:38:48PM +, Nick Kew wrote:
> Now, what leads you to suppose mod_line_edit uses RAM proportional
> to content size? Other than when the entire contents arrive in a
> single bucket?
Because it implements the naive filter implementation, equivalent to:
e = APR_BRIGADE
As a rough proof of concept, I refactored the design,
allowing for the pattern matching and substitution to be
done as soon as we have a "line". Also is some
rough ability to pass the data to the next filter
after we get more than ~AP_MIN_BYTES_TO_WRITE bytes.
Doesn't alleviate all the problems, b
On 3/14/07, Nick Kew <[EMAIL PROTECTED]> wrote:
to content size? Other than when the entire contents arrive in a
single bucket?
Uh, a file bucket? -- justin
On Wed, 14 Mar 2007 16:56:41 +
Joe Orton <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 14, 2007 at 03:45:05PM +, Nick Kew wrote:
> > Nope. Just one brigades worth at a time. And the most likely case
> > for that to be an entire document is when it's a static file, and
> > document == brigade
On Wed, Mar 14, 2007 at 03:45:05PM +, Nick Kew wrote:
> Nope. Just one brigades worth at a time. And the most likely case
> for that to be an entire document is when it's a static file, and
> document == brigade == bucket.
I'm not sure what you're saying here. Which do you agree with:
a) s
On Wed, 14 Mar 2007 11:15:00 -0400
Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> On Mar 14, 2007, at 11:01 AM, Nick Kew wrote:
>
> > Oh, I guess you mean the copying to get a null-terminated string
> > when applying a regexp? And I see it's repeated for every regexp
> > (ouch)! mod_line_edit us
On Wed, 14 Mar 2007 15:27:44 +
Joe Orton <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 14, 2007 at 03:01:53PM +, Nick Kew wrote:
> > On Wed, 14 Mar 2007 14:32:13 +
> > Joe Orton <[EMAIL PROTECTED]> wrote:
> >
> > > 1) the filtering logic is broken and will consume RAM
> > > proportional to
On Wed, Mar 14, 2007 at 03:01:53PM +, Nick Kew wrote:
> On Wed, 14 Mar 2007 14:32:13 +
> Joe Orton <[EMAIL PROTECTED]> wrote:
>
> > 1) the filtering logic is broken and will consume RAM proportional to
> > response size.
>
> I must've missed that when I looked. I thought it used the
> s
On Mar 14, 2007, at 11:01 AM, Nick Kew wrote:
Oh, I guess you mean the copying to get a null-terminated string
when applying a regexp? And I see it's repeated for every regexp
(ouch)! mod_line_edit uses a local pool which is cleared at the
end of each brigade, and avoids multiple copies of th
On Wed, 14 Mar 2007 14:32:13 +
Joe Orton <[EMAIL PROTECTED]> wrote:
> 1) the filtering logic is broken and will consume RAM proportional to
> response size.
I must've missed that when I looked. I thought it used the
same logic as mod_line_edit, which is very careful about that.
Oh, I guess
On Tue, Mar 13, 2007 at 09:24:25AM -0400, Jim Jagielski wrote:
> There have been times when having a simple sed filter in Apache
> would be useful... I used to use just ext_filter to do this,
> but this got more and more painful the more I used it. So awhile
> ago I made mod_sed_filter which I find
On Wed, 14 Mar 2007 13:45:47 +
Nick Kew <[EMAIL PROTECTED]> wrote:
> As for the particular case Frank asked for, that works by
> expanding the union to include a function pointer alongside
> the strmatch and regexp cases. So it's also a per-rule
> configuration flag, and never touches the co
On Wed, 14 Mar 2007 09:25:11 -0400
Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> On Mar 14, 2007, at 5:07 AM, Frank wrote:
>
> >
> > RewriteBodyLine 'http://(.*?)/(.*)/(.*)' 'http://${LOWERCASE:$1}/$
> > {MD5:$2}/$3'
> >
>
> Yeah, that would be useful... Of course, the main issue is
> that wher
On Mar 14, 2007, at 5:07 AM, Frank wrote:
RewriteBodyLine 'http://(.*?)/(.*)/(.*)' 'http://${LOWERCASE:$1}/$
{MD5:$2}/$3'
Yeah, that would be useful... Of course, the main issue is
that whereas mod_rewrite can afford to be dog slow, because,
after all, the URLs aren't *that* big, in-place
On Wed, 14 Mar 2007 10:07:49 +0100
Frank <[EMAIL PROTECTED]> wrote:
> Just wanted to add my two cents worth...
>
> We are using mod_line_edit a lot and would like to see a similar
> functionality coming with Apache by default. :-)
Sounds like a vote.
> When I am correct mod_line_edit has the '
Just wanted to add my two cents worth...
We are using mod_line_edit a lot and would like to see a similar
functionality coming with Apache by default. :-)
When I am correct mod_line_edit has the 'wrong' license model for being
included into Apache by default.
Just for your infomation: There
On Mar 13, 2007, at 3:34 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
On Mar 13, 2007, at 1:10 PM, William A. Rowe, Jr. wrote:
Is this sed or pcre syntax? I'm a bit confused :)
It's a mutant ;) But, of course, we maintain
that confusion internally with regex's being pcre...
Of
Jim Jagielski wrote:
>
> On Mar 13, 2007, at 1:10 PM, William A. Rowe, Jr. wrote:
>
>>
>> Is this sed or pcre syntax? I'm a bit confused :)
>
> It's a mutant ;) But, of course, we maintain
> that confusion internally with regex's being pcre...
Of course :) But it appears to be a tiny fraction
Jim Jagielski wrote:
>
> Bill told me about mod_line_edit maybe 3-4 days ago.
> I had known about mod_proxy_html, which is also something
> we've pointed clients to, so maybe that's where
> the confusion comes from.
Good point - in my experience mod_proxy_html is much more broadly
adopted both by
On Mar 13, 2007, at 2:08 PM, Nick Kew wrote:
AFAICS, this not merely looks like mod_line_edit: the filter *is*
mod_line_edit, right down to the bucket manipulation logic used as
an example in The Book! It's just missing a couple of minor features,
and has a slightly different configuration sy
Nick Kew wrote:
>
> I'm even more confused now, because I thought you were with Covalent,
> and I understood from Will that mod_line_edit was widely used by
> clients of Covalent. Please tell me what I'm missing?
Just to ensure I'm not misquoted, I know I've suggested mod_line_edit
to a few Cova
On Tue, 13 Mar 2007 13:34:07 -0400
Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> On Mar 13, 2007, at 1:10 PM, William A. Rowe, Jr. wrote:
>
> >
> > Is this sed or pcre syntax? I'm a bit confused :)
> >
>
> It's a mutant ;) But, of course, we maintain
> that confusion internally with regex's bei
On Mar 13, 2007, at 1:10 PM, William A. Rowe, Jr. wrote:
Is this sed or pcre syntax? I'm a bit confused :)
It's a mutant ;) But, of course, we maintain
that confusion internally with regex's being pcre...
Although it's sed-ish, is it misleading to confuse the user with the
phrase sed con
Jim Jagielski wrote:
> Anyone mind if I fold it into trunk and maybe have us
> consider making it part of 2.2 (even under experimental)?
+1 to trunk! No opinion yet on 2.2 (I'm not a big fan of growing
the stable branch since it entirely defeats the drive to release
2.next, ever.)
> No docs yet
On Tue, 13 Mar 2007 09:24:25 -0400
Jim Jagielski <[EMAIL PROTECTED]> wrote:
> http://people.apache.org/~jim/code/mod_sed_filter.c
At a glance, it looks like mod_line_edit.
Are you doing anything different?
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://
There have been times when having a simple sed filter in Apache
would be useful... I used to use just ext_filter to do this,
but this got more and more painful the more I used it. So awhile
ago I made mod_sed_filter which I find pretty useful. I've just
built and tested in with 2.2 and trunk...
A
27 matches
Mail list logo
