[ANNOUNCE] CFP open for ApacheCon North America 2016

Community growth starts by talking with those interested in your project. ApacheCon North America is coming, are you? We are delighted to announce that the Call For Presentations (CFP) is now open for ApacheCon North America. You can submit your proposed sessions at

apr_token_* conclusions (was: Better casecmpstr[n]?)

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 and provenance. Does that work for everyone? It is looking for clearer

Re: Better ap_casecmpstr[n]?

What is the current status? Is this on hold?

[ANNOUNCE] CFP open for ApacheCon North America 2016

Community growth starts by talking with those interested in your project. ApacheCon North America is coming, are you? We are delighted to announce that the Call For Presentations (CFP) is now open for ApacheCon North America. You can submit your proposed sessions at

2.4.18 and mod_http2

With the latest checkin into 2.4.x mod_http2 has everything I want for the 2.4.18 release. Tests work for me here on OS X and Ubuntu, so I hope this will be fine. Tomorrow I hopefully will find the time to make a blog about the upcoming changes in 2.4.18 re HTTP/2 and Apache httpd. Make some

[ANNOUNCE] CFP open for ApacheCon North America 2016

Community growth starts by talking with those interested in your project. ApacheCon North America is coming, are you? We are delighted to announce that the Call For Presentations (CFP) is now open for ApacheCon North America. You can submit your proposed sessions at

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On 25.11.2015 18:21, Bert Huijben wrote: > That Turkish ‘I’ problem is the only case I know of where the > collation actually changes behavior within the usual western alphabet > of ASCII characters. Argh, yes, I see now, what the problem would be... Thank you, -mi

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Nov 25, 2015 4:19 PM, "Mikhail T." wrote: > > >> >> So, the concern is, some hypothetical header, such as X-ASSIGN-TO may, after going through the locale-aware strtolower() unexpectedly become x-aßign-to? > > I just tested the above on both FreeBSD and Linux, and the

RE: apr_token_* conclusions (was: Better casecmpstr[n]?)

The example was the other way around. Changing SS to ß is not a valid transform, but the other way is. There are also transforms on the combined AE characters, etc. That Turkish ‘I’ problem is the only case I know of where the collation actually changes behavior within the usual western

RE: apr_token_* conclusions (was: Better casecmpstr[n]?)

See http://www.siao2.com/2004/12/03/274288.aspx And http://www.siao2.com/2013/04/04/10407543.aspx For some background and related bugs in several products. I hope this blog will stay alive. (The author passed away recently) Bert From: Bert Huijben

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 6:45 PM, William A Rowe Jr wrote: > On Nov 25, 2015 4:19 PM, "Mikhail T." wrote: > > > > Thus, I contend, using C-library will not cause invalid results, and the > only reason to have Apache's own implementation is

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 9:44 PM, William A Rowe Jr wrote: > LANG="ku_TR.iso88599"; >64 = @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ > ^ @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`ABCDEFGHİJKLMNOPQRSTUVWXYZ{|}~ > v

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 1:12 PM, Jim Jagielski 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? > > > >

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On 25.11.2015 12:42, William A Rowe Jr wrote: > If the script switches setlocale to turkish, for example, our > forced-lowercase content-type conversion > will cause "IMAGE/GIF" to become "ımage/gıf", clearly not what the > specs intended. I'm sorry, could you elaborate on this? Would not

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On 25.11.2015 13:16, William A Rowe Jr wrote: > > Two variables, LC_CTYPE and LC_COLLATE control this text processing > behavior. The above is the correct lower case transliteration for > Turkish. In German, the upper case correspondence of sharp-S ß is > 'SS', but multi-char translation is not

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

> 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

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

My point is that we use it to compare, for example, "FoobARski!" with "foOBArsKi!", not "Ébana?" with "ébana?" or "ebana?" In that way I mean "ascii" Heck, we may as well say that we really aren't comparing "strings" at all, just arrays of 8bit characters :) Anyway, that was my final post about

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Nov 25, 2015 12:00, "Mikhail T." wrote: > > On 25.11.2015 12:42, William A Rowe Jr wrote: >> >> If the script switches setlocale to turkish, for example, our forced-lowercase content-type conversion >> will cause "IMAGE/GIF" to become "ımage/gıf", clearly not what

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 1:50 PM, Jim Jagielski wrote: > My point is that we use it to compare, for example, > "FoobARski!" with "foOBArsKi!", not "Ébana?" with "ébana?" or "ebana?" > > In that way I mean "ascii" > But that isn't precisely what you wrote. It happens to be

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

Le 25/11/2015 22:02, Jim Jagielski a écrit : 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

RE: apr_token_* conclusions (was: Better casecmpstr[n]?)

We have a set of similar comparison functions in Subversion. I’m pretty sure we already had these in the time we still had ebcdic support on trunk. (We removed that support years ago, but the code should still live on a branch) Bert From: William A Rowe Jr [mailto:wr...@rowe-clan.net]

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On 25.11.2015 14:10, Mikhail T. wrote: >> >> Two variables, LC_CTYPE and LC_COLLATE control this text processing >> behavior. The above is the correct lower case transliteration for >> Turkish. In German, the upper case correspondence of sharp-S ß is >> 'SS', but multi-char translation is not

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 2:06 PM, Jacob Champion wrote: > My two cents: I agree that another "name mangled" abbreviation is not > particularly helpful, but I also agree with Jim's concern: "apr_token" made > me immediately wonder what made this exclusive to HTTP tokens. >

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

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

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Nov 25, 2015 1:10 PM, "Jim Jagielski" wrote: > ... I think we are WAY overthinking naming here. I overthink naming constantly, so there's an excellent chance that you're absolutely correct! That said... your list only ended up convincing me that APR needs better naming

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

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 feedback about the naming convention, I'd like to get this into APR yesterday and start building on it, but

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

My two cents: I agree that another "name mangled" abbreviation is not particularly helpful, but I also agree with Jim's concern: "apr_token" made me immediately wonder what made this exclusive to HTTP tokens. Unfortunately I don't have much of an alternative suggestion. I have seen other

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 3:52 PM, Christophe JAILLET < christophe.jail...@wanadoo.fr> 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 > ) Interesting, does anyone know

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

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

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 3:10 PM, Jim Jagielski wrote: > In a library that has: > > apr_pstrdup() > apr_pstrndup() > apr_pstrmemdup() > which are all semantically and mechanically different... > and apr_pstrmemdup() and apr_pstrndup() are functionally

RE: H2 stream dependencies

> -Original Message- > From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Sent: woensdag 25 november 2015 10:05 > To: dev@httpd.apache.org > Subject: Re: H2 stream dependencies > > The execution order of requests is not defined by the protocol and up to the > server

Re: 2.4.18 and mod_http2

On Wed, Nov 25, 2015 at 11:35 AM, Stefan Eissing < stefan.eiss...@greenbytes.de> wrote: > With the latest checkin into 2.4.x mod_http2 has everything I want for the > 2.4.18 release. Tests work for me here on OS X and Ubuntu, so I hope this > will be fine. > > Tomorrow I hopefully will find the

Re: H2 stream dependencies

The execution order of requests is not defined by the protocol and up to the server implementation. As you noticed, one major factor is the mpm active in httpd, influencing how, and if, requests are handled in parallel. Even setting dependencies and priorities on streams will not make this