Re: strcasecmp raises its...
> Am 19.05.2022 um 17:20 schrieb Ruediger Pluem : > > > > On 5/19/22 5:15 PM, Stefan Eissing wrote: >> >> >>> Am 19.05.2022 um 16:44 schrieb Joe Orton : >>> >>> On Wed, May 18, 2022 at 05:34:22PM +0200, Ruediger Pluem wrote: On 5/18/22 4:55 PM, Joe Orton wrote: > I think for httpd it is only safe and sane to run httpd with LANG=C, we > do this in the default service scripts in Fedora/RHEL for a very long > time. Other than the protocol parsing issues you can get in non-C > locales, you can also get "surprises" when sort order can change with > the system locale, impacting e.g. config file load ordering and more. Don't you need a locale sensitive case insensitive string comparison in case of case blind file systems which support extended latin characters? I know these Germans with their Umlaute :-). >>> >>> Heh. Well, I got away with it so far :) >>> > So IMHO it is probably sufficient & simpler to adjust apachectl to set > LANG=C rather than trying to eliminate strcasecmp, and add another > strcasecmp() reimplementation in APR, in this case. We already have this implementation in APR and we use the httpd one which is just a forward port from APR to httpd until we require a sufficient recent APR version in several places. The question is just if we should use them everywhere and thus do the correct thing no matter what locale is set. >>> >>> Ah, I missed that, thanks. >>> >>> +1 from me on doing replacement of strcasecmp() with the >>> locale-insensitive versions then. At least with config options, protocol >>> data, it is definitely right. >>> >> >> +1 from me for replacing our protocol+config handling code with the >> ap_cstr_casecmp(). > > +1. Just to mention: Christophe already did quite some work in this area. Thanks, Christophe. For my understanding: the code in APR for tables uses strcasecmp() and I am probably just too stupid to see where this is redefined? Kind Regards, Stefan > > Regards > > Rüdiger
Re: strcasecmp raises its...
On 5/19/22 5:15 PM, Stefan Eissing wrote: > > >> Am 19.05.2022 um 16:44 schrieb Joe Orton : >> >> On Wed, May 18, 2022 at 05:34:22PM +0200, Ruediger Pluem wrote: >>> On 5/18/22 4:55 PM, Joe Orton wrote: I think for httpd it is only safe and sane to run httpd with LANG=C, we do this in the default service scripts in Fedora/RHEL for a very long time. Other than the protocol parsing issues you can get in non-C locales, you can also get "surprises" when sort order can change with the system locale, impacting e.g. config file load ordering and more. >>> >>> Don't you need a locale sensitive case insensitive string comparison in >>> case of case blind file systems which support extended >>> latin characters? I know these Germans with their Umlaute :-). >> >> Heh. Well, I got away with it so far :) >> So IMHO it is probably sufficient & simpler to adjust apachectl to set LANG=C rather than trying to eliminate strcasecmp, and add another strcasecmp() reimplementation in APR, in this case. >>> >>> We already have this implementation in APR and we use the >>> httpd one which is just a forward port from APR to httpd until we require a >>> sufficient recent APR version in several places. >>> The question is just if we should use them everywhere and thus do the >>> correct thing no matter what locale is set. >> >> Ah, I missed that, thanks. >> >> +1 from me on doing replacement of strcasecmp() with the >> locale-insensitive versions then. At least with config options, protocol >> data, it is definitely right. >> > > +1 from me for replacing our protocol+config handling code with the > ap_cstr_casecmp(). +1. Just to mention: Christophe already did quite some work in this area. Regards Rüdiger
Re: strcasecmp raises its...
> Am 19.05.2022 um 16:44 schrieb Joe Orton : > > On Wed, May 18, 2022 at 05:34:22PM +0200, Ruediger Pluem wrote: >> On 5/18/22 4:55 PM, Joe Orton wrote: >>> I think for httpd it is only safe and sane to run httpd with LANG=C, we >>> do this in the default service scripts in Fedora/RHEL for a very long >>> time. Other than the protocol parsing issues you can get in non-C >>> locales, you can also get "surprises" when sort order can change with >>> the system locale, impacting e.g. config file load ordering and more. >> >> Don't you need a locale sensitive case insensitive string comparison in case >> of case blind file systems which support extended >> latin characters? I know these Germans with their Umlaute :-). > > Heh. Well, I got away with it so far :) > >>> So IMHO it is probably sufficient & simpler to adjust apachectl to set >>> LANG=C rather than trying to eliminate strcasecmp, and add another >>> strcasecmp() reimplementation in APR, in this case. >> >> We already have this implementation in APR and we use the >> httpd one which is just a forward port from APR to httpd until we require a >> sufficient recent APR version in several places. >> The question is just if we should use them everywhere and thus do the >> correct thing no matter what locale is set. > > Ah, I missed that, thanks. > > +1 from me on doing replacement of strcasecmp() with the > locale-insensitive versions then. At least with config options, protocol > data, it is definitely right. > +1 from me for replacing our protocol+config handling code with the ap_cstr_casecmp(). Cheers, Stefan
Re: strcasecmp raises its...
On Wed, May 18, 2022 at 05:34:22PM +0200, Ruediger Pluem wrote: > On 5/18/22 4:55 PM, Joe Orton wrote: > > I think for httpd it is only safe and sane to run httpd with LANG=C, we > > do this in the default service scripts in Fedora/RHEL for a very long > > time. Other than the protocol parsing issues you can get in non-C > > locales, you can also get "surprises" when sort order can change with > > the system locale, impacting e.g. config file load ordering and more. > > Don't you need a locale sensitive case insensitive string comparison in case > of case blind file systems which support extended > latin characters? I know these Germans with their Umlaute :-). Heh. Well, I got away with it so far :) > > So IMHO it is probably sufficient & simpler to adjust apachectl to set > > LANG=C rather than trying to eliminate strcasecmp, and add another > > strcasecmp() reimplementation in APR, in this case. > > We already have this implementation in APR and we use the > httpd one which is just a forward port from APR to httpd until we require a > sufficient recent APR version in several places. > The question is just if we should use them everywhere and thus do the correct > thing no matter what locale is set. Ah, I missed that, thanks. +1 from me on doing replacement of strcasecmp() with the locale-insensitive versions then. At least with config options, protocol data, it is definitely right. Regards, Joe
Re: Which programming language should be used for newly developed modules?
Hi Stefan,
Thank you for the article. I think I will have to give this some more
thought.
In any case, your input has been very helpful!
Best,
Simon
*From:* Stefan Eissing [mailto:ste...@eissing.org]
*Subject:* Which programming language should be used for newly developed
modules?
*Date:* Monday, May 16, 2022, 11:03
*To:* modules-dev@httpd.apache.org
Am 12.05.2022 um 15:41 schrieb Simon Studer:
Hi Stefan,
Thank you for the quick and extensive feedback!
To be honest, I was not expecting there to be so many good reasons not to use
Rust but I think I see your point that it would be difficult to maintain and
that compatibility would absolutely be a concern.
From what I gather most of the problems arise the moment you add the
abstractions and if you do not add such abstractions there is not much reason
to use Rust in the first place.
Golang had been cheered for when I first asked the question. Do you know by any
chance if there would be similar issues with Golang? If not, I might give that
a shot instead.
A good article about (against, actually) about Go and its
shortcomings:https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang
Kind Regards,
Stefan
Best,
Simon
On 5/12/22 12:13, Stefan Eissing wrote:
Hi Simon,
Am 12.05.2022 um 11:28 schrieb Simon Studer:
Hi everyone,
When I read about Apache's use of rustls I thought of this thread again.
For mod_tls, the module itself was written in C linking to the rustls-ffi. I
have been wondering if it would be desirable to implement the modules
themselves in Rust as well and how you would go about doing that. This is
something I have superficially looked into in the past but never really
followed through with.
I looked around and foundhttps://github.com/majorz/apache2-rs which has been
inactive since about 7 years ago. There are also a number of forks which are
more recent but also appear to be inactive and left in an early development
state. There appears to be one fork that has only just been worked on recently
with minor tweaks but it is still the same for the most part.
When I started the work on mod_tls, I was pointed to that abandoned project as well. The
main issue I see in this approach is that one does "duplicate" Apache APIs and
those duplications do not follow any updates/improvements that the server will do over
time. This may lead to various breakages, even when the API is extended in a C-backward
compatible way. This happens quite often in the 2.4.x release line.
Examples of that:
- Adding an enum: if a new HTTP status comes up, the sever adds a definition to its
enums, but the "pub enum Status {...}" (as defined
inhttps://github.com/majorz/apache2-rs/blob/master/src/httpd.rs) would not follow. The
Rust language runtime will panic() if it encounters an enum not properly defined.
– the wrappers inhttps://github.com/majorz/apache2-rs/blob/master/src/ffi.rs do not
follow either and will not account for added fields. Adding fields happens regularly. The
"wrong" size will most likely be problematic in the Copy/Clone traits
To control that, all these definitions would best be done as part of the Apache
httpd project. That would require a serious build-up of Rust competence among
the core developers. It is doubtful, if the existing team is interested in
that. Of course, Rust people who want to make a long-term commitment in the
project would not be turned away. But so far, I do not see any.
Beyond the pure writing code stuff, the target platforms would need to be
managed. Apache runs on architectures which are not supported by Rust.
Also, feedback from linux distributions I got (those may not be representative)
is that they are hesitant to include more Rust components. I have heard of none
that has picked up mod_tls in their package distribution. That hesitation seems
mainly to stem from the fact that Rust regularly re-invents itself and requires
everything to update to the current state of languages and crates. Those are
mostly in 0.x.x versions and APIs do change regularly.
This means that updating a Firefox requires a Rust updated which requires an
update of crates which then might mean other Rust packages will no longer
compile and one has to update them too, if indeed such an update for the
Firefox Rust version is available. etc. etc. This conflicts with any LTS
distribution model.
tl;dr
The update/backward compatibility/dependency handling of Rust and the *nix
world where Apache contributes too are different in vital aspects. This makes
delivery of Rust based modules there difficult. If you do a module just for
your own/organization, this might be fine.
Recently, I have started to implement something similar, mostly to get some
familiarity with the process of using Rust's bindgen tools. The approach I
chose is somewhat different as I generate the FFI with bindgen on the fly
Final reminder: ApacheCon North America call for presentations closing soon
[Note: You're receiving this because you are subscribed to one or more Apache Software Foundation project mailing lists.] This is your final reminder that the Call for Presetations for ApacheCon North America 2022 will close at 00:01 GMT on Monday, May 23rd, 2022. Please don't wait! Get your talk proposals in now! Details here: https://apachecon.com/acna2022/cfp.html --Rich, for the ApacheCon Planners
Final reminder: ApacheCon North America call for presentations closing soon
[Note: You're receiving this because you are subscribed to one or more Apache Software Foundation project mailing lists.] This is your final reminder that the Call for Presetations for ApacheCon North America 2022 will close at 00:01 GMT on Monday, May 23rd, 2022. Please don't wait! Get your talk proposals in now! Details here: https://apachecon.com/acna2022/cfp.html --Rich, for the ApacheCon Planners
Final reminder: ApacheCon North America call for presentations closing soon
[Note: You're receiving this because you are subscribed to one or more Apache Software Foundation project mailing lists.] This is your final reminder that the Call for Presetations for ApacheCon North America 2022 will close at 00:01 GMT on Monday, May 23rd, 2022. Please don't wait! Get your talk proposals in now! Details here: https://apachecon.com/acna2022/cfp.html --Rich, for the ApacheCon Planners
Re: strcasecmp raises its...
On 5/18/22 7:17 PM, Nick Kew wrote: > >> On 18 May 2022, at 16:34, Ruediger Pluem wrote: >> >> Rüdiger > > What locale are YOU in there? Any attempt at locale is going to have to draw > lines: de_DE.UTF-8 > what are the rules for when Ruediger == Rüdiger? There can be none. Because I can transcribe ü to ue , but not every ue is an ü the other way around. Regards Rüdiger
