As I read ap_expr, it should be:
diff --git a/modules/proxy/mod_proxy_hcheck.c b/modules/proxy/mod_proxy_hcheck.c
index 1667e77..b211d1c 100644
--- a/modules/proxy/mod_proxy_hcheck.c
+++ b/modules/proxy/mod_proxy_hcheck.c
@@ -987,7 +987,7 @@ static int hc_expr_lookup(ap_expr_lookup_parms *parms)
reak;
Specifically:
*parms->data = NULL;
> On Jan 21, 2016, at 1:08 PM, Jim Jagielski wrote:
>
> That is with:
>
> ProxyHCExpr foof2 {hc('body') !~ /domain is established/}
>
> With
>
> ProxyHCExpr foof2 {kept_body('body') !~ /domain is esta
That is with:
ProxyHCExpr foof2 {hc('body') !~ /domain is established/}
With
ProxyHCExpr foof2 {kept_body('body') !~ /domain is established/}
it works as expected.
Thx!
> On Jan 21, 2016, at 1:06 PM, Jim Jagielski wrote:
>
> I get:
>
>AH001
I get:
AH00102: [Thu Jan 21 18:05:44 2016] file util_expr_eval.c, line 218,
assertion "data != ((void*)0)" failed
> On Jan 21, 2016, at 12:50 PM, Rainer Jung wrote:
>
> Am 21.01.2016 um 17:55 schrieb Jim Jagielski:
>> even better!
>>
>> sounds c
BTW: that is so cool. No idea we could do that w/ ap_expr!
> On Jan 21, 2016, at 12:55 PM, Jim Jagielski wrote:
>
> This implies that the kept_body() func added to ap_expr should
> be removed, right?
>
>> On Jan 21, 2016, at 12:49 PM, rj...@apache.org wrote:
>>
&g
This implies that the kept_body() func added to ap_expr should
be removed, right?
> On Jan 21, 2016, at 12:49 PM, rj...@apache.org wrote:
>
> Author: rjung
> Date: Thu Jan 21 17:49:21 2016
> New Revision: 1726038
>
> URL: http://svn.apache.org/viewvc?rev=1726038&view=rev
> Log:
> Implement expr
even better!
sounds cool.
> On Jan 21, 2016, at 11:51 AM, Rainer Jung wrote:
>
> Am 21.01.2016 um 17:03 schrieb Jim Jagielski:
>> Did you want me to work on it, or are you?
>
> I just had some late lunch and started to think closer about it. Since
> kept_body was
Not seeing a mmn bump... ?
> On Jan 21, 2016, at 11:36 AM, ic...@apache.org wrote:
>
> Author: icing
> Date: Thu Jan 21 16:36:33 2016
> New Revision: 1726009
>
> URL: http://svn.apache.org/viewvc?rev=1726009&view=rev
> Log:
> scoreboard addition of protocol, new ap_udpte_child_status methods
>
Where are we with this? Trunk uses this. Should a backport
proposal be done for 2.4??
Did you want me to work on it, or are you?
> On Jan 21, 2016, at 10:25 AM, Jim Jagielski wrote:
>
> Sounds good to me!!
>
> thx!
>
>> On Jan 21, 2016, at 10:23 AM, Rainer Jung wrote:
>>
>> I should have asked earlier: wouldn't it be more suitab
eck if the backend is healthy or not.
It's totally self-contained.
> On Jan 21, 2016, at 10:29 AM, Yann Ylavic wrote:
>
> Is r->kept_body ever initiallized on the backend side, wouldn't
> mod_proxy need to somehow add mod_request's filters?
>
> On Thu, Jan
Sounds good to me!!
thx!
> On Jan 21, 2016, at 10:23 AM, Rainer Jung wrote:
>
> I should have asked earlier: wouldn't it be more suitable to implement to
> response body as a variable instead of a function?
>
> When looking at server/util_expr_eval.c, I find request_var_names and
> request_v
THX!
> On Jan 21, 2016, at 10:12 AM, Rainer Jung wrote:
>
> Hi Jim,
>
> Am 21.01.2016 um 15:35 schrieb Jim Jagielski:
>> BTW, do you have pointers on how to use your "new" Coccinelle/spatch
>> script to assign AH log numbers?
>
> first I had to
Thx!
BTW, do you have pointers on how to use your "new" Coccinelle/spatch
script to assign AH log numbers?
> On Jan 19, 2016, at 2:44 PM, Rainer Jung wrote:
>
> Am 19.01.2016 um 20:02 schrieb Jim Jagielski:
>> Ahhh... yeah, I guess updating all the usages to do
>&
I think that we should always ensure that mod_status provides the info and
insight that our users want and need, so +1 on adding fields and columns
as required.
It *might* make sense to add them at the end, almost as if we were
adding additional fields to a struct and wanted to maintain an API,
be
Committed revision 1725755.
> On Jan 20, 2016, at 11:37 AM, Jim Jagielski wrote:
>
> Pseudo-patch... that is.
>
>> On Jan 20, 2016, at 11:31 AM, Jim Jagielski wrote:
>>
>> From what I can see, this is the full patch required (minus docs):
>>
>> dif
.
-
+
+ Copyright (C) 1984, 1989-1990, 2000-2015 Free Software Foundation, Inc.
+
> On Jan 20, 2016, at 11:31 AM, Jim Jagielski wrote:
>
> From what I can see, this is the full patch required (minus docs):
>
> diff --git a/server/util_expr_eval.c b/server/util_expr_eval.c
> index 5a8f2
Pseudo-patch... that is.
> On Jan 20, 2016, at 11:31 AM, Jim Jagielski wrote:
>
> From what I can see, this is the full patch required (minus docs):
>
> diff --git a/server/util_expr_eval.c b/server/util_expr_eval.c
> index 5a8f207..e97df88 100644
> --- a/server/util_expr_
NULL, 0 },
#endif
in other words, pretty brain dead easy...
> On Jan 20, 2016, at 11:11 AM, Rainer Jung wrote:
>
> Am 20.01.2016 um 16:28 schrieb Jim Jagielski:
>>
>>> On Jan 20, 2016, at 9:57 AM, Jim Jagielski wrote:
>>>
>>> It would *REALLY
> On Jan 20, 2016, at 9:57 AM, Jim Jagielski wrote:
>
> It would *REALLY* be nice if ap_expr was r->kept_body
> aware.
>
Actually, that does NOT look that difficult...
Comments? Should I go for it?
> I could look at folding that in, but my goal is that all the
> h
ust like blocking back-
ports, especially from people who's 1st and last names have the
same letters :)
> On Jan 20, 2016, at 8:08 AM, Jim Jagielski wrote:
>
>>
>> On Jan 20, 2016, at 7:59 AM, Jim Jagielski wrote:
>>
>>>
>>> On Jan 20, 2016, at 3:34
> On Jan 20, 2016, at 7:59 AM, Jim Jagielski wrote:
>
>>
>> On Jan 20, 2016, at 3:34 AM, Rainer Jung wrote:
>>
>> Am 20.01.2016 um 01:57 schrieb Jim Jagielski:
>>> Right now GET and CPING (as well as provider) is on my
>>> TODO, in fact, they a
> On Jan 20, 2016, at 3:34 AM, Rainer Jung wrote:
>
> Am 20.01.2016 um 01:57 schrieb Jim Jagielski:
>> Right now GET and CPING (as well as provider) is on my
>> TODO, in fact, they are currently set as "unimplemented"
>> although the hooks are there.
>
t's not as "easy" as it
was using ap_expr.
> On Jan 19, 2016, at 5:14 PM, Tim Bannister wrote:
>
> On 19 January 2016 19:01:12 GMT, Jim Jagielski wrote:
>> Okey dokey... this is quite functional at this stage.
>> Right now we have:
>>
>> o TCP he
fwiw, this tested out fine
Thx!
> On Jan 14, 2016, at 10:25 AM, Eric Covener wrote:
>
> Review please? Didn't want unnecessary churn in svn.
>
> http://people.apache.org/~covener/patches/httpd-trunk-cachecontrol.diff
>
> (whitespace not included)
>
> I think the changing meaning of "exp" ov
Ahhh... yeah, I guess updating all the usages to do
that makes sense.
thx!
> On Jan 19, 2016, at 1:59 PM, Ruediger Pluem wrote:
>
>
>
> On 01/19/2016 06:45 PM, Jim Jagielski wrote:
>>
>>> On Jan 19, 2016, at 11:09 AM, Ruediger Pluem wrote:
>>>
Okey dokey... this is quite functional at this stage.
Right now we have:
o TCP health checking (socket up/down)
o HTTP OPTIONS checking
o HTTP HEAD checking
o Support for ap_expr against the response of
the backend for OPTIONS/HEAD
o Ability to add a URI to the worker's path fo
> On Jan 19, 2016, at 11:09 AM, Ruediger Pluem wrote:
>
>> +} else {
>> +if (rv != APR_SUCCESS) {
>> +worker->s->error_time = now;
>> +worker->s->fcount += 1;
>> +if (worker->s->fcount >= worker->s->fails) {
>> +ap_proxy_set_wstatus
Rowe Jr wrote:
>
> On Mon, Jan 18, 2016 at 3:29 PM, Jim Jagielski wrote:
>
> > On Jan 18, 2016, at 3:28 PM, William A Rowe Jr wrote:
> >
> > On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski wrote:
> >
> > > On Jan 14, 2016, at 5:19 PM, William A Rowe
> On Jan 18, 2016, at 3:28 PM, William A Rowe Jr wrote:
>
> On Fri, Jan 15, 2016 at 7:44 AM, Jim Jagielski wrote:
>
> > On Jan 14, 2016, at 5:19 PM, William A Rowe Jr wrote:
> >
> > Good point with your example, this is something that should
> > be benchm
>
> Hm, shouldn't the HC worker use the same setting as the corresponding worker?
> If the workers address is not reusable then worker address might resolve to a
> different IP
> each time it resolves which could cause the HC worker to probe the wrong
> backend.
>
That is a good point... I was
What's currently in trunk is mostly ready for a more
in-depth look-see. Right now, only the tcp check is
complete, with others coming shortly.
Will work on the docs over the weekend.
> On Jan 14, 2016, at 5:19 PM, William A Rowe Jr wrote:
>
>
> Good point with your example, this is something that should
> be benchmarked and the winner-take-all, loser bumped from the
> trunk/ copy of httpd.
-1
You are implying that one would be a winner in all cases. The
whole idea is tha
I'll have some time over the weekend...
> On Jan 14, 2016, at 10:25 AM, Eric Covener wrote:
>
> Review please? Didn't want unnecessary churn in svn.
>
> http://people.apache.org/~covener/patches/httpd-trunk-cachecontrol.diff
>
> (whitespace not included)
>
> I think the changing meaning of "e
> On Jan 13, 2016, at 12:28 PM, William A Rowe Jr wrote:
>
>
> I can see us moving those modules into trunk (not 2.4), retaining the
> mmn tests for 2.2 and 2.4 compat, and then deriving an fcgid release
> out of trunk/modules/fcgid/. But I'm not clear why we would want to
> maintain the dupli
Not just for that, but to make it easier for people
to use it... Seems stable enough that making it a
bundled module makes sense.
> On Jan 13, 2016, at 9:43 AM, Ruediger Pluem wrote:
>
>
>
> On 01/13/2016 01:33 PM, Jim Jagielski wrote:
>> Does it make sense to "offi
Does it make sense to "officially" bundle mod_fcgid w/ httpd?
> On Jan 12, 2016, at 1:13 PM, Rich Bowen wrote:
>
> mod_fcgid is in a separate repo from the main httpd tree, due to
> historical reasons. I presume there are good reasons for this. JimJag
> suggested on IRC it's due to its independe
reate
> this static data in
> each object file separately that includes mod_proxy.h.
>
> Regards
>
> Rüdiger
>
>> -Ursprüngliche Nachricht-
>> Von: Jim Jagielski [mailto:j...@jagunet.com]
>> Gesendet: Montag, 11. Januar 2016 13:43
>> An: dev
I can't recreate that... did you do a clean build?
> On Jan 11, 2016, at 4:56 AM, Ruediger Pluem wrote:
>
>
>
> On 01/10/2016 08:20 PM, j...@apache.org wrote:
>> Author: jim
>> Date: Sun Jan 10 19:20:31 2016
>> New Revision: 1723953
>>
>> URL: http://svn.apache.org/viewvc?rev=1723953&view=rev
en the code, but your previous email said you were thinking of the
> former case.
>
> P.S.
> Thanks for taking this on. It's been on my own todo list for a long time.
>
> --
> Daniel Ruggeri
>
> On 1/8/2016 1:09 PM, Jim Jagielski wrote:
>> Thx! Any other comme
Alternatively, it could use a global extern var and avoid the dup.
> On Jan 8, 2016, at 3:00 PM, Jim Jagielski wrote:
>
> Looks right to me... using the address of a local var is nasty
> and broken and for sure will cause grief.
>
>> On Jan 8, 2016, at 2:30 PM, Christop
Looks right to me... using the address of a local var is nasty
and broken and for sure will cause grief.
> On Jan 8, 2016, at 2:30 PM, Christophe JAILLET
> wrote:
>
> Hi,
>
> not directly related to this discussion, but while looking at mod_mime_magic,
> could someone have a look at:
> http:/
Thx! Any other comments/suggestions?
> On Jan 8, 2016, at 10:53 AM, Eric Covener wrote:
>
> On Fri, Jan 8, 2016 at 10:18 AM, Jim Jagielski wrote:
>> I am thinking about the actual health-check impl a bit more,
>> hence the lack of commits. As noted, initially I was think
It just seems like feature-creep and YetAnotherDirective for
something that is better handled some other way. As OtherBill
notes, a small edit to the magic file "fixes" this.
> On Jan 8, 2016, at 11:16 AM, Yann Ylavic wrote:
>
> On Fri, Jan 8, 2016 at 1:43 PM, Jim Jagiel
I went ahead and committed what was there and ran tests
to make sure it runs clean before doing so.
> On Jan 8, 2016, at 10:48 AM, Yann Ylavic wrote:
>
> On Fri, Jan 8, 2016 at 3:34 PM, Paul Spangler wrote:
>> On 1/8/2016 6:49 AM, Jim Jagielski wrote:
>>>
>&g
Yann, will you be doing that? Backporting the tests from:
https://bz.apache.org/bugzilla/attachment.cgi?id=33187&action=diff
???
> On Jan 8, 2016, at 9:34 AM, Paul Spangler wrote:
>
> On 1/8/2016 6:49 AM, Jim Jagielski wrote:
>> Just noticed that the test framewo
I am thinking about the actual health-check impl a bit more,
hence the lack of commits. As noted, initially I was thinking
about optional functions, defined in mod_proxy_http, mod_proxy_ajp,
etc. Then I started thinking that maybe doing it via providers
might be better, allowing for more "custom" h
Just noticed that the test framework reports issues w/ sessions on trunk:
t/modules/session.t . 1/105 # Failed test 8 in
t/modules/session.t at line 63 fail #2
# Failed test 18 in t/modules/session.t at line 63 fail #4
# Failed test 38 in t/modules/session.t at line 63 fa
-0.9...
This seems a very heavy solution to a specific one-off problem.
> On Jan 8, 2016, at 4:27 AM, Yann Ylavic wrote:
>
> Hi,
>
> On Fri, Jan 8, 2016 at 8:49 AM, Jan Kaluža wrote:
>>
>> Content-Type: application/x-tar
>> Content-Encoding: x-gzip
> []
>>
>> So, the mod_mime_magic is sayin
> On Dec 29, 2015, at 5:14 PM, William A Rowe Jr wrote:
>
>
> Directive names, yes. Directive arguments - not as much.
Yeah... that's what I said. We know our names :)
stores *but does not evaluate* the above expression,
which is called 'rfc1918' (ie: the name of the envvar also serves as the
name/label of the condition).
We can then call:
EvalEnvfIfCond rfc1918
which will then evaluate the expression at *that* time, and
set/unset the 'rfc1918&#
Just a note that I've started committing my mod_proxy health
check module work... it is still a work-in-progress but the
goal is to always ensure that trunk is buildable and usable.
Right now, the module needs to be explicitly enabled during
configuration and all specific health-checks are basicall
> On Dec 29, 2015, at 11:28 AM, Yann Ylavic wrote:
>
> On Tue, Dec 29, 2015 at 5:16 PM, Jim Jagielski wrote:
>> In a sep thread on dev@apr, OtherBill appears to be trying to
>> determine the "right" name for the APR impl... maube we should
>> wait to see
wrote:
>
> On Tue, Dec 29, 2015 at 3:24 PM, Jim Jagielski wrote:
>> ping.
>>
>> Just a reminder that right now, trunk uses ap_casecmpstr[n](),
>> which can make some backport requests "problematic" due to
>> possible merge conflicts.
>
> I&#x
in trunk which is wonky enough that we
don't feel like it's ready for prime-time in 2.4 no matter
what we do (or is simply being ignored).
> On Nov 25, 2015, at 11:17 AM, Jim Jagielski wrote:
>
> What is the current status? Is this on hold?
announced on that list too.
>
> Does it make sense to send the announcement there. Of course it has a unusual
> delay now but some people might rely on that channel for the info.
>
> Regards,
>
> Rainer
>
> Am 14.12.2015 um 21:09 schrieb Jim Jagielski:
>>
Apache HTTP Server 2.4.18 Released
The Apache Software Foundation and the Apache HTTP Server Project
are pleased to announce the release of version 2.4.18 of the Apache
HTTP Server ("Apache"). This version of Apache is our latest GA
release of the new generation 2.4.x branch of Apache
With more than the required 3 +1 (binding) votes, I call
the VOTE closed with the result that the VOTE PASSES.
I will start moving the artifacts so the mirrors can collect
them over the weekend.
> On Dec 8, 2015, at 3:38 PM, Jim Jagielski wrote:
>
> The pre-release test tarballs f
Just a quick reminder that the voting closes in about 90mins.
tia!
> On Dec 8, 2015, at 3:38 PM, Jim Jagielski wrote:
>
> The pre-release test tarballs for Apache httpd 2.4.18 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'
+1:
o OSX 10.11.2, Xcode 7.2: x64
o CentOS6: x64
o CentOS7: x64
> On Dec 8, 2015, at 3:38 PM, Jim Jagielski wrote:
>
> The pre-release test tarballs for Apache httpd 2.4.18 can be found
> at the usual place:
>
> http://httpd.apache.org/dev/dist/
>
> I'
> On Dec 9, 2015, at 2:02 AM, jean-frederic clere wrote:
>
> On 12/03/2015 03:59 PM, Jim Jagielski wrote:
>> I put out a call on Twitter regarding this, but wanted to
>> close the loop here as well.
>>
>> What would *you* like to see as new features or enhancem
> On Dec 8, 2015, at 4:00 PM, Jacob Champion wrote:
>
> On 12/08/2015 12:45 PM, Jim Jagielski wrote:
>> Well
>>
>> We are not NGINX. We are also not Microsoft. We don't create HTTP
>> response codes willy-nilly. We actually try to *honor* the
Well
We are not NGINX. We are also not Microsoft. We don't create HTTP
response codes willy-nilly. We actually try to *honor* the actual
specs.
> On Dec 8, 2015, at 3:22 PM, Jacob Champion wrote:
>
> I wrote this in response to Stefan's note on the zero-length request body
> limit for h2c
The pre-release test tarballs for Apache httpd 2.4.18 can be found
at the usual place:
http://httpd.apache.org/dev/dist/
I'm calling a VOTE on releasing these as Apache httpd 2.4.18 GA.
[ ] +1: Good to go
[ ] +0: meh
[ ] -1: Danger Will Robinson. And why.
Vote will last the normal 72 hr
> On Dec 8, 2015, at 11:11 AM, Yann Ylavic wrote:
>
> On Tue, Dec 8, 2015 at 3:17 PM, Jim Jagielski wrote:
>> My only suggestion is that instead of willy-nilly suggesting
>> patches that will be included in a release, that we actually take
>> time to think of the cor
So what is current (r1718631) is likely what will be tagged and rolled
and, assuming enuff +1s, released.
My only suggestion is that instead of willy-nilly suggesting
patches that will be included in a release, that we actually take
time to think of the correct patch, to implement it and TEST against
it and only THEN have it backported.
Please.
We don't want to put out a semi-immediate 2.4.19 because
This will be happening today, afternoon, eastern time.
> On Dec 7, 2015, at 8:32 AM, Plüm, Rüdiger, Vodafone Group
> wrote:
> So I would go for a pragmatic approach with no sharp line. I guess we can
> bundle all balancers we deliver into one module. IMHO we wouldn't lose
> anything here
In this particular case, I would be +1. They are extremely
> On Dec 5, 2015, at 9:30 PM, William A Rowe Jr wrote:
>
> On Sat, Dec 5, 2015 at 3:48 PM, Jim Jagielski wrote:
>
> > On Dec 4, 2015, at 10:25 AM, William A Rowe Jr wrote:
> >
> > My observation was that that the mapped pages for 2-6 fundamental socache,
>
Can you retry w DEBUG level, to see if h2_response_trailers_filter()
is the issue?
> On Dec 6, 2015, at 6:33 AM, Jan Ehrhardt wrote:
>
> Stefan Eissing in gmane.comp.apache.devel (Sun, 6 Dec 2015 09:26:56 +0100):
>> Jan, thanks for tracking this down to the duplicate headers. I will look
>> in
> On Dec 4, 2015, at 10:25 AM, William A Rowe Jr wrote:
>
> My observation was that that the mapped pages for 2-6 fundamental socache,
> lbmethod or slotmem providers are the same as for a single module due to page
> alignment - load any two and you are already wasting kernel resources and
>
With the latest patches, I think we are in good shape.
With that in mind, I plan to T&R on Tues (Dec 8)
t 7:05 PM, Bert Huijben wrote:
>
>
>
>> -----Original Message-
>> From: Jim Jagielski [mailto:j...@jagunet.com]
>> Sent: donderdag 3 december 2015 22:20
>> To: dev@httpd.apache.org
>> Subject: Re: reverse proxy wishlist
>>
>>
>>> On
illiam A Rowe Jr wrote:
>
> On Thu, Dec 3, 2015 at 3:40 PM, Jim Jagielski wrote:
>
> > On Dec 3, 2015, at 11:09 AM, William A Rowe Jr wrote:
> >
> > My personal wish list is that we eliminate module bloat by coalescing
> > alternative "standard" imple
AM
>> To: dev@httpd.apache.org
>> Subject: AW: reverse proxy wishlist
>>
>> How about an async proxy that frees up the thread while waiting on a slow
>> backend?
>>
>> Regards
>>
>> Rüdiger
>>
>>> -Ursprüngliche Nachricht-
> On Dec 3, 2015, at 11:09 AM, William A Rowe Jr wrote:
>
> My personal wish list is that we eliminate module bloat by coalescing
> alternative "standard" implementations into a single module again in
> 2.next, and not just limited to lbmethod, but also the core socache
> and slotmem providers
> On Dec 3, 2015, at 11:09 AM, William A Rowe Jr wrote:
>
> On Thu, Dec 3, 2015 at 8:59 AM, Jim Jagielski wrote:
>
> What would *you* like to see as new features or enhancements
> w/ mod_proxy, esp reverse proxy.
>
> HTTP/2 support, of course :) It will be i
I put out a call on Twitter regarding this, but wanted to
close the loop here as well.
What would *you* like to see as new features or enhancements
w/ mod_proxy, esp reverse proxy. I was thinking about some
sort of active backend monitoring, utilizing watchdog, which
could also maybe, eventually,
Passes all tests: OSX and CentOS6.
> On Dec 2, 2015, at 9:44 AM, Stefan Eissing
> wrote:
>
> Please find with r1717641 version 1.0.9-DEV of mod_http2 in trunk and
> branches/2.4.x
> that fixes the issue of streams with smallish inputs and lost WINDOW_UPDATEs.
>
> Please report back if this wo
Can you (or someone) provide a test case or explanation of
how to recreate the issue?
tia
> On Nov 30, 2015, at 5:53 PM, Jan Ehrhardt wrote:
>
> Jim Jagielski in gmane.comp.apache.devel (Mon, 30 Nov 2015 07:24:07 -0500):
>> I'm assuming that the brokenness also shows up on trunk,
>> right?
>>
>> Bert, Jan, can you check if trunk shows th
I'm assuming that the brokenness also shows up on trunk,
right?
Bert, Jan, can you check if trunk shows the same behavior?
I would prefer not hacking away on 2.4 directly and independently.
tia!!
> On Nov 29, 2015, at 3:03 AM, Stefan Eissing
> wrote:
>
> Ok, thanks. I think I have an idea of
Hmmm... this seems to me enough to warrant a hold on my T&R
until we dig into this deeper.
Yeah, SVN's 'svn_cstring_casecmp' and how it's used is
pretty much inline with my thoughts on how httpd would
use ours...
> On Nov 25, 2015, at 5:10 PM, Bert Huijben wrote:
>
> We have a set of similar comparison functions in Subversion. I’m pretty sure
> we already had these in the time we sti
ascii? ascii? ascii?
:-)
> On Nov 25, 2015, at 4:52 PM, Christophe JAILLET
> wrote:
>
> Hi,
>
> just in case off, gnome as a set of function g_ascii_...
> (see
> https://developer.gnome.org/glib/2.28/glib-String-Utility-Functions.html#g-ascii-strcasecmp)
>
>>
>> I'm also waiting for fe
In a library that has:
apr_pstrdup()
apr_pstrndup()
apr_pstrmemdup()
and apr_pstrmemdup() and apr_pstrndup() are functionally
the same, as well as:
apr_strnatcasecmp()
apr_strnatcmp()
neither of which use an 'n' variable to determine string
size, yet is c
In general, strcmp() is not implemented via strcmp.c
(although if you do a source code search for strcmp, that's
what you'll get). Most of the time it's implemented in
assembly (strcmp.s) or simply leverages memcmp() where
you aren't doing a byte by byte comparison but are doing
a native memory wor
ll, just arrays of 8bit characters :)
Anyway, that was my final post about the name... at this
point I'd just like to see the actual improvement get completely
folded in and used so we (and our users) can start enjoying the
benefit.
> On Nov 25, 2015, at 2:31 PM, William A Rowe Jr wrote:
> On Nov 25, 2015, at 12:42 PM, William A Rowe Jr wrote:
>
> On Wed, Nov 25, 2015 at 10:17 AM, Jim Jagielski wrote:
> What is the current status? Is this on hold?
>
> It is looking for a good name. I'm happy with apr_token_strcasecmp
> to best indicate its use-case
What is the current status? Is this on hold?
Just a head's up: I intend to T&R 2.4.18 around
Nov 30th...
> On Nov 24, 2015, at 1:11 PM, Yann Ylavic wrote:
>
> On Tue, Nov 24, 2015 at 7:03 PM, Jim Jagielski wrote:
>>
>>> On Nov 24, 2015, at 11:18 AM, Graham Leggett wrote:
>>>
>>> On 24 Nov 2015, at 6:15 PM, Yann Ylavic wrote:
>>
gt;
> On Tue, Nov 24, 2015 at 11:53 AM, Jim Jagielski wrote:
> It's for these types of reasons that I suggest that
> instead of looking at this as some replacement for
> strcasecmp, we instead look at the function on how we
> actually *use* it. As far as I know, we simply use
>
If we really want to squeek out optimizations, judicious use
of 'register' might help even...
But after awhile things start getting silly :)
> On Nov 24, 2015, at 1:04 PM, Yann Ylavic wrote:
>
> I did some testing with different implémentations and my results show
> that fastest one is:
>
> in
+1 (concept)
> On Nov 24, 2015, at 12:40 PM, William A Rowe Jr wrote:
>
> On Tue, Nov 24, 2015 at 10:18 AM, Graham Leggett wrote:
> On 24 Nov 2015, at 6:15 PM, Yann Ylavic wrote:
>
> > Not sure:
> >if (!strcmp(h, "max-age")
> >|| ap_cmpcasestr(h, "max-age"))
> > is likely to be a
> On Nov 24, 2015, at 11:18 AM, Graham Leggett wrote:
>
> On 24 Nov 2015, at 6:15 PM, Yann Ylavic wrote:
>
>> Not sure:
>> if (!strcmp(h, "max-age")
>> || ap_cmpcasestr(h, "max-age"))
>> is likely to be a bit faster than a single ap_cmpcasestr() when it
>> matches, but much slower when
It's for these types of reasons that I suggest that
instead of looking at this as some replacement for
strcasecmp, we instead look at the function on how we
actually *use* it. As far as I know, we simply use
it to see if 2 strings are equal, ignoring ASCII case.
I could be wrong, and I'm sure someo
> On Nov 24, 2015, at 10:28 AM, Eric Covener wrote:
>
> On Tue, Nov 24, 2015 at 10:21 AM, Jim Jagielski wrote:
>> For these types of paths, where we use a switch/case against
>> the 1st char of the token, the real reason why we used that
>> impl was to avoid the
ne it to be more
sensible ;)
Like you said, we aren't creating a replacement clib, so creating
funcs for our own specific usecase does make some sense.
> On Nov 24, 2015, at 10:15 AM, William A Rowe Jr wrote:
>
> On Tue, Nov 24, 2015 at 6:35 AM, Jim Jagielski wrote:
> Yeah, but n
901 - 1000 of 4750 matches
Mail list logo
