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 @abcdefghıjklmnopqrstuvwxyz[\]^_`abcdefghijklmnopqrstuvw
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 performance, but not
> correctness.
>
> Well almost but w
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 results are
encouraging:
>>
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
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 [mailto:b...@qqmail.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 alph
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 pro
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]
Se
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 by
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 of
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 it's
> -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 implementatio
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
> the same,
Are y
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 conventions. ;-D
(I do
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
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.
> Unfortunately I don't hav
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 ASCII here
because
we a
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 frameworks
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
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?
> >
> > It is looking for a good name. I'm happy with apr_token_s
> 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 and provenance. Does that
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 p
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 the specs
intended.
>
> I'm so
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 strtolow
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 ti
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 docs. Spent 20 hours
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 pe
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
http://events.linuxfoundation.o
What is the current status? Is this on hold?
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 fully
31 matches
Mail list logo