Menu
▾
▴
naviserver-devel — Developer discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(53) |
Mar
(62) |
Apr
(88) |
May
(55) |
Jun
(204) |
Jul
(52) |
Aug
|
Sep
(1) |
Oct
(94) |
Nov
(15) |
Dec
(68) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(130) |
Feb
(105) |
Mar
(34) |
Apr
(61) |
May
(41) |
Jun
(92) |
Jul
(176) |
Aug
(102) |
Sep
(247) |
Oct
(69) |
Nov
(32) |
Dec
(140) |
| 2007 |
Jan
(58) |
Feb
(51) |
Mar
(11) |
Apr
(20) |
May
(34) |
Jun
(37) |
Jul
(18) |
Aug
(60) |
Sep
(41) |
Oct
(105) |
Nov
(19) |
Dec
(14) |
| 2008 |
Jan
(3) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(123) |
Jun
(5) |
Jul
(1) |
Aug
(29) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(3) |
| 2009 |
Jan
|
Feb
(36) |
Mar
(29) |
Apr
|
May
|
Jun
(7) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(13) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(9) |
Apr
(11) |
May
(16) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(92) |
Nov
(28) |
Dec
(16) |
| 2013 |
Jan
(9) |
Feb
(2) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(6) |
Jul
(14) |
Aug
(12) |
Sep
(4) |
Oct
(13) |
Nov
(1) |
Dec
(6) |
| 2014 |
Jan
(23) |
Feb
(19) |
Mar
(10) |
Apr
(14) |
May
(11) |
Jun
(6) |
Jul
(11) |
Aug
(15) |
Sep
(41) |
Oct
(95) |
Nov
(23) |
Dec
(11) |
| 2015 |
Jan
(3) |
Feb
(9) |
Mar
(19) |
Apr
(3) |
May
(1) |
Jun
(3) |
Jul
(11) |
Aug
(1) |
Sep
(15) |
Oct
(5) |
Nov
(2) |
Dec
|
| 2016 |
Jan
(7) |
Feb
(11) |
Mar
(8) |
Apr
(1) |
May
(3) |
Jun
(17) |
Jul
(12) |
Aug
(3) |
Sep
(5) |
Oct
(19) |
Nov
(12) |
Dec
(6) |
| 2017 |
Jan
(30) |
Feb
(23) |
Mar
(12) |
Apr
(32) |
May
(27) |
Jun
(7) |
Jul
(13) |
Aug
(16) |
Sep
(6) |
Oct
(11) |
Nov
|
Dec
(12) |
| 2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(7) |
May
(23) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(10) |
Dec
(3) |
| 2019 |
Jan
(26) |
Feb
(15) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(14) |
Jul
(10) |
Aug
(10) |
Sep
(4) |
Oct
(2) |
Nov
(20) |
Dec
(10) |
| 2020 |
Jan
(10) |
Feb
(14) |
Mar
(29) |
Apr
(11) |
May
(25) |
Jun
(21) |
Jul
(23) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(8) |
Dec
(12) |
| 2021 |
Jan
(29) |
Feb
(9) |
Mar
(8) |
Apr
(8) |
May
(2) |
Jun
(2) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(4) |
Nov
(12) |
Dec
(13) |
| 2022 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(15) |
Jun
(7) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(8) |
Dec
|
| 2023 |
Jan
(15) |
Feb
|
Mar
(23) |
Apr
(1) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(22) |
Sep
(19) |
Oct
(2) |
Nov
(20) |
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
(16) |
Apr
(15) |
May
(6) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(18) |
Dec
(6) |
| 2025 |
Jan
(12) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
(5) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Gustaf N. <ne...@wu...> - 2023-01-05 06:08:47
|
Dear Wolfgang, The HTML Living Standard allows the greater than sign inside single or double quoted attribute values, so i would regard the old behavior as a bug (i think to remember that at a certain time, one had to use entities for these). With the change, all old test continue to work, although the testing set is not very extensive. Please test. https://bitbucket.org/naviserver/naviserver/commits/6f7b322d0f45daa2154d702ca763442bb2be9fac all the best from Maui, -gustaf On 04.01.23 15:19, Wolfgang Winkler via naviserver-devel wrote: > > Hello! > > When we try to use custom tags with attributes, we encounter a problem > when passing html strings, e.g: > > proc::dummy_tag_proc {params} { > return[ns_set array$params] > } > ns_adp_registerscript dummy_tag ::dummy_tag_proc > > <dummy_tag title="<i class='fal fa-link'></i>"> > > Outputs: > > title {"<i class='fal fa-icon'>} > > Everything after the first ">" is truncated. Is there a safe way to > prevent this behaviour? > > Regards, > > Wolfgang > > -- > > *Wolfgang Winkler* > Geschäftsführung > wol...@di... > mobil +43.699.19971172 > > dc:*büro* > digital concepts Novak Winkler OG > Software & Design > Landstraße 68, 5. Stock, 4020 Linz > www.digital-concepts.com <http://www.digital-concepts.com> > tel +43.732.997117.72 > tel +43.699.1997117.2 > > Firmenbuchnummer: 192003h > Firmenbuchgericht: Landesgericht Linz > > > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel -- Univ.Prof. Dr. Gustaf Neumann Head of the Institute of Information Systems and New Media of Vienna University of Economics and Business Program Director of MSc "Information Systems" |
|
From: Brian F. <bri...@ai...> - 2023-01-04 19:33:19
|
Hi Wolfgang I think that you need to use the endtag optional parameter to ns_adp_registerscript i.e. see https://naviserver.sourceforge.io/n/naviserver/files/ns_adp_register.html Brian ________________________________ From: Wolfgang Winkler via naviserver-devel <nav...@li...> Sent: Wednesday 4 January 2023 2:19 pm To: Navidevel <nav...@li...> Cc: Wolfgang Winkler <wol...@di...> Subject: [naviserver-devel] ns_adp_registerproc and attributes Hello! When we try to use custom tags with attributes, we encounter a problem when passing html strings, e.g: proc ::dummy_tag_proc {params} { return [ns_set array $params] } ns_adp_registerscript dummy_tag ::dummy_tag_proc <dummy_tag title="<i class='fal fa-link'></i>"> Outputs: title {"<i class='fal fa-icon'>} Everything after the first ">" is truncated. Is there a safe way to prevent this behaviour? Regards, Wolfgang -- Wolfgang Winkler Geschäftsführung wol...@di...<mailto:wol...@di...> mobil +43.699.19971172 dc:büro digital concepts Novak Winkler OG Software & Design Landstraße 68, 5. Stock, 4020 Linz www.digital-concepts.com<http://www.digital-concepts.com> tel +43.732.997117.72 tel +43.699.1997117.2 Firmenbuchnummer: 192003h Firmenbuchgericht: Landesgericht Linz [https://www.digital-concepts.com/cu/digitalconcepts2016/images/logo_digitalconcepts2016.png] |
|
From: Brian F. <bri...@ai...> - 2023-01-04 17:55:05
|
Hi Wolfgang
oh yes, I understand better now that your issue is with the HTML being included in the tag attributes. Nothing to do with endtags.
Are you sure you proc is correct? Maybe try something like this:
proc ::dummy_tag_proc {params} {
set title [ns_set get $params title]
return "My title is $title"
}
Brian
________________________________
From: Wolfgang Winkler via naviserver-devel <nav...@li...>
Sent: Wednesday 4 January 2023 3:20 pm
To: Navidevel <nav...@li...>
Cc: Wolfgang Winkler <wol...@di...>
Subject: Re: [naviserver-devel] ns_adp_registerproc and attributes
Hi Brian!
With the closing tag, it's possible to create custom tags like:
<dummy_tag title="<h1>My Title</h1>">
<p>Output this text</p>
</dummy_tag>
and proc ::dummy_tag_proc {params inner_html} {
...
}
The inner_html parameter works fine, but the attribute values will be truncated as well, if a ">" sign is encountered.
Regards,
Wolfgang
Am 04.01.23 um 15:57 schrieb Brian Fenton:
Hi Wolfgang
I think that you need to use the endtag optional parameter to ns_adp_registerscript i.e. see https://naviserver.sourceforge.io/n/naviserver/files/ns_adp_register.html
Brian
________________________________
From: Wolfgang Winkler via naviserver-devel <nav...@li...><mailto:nav...@li...>
Sent: Wednesday 4 January 2023 2:19 pm
To: Navidevel <nav...@li...><mailto:nav...@li...>
Cc: Wolfgang Winkler <wol...@di...><mailto:wol...@di...>
Subject: [naviserver-devel] ns_adp_registerproc and attributes
Hello!
When we try to use custom tags with attributes, we encounter a problem when passing html strings, e.g:
proc ::dummy_tag_proc {params} {
return [ns_set array $params]
}
ns_adp_registerscript dummy_tag ::dummy_tag_proc
<dummy_tag title="<i class='fal fa-link'></i>">
Outputs:
title {"<i class='fal fa-icon'>}
Everything after the first ">" is truncated. Is there a safe way to prevent this behaviour?
Regards,
Wolfgang
--
Wolfgang Winkler
Geschäftsführung
wol...@di...<mailto:wol...@di...>
mobil +43.699.19971172
dc:büro
digital concepts Novak Winkler OG
Software & Design
Landstraße 68, 5. Stock, 4020 Linz
www.digital-concepts.com<http://www.digital-concepts.com>
tel +43.732.997117.72
tel +43.699.1997117.2
Firmenbuchnummer: 192003h
Firmenbuchgericht: Landesgericht Linz
[https://www.digital-concepts.com/cu/digitalconcepts2016/images/logo_digitalconcepts2016.png]
--
Wolfgang Winkler
Geschäftsführung
wol...@di...<mailto:wol...@di...>
mobil +43.699.19971172
dc:büro
digital concepts Novak Winkler OG
Software & Design
Landstraße 68, 5. Stock, 4020 Linz
www.digital-concepts.com<http://www.digital-concepts.com>
tel +43.732.997117.72
tel +43.699.1997117.2
Firmenbuchnummer: 192003h
Firmenbuchgericht: Landesgericht Linz
[https://www.digital-concepts.com/cu/digitalconcepts2016/images/logo_digitalconcepts2016.png]
|
|
From: Wolfgang W. <wol...@di...> - 2023-01-04 15:20:51
|
Hi Brian!
With the closing tag, it's possible to create custom tags like:
<dummy_tag title="<h1>My Title</h1>">
<p>Output this text</p>
</dummy_tag>
and proc ::dummy_tag_proc {params inner_html} {
...
}
The inner_html parameter works fine, but the attribute values will be
truncated as well, if a ">" sign is encountered.
Regards,
Wolfgang
Am 04.01.23 um 15:57 schrieb Brian Fenton:
> Hi Wolfgang
>
> I think that you need to use the endtag optional parameter to
> ns_adp_registerscript i.e. see
> https://naviserver.sourceforge.io/n/naviserver/files/ns_adp_register.html
>
> Brian
> ------------------------------------------------------------------------
> *From:* Wolfgang Winkler via naviserver-devel
> <nav...@li...>
> *Sent:* Wednesday 4 January 2023 2:19 pm
> *To:* Navidevel <nav...@li...>
> *Cc:* Wolfgang Winkler <wol...@di...>
> *Subject:* [naviserver-devel] ns_adp_registerproc and attributes
>
> Hello!
>
> When we try to use custom tags with attributes, we encounter a problem
> when passing html strings, e.g:
>
> proc::dummy_tag_proc {params} {
> return[ns_set array$params]
> }
> ns_adp_registerscript dummy_tag ::dummy_tag_proc
>
> <dummy_tag title="<i class='fal fa-link'></i>">
>
> Outputs:
>
> title {"<i class='fal fa-icon'>}
>
> Everything after the first ">" is truncated. Is there a safe way to
> prevent this behaviour?
>
> Regards,
>
> Wolfgang
>
> --
>
> *Wolfgang Winkler*
> Geschäftsführung
> wol...@di...
> <mailto:wol...@di...>
> mobil +43.699.19971172
>
> dc:*büro*
> digital concepts Novak Winkler OG
> Software & Design
> Landstraße 68, 5. Stock, 4020 Linz
> www.digital-concepts.com <http://www.digital-concepts.com>
> tel +43.732.997117.72
> tel +43.699.1997117.2
>
> Firmenbuchnummer: 192003h
> Firmenbuchgericht: Landesgericht Linz
>
>
--
*Wolfgang Winkler*
Geschäftsführung
wol...@di...
mobil +43.699.19971172
dc:*büro*
digital concepts Novak Winkler OG
Software & Design
Landstraße 68, 5. Stock, 4020 Linz
www.digital-concepts.com <http://www.digital-concepts.com>
tel +43.732.997117.72
tel +43.699.1997117.2
Firmenbuchnummer: 192003h
Firmenbuchgericht: Landesgericht Linz
|
|
From: Wolfgang W. <wol...@di...> - 2023-01-04 14:35:10
|
Hello!
When we try to use custom tags with attributes, we encounter a problem
when passing html strings, e.g:
proc::dummy_tag_proc {params} {
return[ns_set array$params]
}
ns_adp_registerscript dummy_tag ::dummy_tag_proc
<dummy_tag title="<i class='fal fa-link'></i>">
Outputs:
title {"<i class='fal fa-icon'>}
Everything after the first ">" is truncated. Is there a safe way to
prevent this behaviour?
Regards,
Wolfgang
--
*Wolfgang Winkler*
Geschäftsführung
wol...@di...
mobil +43.699.19971172
dc:*büro*
digital concepts Novak Winkler OG
Software & Design
Landstraße 68, 5. Stock, 4020 Linz
www.digital-concepts.com <http://www.digital-concepts.com>
tel +43.732.997117.72
tel +43.699.1997117.2
Firmenbuchnummer: 192003h
Firmenbuchgericht: Landesgericht Linz
|
|
From: Gustaf N. <ne...@wu...> - 2022-11-28 18:10:59
|
Hi Brian, many thanks for the patch, added on bitbucket! all the best -g https://bitbucket.org/naviserver/nsstats/commits/7c8e69db4e83458f10bb8212b4111a60023d6693 On 28.11.22 17:49, Brian Fenton wrote: > Hello > > I just tried the latest version of nsstats.tcl from > https://bitbucket.org/naviserver/nsstats/src/main/ > I have to say I love this tool, but in the latest version the Process > page is giving an error because our version of Naviserver doesn't > support "ns_conn details". |
|
From: Brian F. <bri...@ai...> - 2022-11-28 17:03:52
|
Hello I just tried the latest version of nsstats.tcl from https://bitbucket.org/naviserver/nsstats/src/main/ I have to say I love this tool, but in the latest version the Process page is giving an error because our version of Naviserver doesn't support "ns_conn details". I have patched as follows: try { set connect_info [ns_conn details] if {$connect_info ne ""} { append version_info ", connected via [ns_conn details]" } append version_info " from client [ns_conn peeraddr]" } on error {errmsg} { ns_log Notice "This version of Naviserver doesn't support ns_conn details: $errmsg" } regards Brian |
|
From: THORPE M. <ta...@me...> - 2022-11-08 13:46:16
|
Hi Gustaf, It just occurred to me that my comment about OpenSSL not being automatically configured by Naviserver was inappropriate. I was certainly not complaining and I completely understand that things change. My apologies. What that remark suggested was not my intention. Thorpe > On Nov 8, 2022, at 00:37, Gustaf Neumann <ne...@wu...> wrote: > > From your original mail, i got the impression that you hand no "issues" with NaviServer either, but you are wondering, why OpenSSL 3.* is not "picked up automatically" and still linked against OpenSSL 1.*. Since there are many differences between OpenSSL 1.* and 3.* [1], many distributors do not replace the 1.* version upon installation of OpenSSL 3.* , but they install it side by side, simply to avoid problems (there are many API changes, see e.g. [2,3]). So, no all software compiled against the include files of OpenSSL 1.* will work out of the box with OpenSSL 3.* > > Coming to my questions of the last mail: > - against which library is your nsd linked? > - have you reconfigured and recompiled naviserver? > > let me know, if i can be of any further help. > > -g > > [1] https://www.openssl.org/docs/man3.0/man7/migration_guide.html > [2] https://packages.debian.org/bullseye/amd64/libssl1.1/filelist > [3] https://packages.debian.org/bookworm/amd64/libssl3/filelist > > On 07.11.22 14:52, THORPE MAYES via naviserver-devel wrote: >> Hi Gustaf, >> >> Thank you for your response and the information. >> >> I did not have any issues with previous OpenSSL updates, although I had not installed 3.x versions. >> >> Best regards. >> >> Thorpe >> >> Thorpe Mayes >> (512) 394-8766 >> >>> On 6 Nov 2022, at 11:34, Gustaf Neumann <ne...@wu...> <mailto:ne...@wu...> wrote: >>> Dear Thorpe, >>> it looks like you have now two versions of openssl installed on your system, since the output "1.0.2k-fips" comes straight from the library. So, if you see this string, the library is still there. >>> >>> One can check the version used during linkage via >>> >>> ldd /usr/local/ns/bin/nsd >>> >>> When upgrading to OpenSSL 3.*, it is recommended to recompile NaviServer >>> (make clean, configure ..., make, make install) such that NaviServer can use >>> the newer library calls. When the path to the openssl libary is not specified >>> explicitly, configure uses "pkg-config --libs openssl" to determine the >>> path the the library. >>> >>> all the best >>> >>> -g >>> >>> PS Btw, OpenACS.org runs with OpenSSL 3.2.0-dev >>> >>> On 06.11.22 13:47, THORPE MAYES via naviserver-devel wrote: >>>> Hi, >>>> >>>> I updated OpenSSL on my server to version 3.0.7. >>>> >>>> Prior to updating, openssl version -a showed: >>>> >>>> OpenSSL 1.0.2k-fips 26 Jan 2017 >>>> built on: reproducible build, date unspecified >>>> platform: linux-x86_64 >>>> options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) >>>> compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM >>>> OPENSSLDIR: "/etc/pki/tls" >>>> engines: rdrand dynamic >>>> >>>> After updating, openssl version -a showed: >>>> >>>> OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022) >>>> built on: Sat Nov 5 14:56:48 2022 UTC >>>> platform: linux-x86_64 >>>> options: bn(64,64) >>>> compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG >>>> OPENSSLDIR: "/etc/ssl" >>>> ENGINESDIR: "/etc/ssl/lib64/engines-3" >>>> MODULESDIR: "/etc/ssl/lib64/ossl-modules" >>>> Seeding source: os-specific >>>> CPUINFO: OPENSSL_ia32cap=0xfffa3203478bffff:0x7a9 >>>> >>>> When I restart naviserver I see this in the log file: >>>> >>>> Notice: OpenSSL OpenSSL 1.0.2k-fips 26 Jan 2017 initialized >>>> >>>> That is the previous version of OpenSSL on the server. >>>> >>>> What do I need to change in order for naviserver to use the current version of OpenSSL? Or, does it matter? >>>> >>>> When I updated to naviserver version 4.99.24 my configuration was: >>>> ./configure --prefix=/usr/local/ns --with-tcl=/usr/local/ns/lib --enable-symbols >>>> >>>> >>>> Thorpe > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: THORPE M. <ta...@me...> - 2022-11-08 10:50:07
|
Hi Gustaf, Thank you for your followup. I have reconfigured and recompiled naviserver. I do not think I have any issues there. I have been able to update naviserver without any problems. I installed openssl 3..0.7 again. The test showed a couple of errors. Very likely an issue. I am using CentOS - 7. That could very well be an issue. I created a server using RockyLinux version 9.x. An earlier version of openssl 3.0 was already installed. I installed openssl 3.0.7. No errors. I stopped there for the moment. I will get a new server running using RockyLinux 9.x. That may very well solve my problem. If not, at least I will be working from a clean start. You have been very helpful. Thank you. Best regards, Thorpe > On Nov 8, 2022, at 00:37, Gustaf Neumann <ne...@wu...> wrote: > > From your original mail, i got the impression that you hand no "issues" with NaviServer either, but you are wondering, why OpenSSL 3.* is not "picked up automatically" and still linked against OpenSSL 1.*. Since there are many differences between OpenSSL 1.* and 3.* [1], many distributors do not replace the 1.* version upon installation of OpenSSL 3.* , but they install it side by side, simply to avoid problems (there are many API changes, see e.g. [2,3]). So, no all software compiled against the include files of OpenSSL 1.* will work out of the box with OpenSSL 3.* > > Coming to my questions of the last mail: > - against which library is your nsd linked? > - have you reconfigured and recompiled naviserver? > > let me know, if i can be of any further help. > > -g > > [1] https://www.openssl.org/docs/man3.0/man7/migration_guide.html > [2] https://packages.debian.org/bullseye/amd64/libssl1.1/filelist > [3] https://packages.debian.org/bookworm/amd64/libssl3/filelist > > On 07.11.22 14:52, THORPE MAYES via naviserver-devel wrote: >> Hi Gustaf, >> >> Thank you for your response and the information. >> >> I did not have any issues with previous OpenSSL updates, although I had not installed 3.x versions. >> >> Best regards. >> >> Thorpe >> >> Thorpe Mayes >> (512) 394-8766 >> >>> On 6 Nov 2022, at 11:34, Gustaf Neumann <ne...@wu...> <mailto:ne...@wu...> wrote: >>> Dear Thorpe, >>> it looks like you have now two versions of openssl installed on your system, since the output "1.0.2k-fips" comes straight from the library. So, if you see this string, the library is still there. >>> >>> One can check the version used during linkage via >>> >>> ldd /usr/local/ns/bin/nsd >>> >>> When upgrading to OpenSSL 3.*, it is recommended to recompile NaviServer >>> (make clean, configure ..., make, make install) such that NaviServer can use >>> the newer library calls. When the path to the openssl libary is not specified >>> explicitly, configure uses "pkg-config --libs openssl" to determine the >>> path the the library. >>> >>> all the best >>> >>> -g >>> >>> PS Btw, OpenACS.org runs with OpenSSL 3.2.0-dev >>> >>> On 06.11.22 13:47, THORPE MAYES via naviserver-devel wrote: >>>> Hi, >>>> >>>> I updated OpenSSL on my server to version 3.0.7. >>>> >>>> Prior to updating, openssl version -a showed: >>>> >>>> OpenSSL 1.0.2k-fips 26 Jan 2017 >>>> built on: reproducible build, date unspecified >>>> platform: linux-x86_64 >>>> options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) >>>> compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM >>>> OPENSSLDIR: "/etc/pki/tls" >>>> engines: rdrand dynamic >>>> >>>> After updating, openssl version -a showed: >>>> >>>> OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022) >>>> built on: Sat Nov 5 14:56:48 2022 UTC >>>> platform: linux-x86_64 >>>> options: bn(64,64) >>>> compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG >>>> OPENSSLDIR: "/etc/ssl" >>>> ENGINESDIR: "/etc/ssl/lib64/engines-3" >>>> MODULESDIR: "/etc/ssl/lib64/ossl-modules" >>>> Seeding source: os-specific >>>> CPUINFO: OPENSSL_ia32cap=0xfffa3203478bffff:0x7a9 >>>> >>>> When I restart naviserver I see this in the log file: >>>> >>>> Notice: OpenSSL OpenSSL 1.0.2k-fips 26 Jan 2017 initialized >>>> >>>> That is the previous version of OpenSSL on the server. >>>> >>>> What do I need to change in order for naviserver to use the current version of OpenSSL? Or, does it matter? >>>> >>>> When I updated to naviserver version 4.99.24 my configuration was: >>>> ./configure --prefix=/usr/local/ns --with-tcl=/usr/local/ns/lib --enable-symbols >>>> >>>> >>>> Thorpe > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Gustaf N. <ne...@wu...> - 2022-11-08 05:37:50
|
From your original mail, i got the impression that you hand no "issues" with NaviServer either, but you are wondering, why OpenSSL 3.* is not "picked up automatically" and still linked against OpenSSL 1.*. Since there are many differences between OpenSSL 1.* and 3.* [1], many distributors do not replace the 1.* version upon installation of OpenSSL 3.* , but they install it side by side, simply to avoid problems (there are many API changes, see e.g. [2,3]). So, no all software compiled against the include files of OpenSSL 1.* will work out of the box with OpenSSL 3.* Coming to my questions of the last mail: - against which library is your nsd linked? - have you reconfigured and recompiled naviserver? let me know, if i can be of any further help. -g [1] https://www.openssl.org/docs/man3.0/man7/migration_guide.html [2] https://packages.debian.org/bullseye/amd64/libssl1.1/filelist [3] https://packages.debian.org/bookworm/amd64/libssl3/filelist On 07.11.22 14:52, THORPE MAYES via naviserver-devel wrote: > Hi Gustaf, > > Thank you for your response and the information. > > I did not have any issues with previous OpenSSL updates, although I > had not installed 3.x versions. > > Best regards. > > Thorpe > > Thorpe Mayes > (512) 394-8766 > >> On 6 Nov 2022, at 11:34, Gustaf Neumann <ne...@wu...> wrote: >> Dear Thorpe, >> >> it looks like you have now two versions of openssl installed on your >> system, since the output "1.0.2k-fips" comes straight from the >> library. So, if you see this string, the library is still there. >> >> One can check the version used during linkage via >> >> ldd /usr/local/ns/bin/nsd >> >> When upgrading to OpenSSL 3.*, it is recommended to recompile NaviServer >> (make clean, configure ..., make, make install) such that NaviServer >> can use >> the newer library calls. When the path to the openssl libary is not >> specified >> explicitly, configure uses "pkg-config --libs openssl" to determine the >> path the the library. >> >> all the best >> >> -g >> >> PS Btw, OpenACS.org runs with OpenSSL 3.2.0-dev >> >> On 06.11.22 13:47, THORPE MAYES via naviserver-devel wrote: >>> Hi, >>> >>> I updated OpenSSL on my server to version 3.0.7. >>> >>> Prior to updating, openssl version -a showed: >>> >>> OpenSSL 1.0.2k-fips 26 Jan 2017 >>> built on: reproducible build, date unspecified >>> platform: linux-x86_64 >>> options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) >>> idea(int) blowfish(idx) >>> compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB >>> -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT >>> -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 >>> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 >>> -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack >>> -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT >>> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM >>> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM >>> -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM >>> OPENSSLDIR: "/etc/pki/tls" >>> engines: rdrand dynamic >>> >>> After updating, openssl version -a showed: >>> >>> OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022) >>> built on: Sat Nov 5 14:56:48 2022 UTC >>> platform: linux-x86_64 >>> options: bn(64,64) >>> compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 >>> -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC >>> -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG >>> OPENSSLDIR: "/etc/ssl" >>> ENGINESDIR: "/etc/ssl/lib64/engines-3" >>> MODULESDIR: "/etc/ssl/lib64/ossl-modules" >>> Seeding source: os-specific >>> CPUINFO: OPENSSL_ia32cap=0xfffa3203478bffff:0x7a9 >>> >>> When I restart naviserver I see this in the log file: >>> >>> Notice: OpenSSL OpenSSL 1.0.2k-fips 26 Jan 2017 initialized >>> >>> >>> That is the previous version of OpenSSL on the server. >>> >>> What do I need to change in order for naviserver to use the current >>> version of OpenSSL? Or, does it matter? >>> >>> When I updated to naviserver version 4.99.24 my configuration was: >>> ./configure --prefix=/usr/local/ns --with-tcl=/usr/local/ns/lib >>> --enable-symbols >>> >>> >>> Thorpe |
|
From: THORPE M. <ta...@me...> - 2022-11-07 13:53:19
|
Hi Gustaf, Thank you for your response and the information. I did not have any issues with previous OpenSSL updates, although I had not installed 3.x versions. Best regards. Thorpe Thorpe Mayes (512) 394-8766 > On 6 Nov 2022, at 11:34, Gustaf Neumann <ne...@wu...> wrote: > > > Dear Thorpe, > > it looks like you have now two versions of openssl installed on your system, since the output "1.0.2k-fips" comes straight from the library. So, if you see this string, the library is still there. > > One can check the version used during linkage via > > ldd /usr/local/ns/bin/nsd > > When upgrading to OpenSSL 3.*, it is recommended to recompile NaviServer > (make clean, configure ..., make, make install) such that NaviServer can use > the newer library calls. When the path to the openssl libary is not specified > explicitly, configure uses "pkg-config --libs openssl" to determine the > path the the library. > > all the best > > -g > > PS Btw, OpenACS.org runs with OpenSSL 3.2.0-dev > > On 06.11.22 13:47, THORPE MAYES via naviserver-devel wrote: >> Hi, >> >> I updated OpenSSL on my server to version 3.0.7. >> >> Prior to updating, openssl version -a showed: >> >> OpenSSL 1.0.2k-fips 26 Jan 2017 >> built on: reproducible build, date unspecified >> platform: linux-x86_64 >> options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) >> compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM >> OPENSSLDIR: "/etc/pki/tls" >> engines: rdrand dynamic >> >> After updating, openssl version -a showed: >> >> OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022) >> built on: Sat Nov 5 14:56:48 2022 UTC >> platform: linux-x86_64 >> options: bn(64,64) >> compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG >> OPENSSLDIR: "/etc/ssl" >> ENGINESDIR: "/etc/ssl/lib64/engines-3" >> MODULESDIR: "/etc/ssl/lib64/ossl-modules" >> Seeding source: os-specific >> CPUINFO: OPENSSL_ia32cap=0xfffa3203478bffff:0x7a9 >> >> When I restart naviserver I see this in the log file: >> >> Notice: OpenSSL OpenSSL 1.0.2k-fips 26 Jan 2017 initialized >> >> That is the previous version of OpenSSL on the server. >> >> What do I need to change in order for naviserver to use the current version of OpenSSL? Or, does it matter? >> >> When I updated to naviserver version 4.99.24 my configuration was: >> ./configure --prefix=/usr/local/ns --with-tcl=/usr/local/ns/lib --enable-symbols >> >> >> Thorpe > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Gustaf N. <ne...@wu...> - 2022-11-06 16:34:00
|
Dear Thorpe, it looks like you have now two versions of openssl installed on your system, since the output "1.0.2k-fips" comes straight from the library. So, if you see this string, the library is still there. One can check the version used during linkage via ldd /usr/local/ns/bin/nsd When upgrading to OpenSSL 3.*, it is recommended to recompile NaviServer (make clean, configure ..., make, make install) such that NaviServer can use the newer library calls. When the path to the openssl libary is not specified explicitly, configure uses "pkg-config --libs openssl" to determine the path the the library. all the best -g PS Btw, OpenACS.org runs with OpenSSL 3.2.0-dev On 06.11.22 13:47, THORPE MAYES via naviserver-devel wrote: > Hi, > > I updated OpenSSL on my server to version 3.0.7. > > Prior to updating, openssl version -a showed: > > OpenSSL 1.0.2k-fips 26 Jan 2017 > built on: reproducible build, date unspecified > platform: linux-x86_64 > options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) > idea(int) blowfish(idx) > compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB > -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT > -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 > -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY > -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM > -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM > -DGHASH_ASM -DECP_NISTZ256_ASM > OPENSSLDIR: "/etc/pki/tls" > engines: rdrand dynamic > > After updating, openssl version -a showed: > > OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022) > built on: Sat Nov 5 14:56:48 2022 UTC > platform: linux-x86_64 > options: bn(64,64) > compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 > -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC > -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG > OPENSSLDIR: "/etc/ssl" > ENGINESDIR: "/etc/ssl/lib64/engines-3" > MODULESDIR: "/etc/ssl/lib64/ossl-modules" > Seeding source: os-specific > CPUINFO: OPENSSL_ia32cap=0xfffa3203478bffff:0x7a9 > > When I restart naviserver I see this in the log file: > > Notice: OpenSSL OpenSSL 1.0.2k-fips 26 Jan 2017 initialized > > > That is the previous version of OpenSSL on the server. > > What do I need to change in order for naviserver to use the current > version of OpenSSL? Or, does it matter? > > When I updated to naviserver version 4.99.24 my configuration was: > ./configure --prefix=/usr/local/ns --with-tcl=/usr/local/ns/lib > --enable-symbols > > > Thorpe |
|
From: THORPE M. <ta...@me...> - 2022-11-06 12:47:36
|
Hi, I updated OpenSSL on my server to version 3.0.7. Prior to updating, openssl version -a showed: OpenSSL 1.0.2k-fips 26 Jan 2017 built on: reproducible build, date unspecified platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/etc/pki/tls" engines: rdrand dynamic After updating, openssl version -a showed: OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022) built on: Sat Nov 5 14:56:48 2022 UTC platform: linux-x86_64 options: bn(64,64) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG OPENSSLDIR: "/etc/ssl" ENGINESDIR: "/etc/ssl/lib64/engines-3" MODULESDIR: "/etc/ssl/lib64/ossl-modules" Seeding source: os-specific CPUINFO: OPENSSL_ia32cap=0xfffa3203478bffff:0x7a9 When I restart naviserver I see this in the log file: Notice: OpenSSL OpenSSL 1.0.2k-fips 26 Jan 2017 initialized That is the previous version of OpenSSL on the server. What do I need to change in order for naviserver to use the current version of OpenSSL? Or, does it matter? When I updated to naviserver version 4.99.24 my configuration was: ./configure --prefix=/usr/local/ns --with-tcl=/usr/local/ns/lib --enable-symbols Thorpe |
|
From: Gustaf N. <ne...@wu...> - 2022-10-15 11:42:18
|
Dear all,
The "main" branch of NaviServer contains no more detailed version
numbers to ease orientation, especially, when many installations are
managed. The nstats process page contains now the OS, architecture,
Tcl-version and the version of the OpenSSL library in use. The only
interesting part missing is now the version of the Database (when in
use), but that requires changes in the parent-driver of nsdb, where the
concrete db-drivers have to report the information...
All the best
-gn
Provide introspection features for network driver
- ns_driver info: return in the resulting dict the additional field
"libraryversion", which is supplied by network driver. This is at
least useful for new installations and debugging, to make sure,
which library is actually used
- "ns_conn details": new sub-command, returning a dict provided by a
driver callback concerning the current connection. For an HTTPS
connection, it returns the result of protocol and cipher
negotiation, like e.g.
{sslversion TLSv1.3 cipher TLS_AES_256_GCM_SHA384}
--
Univ.Prof. Dr. Gustaf Neumann
Head of the Institute of Information Systems and New Media
of Vienna University of Economics and Business
Program Director of MSc "Information Systems"
|
|
From: Gustaf N. <ne...@wu...> - 2022-08-21 10:36:37
|
Dear all, The NaviServer source code repository is now set up to run a CI/CD testing pipeline on every commit on the main and release/4.99 branches. Since the free version of Bitbucket, where the repository is hosted, allows only limited resources (50 minutes per month), the commits are now forwarded to a GitHub mirror repository [1], which is more permissive (2000 minutes per month, but not only for NaviServer). The CI/CD testing pipeline is built around docker images. On every run, we fetch ubuntu-latest, the necessary build-environment, Tcl sources, Tcllib, NSF, tDom, libthread, NaviServer, the PostgreSQL client library, and the nsdbpg module. Once everything is compiled successfully, the NaviServer regression test is performed (currently 1900 tests). This pipeline is just the initial version, more modules should be added in the future. For the main and the release/4.99 branches, currently we test with two different compilers (gcc-10 and gcc-11), two Tcl versions (8.6.12 and 8.7-a5), two versions of NSF/XOTcl (2.3.0 and 2.4.0) and with two different tDom versions (0.9.1 and 0.9.3): - os: ubuntu-latest compiler: gcc-10 tcltag: core-8-6-12 nsf_version: 2.3.0 tdom_version: 0.9.1 - os: ubuntu-latest compiler: gcc-11 tcltag: core-8-7-a5 nsf_version: 2.4.0 tdom_version: 0.9.3 You can see the results of these runs under [2]. Note that the naviserver-mirror repository is just set up for the testing pipeline. All development continues to happen on Bitbucket. All the best -gustaf neumann [1] https://github.com/nm-wu/naviserver-mirror [2] https://github.com/nm-wu/naviserver-mirror/actions |
|
From: Gustaf N. <ne...@wu...> - 2022-08-07 13:29:10
|
Dear all, The default branch of NaviServer was changed from "master" to "main". I have done this for the "naviserver" main repository and for the 51 modules below. Fresh checkouts are now on the branch "main", old checkouts should switch to the main branch after a "git pull" with: git branch main Since git 2.28, one can also change the default branch with the built-in git command: git config --global init.defaultBranch main We were actually quite late with this change. Details for the main branch reaming are here: https://dev.to/lukeocodes/change-git-s-default-branch-from-master-19le All the best -g Changed modules: letsencrypt nsaccess nsaspell nsauthpam nschartdir nsclamav nscoap nsconf nsdbbdb nsdbi nsdbilite nsdbimy nsdbipg nsdbmysql nsdbpg nsdbsqlite nsdbtds nsdhcpd nsdns nsexample nsexpat nsfortune nsgdchart nsicmp nsimap nsldap nsldapd nsloopctl nsmemcache nsocaml nsodbc nsoracle nsphp nsradiusd nsrtsp nssavi nsshell nssip nssmtpd nssnmp nsstats nssys nssyslogd nstftpd nstk nsudp nsvfs nswebpush nszlib revproxy websocket |
|
From: Oscar R. F. <oro...@vr...> - 2022-07-20 21:10:10
|
I didn't know that.
It seems that most browsers are quite benevolent parsing this with
wrong space character encoding.
I have to update my code.
Thank you very much!
-----Mensaje original-----
De: Gustaf Neumann <ne...@wu...>
Responder a: nav...@li...
Para: nav...@li...
Asunto: Re: [naviserver-devel] ns_returnfile return original file
name
Fecha: Wed, 20 Jul 2022 22:08:05 +0200
Dear Oscar,
In principle, you are right concerning the encoding. A few comments:
- on most browsers, also utf-8 filenames are accepted,
but the use of UTF-8 in the header fields is not recommended.
- For the percent encoding, one should use "ns_urlencode -path",
e.g.,
ns_urlencode -part path {£ and € rates}
since the "ns_urlencode" without parameters (as in your example)
uses a special rule for the space character.
One should actually provide an API along the lines of:
ns_header_field_parameter -charset /charset/ -language /language/
name string
to ease its usage. ... maybe something for the next release...
All the best
-g
PS: Minor nitpick: RFC 5987 was obsoleted by RFC 8187
On 19.07.22 23:25, Oscar Rodriguez Fonseca wrote:
> Dear all,
>
> Just for the sake of completeness. If you need an utf-8 encoded
> filename you may need to encode the filename (as per RFC 5987):
>
> ns_set update [ns_conn outputheaders] Content-Disposition
> "attachment; filename*=UTF-8''[ns_urlencode $filename]"
>
> ns_set update [ns_conn outputheaders] Content-Disposition
> "filename*=UTF-8''[ns_urlencode $filename]"
>
> AFAIK it works well in any modern browser.
>
> Best regards.
>
>
> -----Mensaje original-----
> De: Maksym Zinchenko <siq...@gm...>
> Responder a: nav...@li...
> Para: nav...@li...
> Asunto: Re: [naviserver-devel] ns_returnfile return original file
> name
> Fecha: Tue, 19 Jul 2022 16:33:58 -0100
>
> Thank you all, that's exactly what I needed.
>
> On Mon, Jul 18, 2022 at 1:00 PM Wolfgang Winkler via naviserver-
> devel <nav...@li...> wrote:
>
> > Hi!
> > We use
> > ns_set update [ns_conn outputheaders] Content-Disposition
> > "attachment; filename=\"${filename}\""
> > for downloading and
> > ns_set update [ns_conn outputheaders] Content-Disposition
> > "filename=\"${filename}\""
> > for viewing files
> > Am 15.07.22 um 16:50 schrieb Maksym Zinchenko:
> >
> >
> > > Hello, I have a question about how to return the original file
> > > name. For example:
> > >
> > > ns_register_proc GET /dev/rtrn_file ::dev::rtrn_file
> > > proc rtrn_file {args} {
> > > set f [file join /tmp test.csv]
> > > ns_returnfile 200 [ns_guesstype "$f"] $f
> > > }
> > >
> > > When I do GET request I'm getting "rtrn_file.csv" instead of
> > > "test.csv"
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
_______________________________________________
naviserver-devel mailing list
nav...@li...
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
|
|
From: Gustaf N. <ne...@wu...> - 2022-07-20 20:08:23
|
Dear Oscar,
In principle, you are right concerning the encoding. A few comments:
- on most browsers, also utf-8 filenames are accepted,
but the use of UTF-8 in the header fields is not recommended.
- For the percent encoding, one should use "ns_urlencode -path", e.g.,
ns_urlencode -part path {£ and € rates}
since the "ns_urlencode" without parameters (as in your example)
uses a special rule for the space character.
One should actually provide an API along the lines of:
ns_header_field_parameter -charset /charset/ -language /language/
name string
to ease its usage. ... maybe something for the next release...
All the best
-g
PS: Minor nitpick: RFC 5987 was obsoleted by RFC 8187
On 19.07.22 23:25, Oscar Rodriguez Fonseca wrote:
> Dear all,
>
> Just for the sake of completeness. If you need an utf-8 encoded
> filename you may need to encode the filename (as per RFC 5987):
>
> ns_set update [ns_conn outputheaders] Content-Disposition "attachment;
> filename*=UTF-8''[ns_urlencode $filename]"
>
> ns_set update [ns_conn outputheaders] Content-Disposition
> "filename*=UTF-8''[ns_urlencode $filename]"
>
> AFAIK it works well in any modern browser.
>
> Best regards.
>
>
> -----Mensaje original-----
> *De*: Maksym Zinchenko <siq...@gm...
> <mailto:Maksym%20Zinchenko%20%3cs...@gm...%3e>>
> *Responder a*: nav...@li...
> *Para*: nav...@li...
> *Asunto*: Re: [naviserver-devel] ns_returnfile return original file name
> *Fecha*: Tue, 19 Jul 2022 16:33:58 -0100
>
> Thank you all, that's exactly what I needed.
>
> On Mon, Jul 18, 2022 at 1:00 PM Wolfgang Winkler via naviserver-devel
> <nav...@li...> wrote:
>>
>> Hi!
>>
>> We use
>>
>> ns_set update [ns_conn outputheaders] Content-Disposition
>> "attachment; filename=\"${filename}\""
>>
>> for downloading and
>>
>> ns_set update [ns_conn outputheaders] Content-Disposition
>> "filename=\"${filename}\""
>>
>> for viewing files
>>
>> Am 15.07.22 um 16:50 schrieb Maksym Zinchenko:
>>
>>> Hello, I have a question about how to return the original file name.
>>> For example:
>>>
>>> ns_register_proc GET /dev/rtrn_file ::dev::rtrn_file
>>> proc rtrn_file {args} {
>>> set f [file join /tmp test.csv]
>>> ns_returnfile 200 [ns_guesstype "$f"] $f
>>> }
>>>
>>> When I do GET request I'm getting "rtrn_file.csv" instead of "test.csv"
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Univ.Prof. Dr. Gustaf Neumann
Head of the Institute of Information Systems and New Media
of Vienna University of Economics and Business
Program Director of MSc "Information Systems"
|
|
From: Gustaf N. <ne...@wu...> - 2022-07-20 19:39:50
|
Dear all, over the last days, I've worked on improving scalability of ns_set operations in NaviServer, which are used on multiple crucial places such as: - ndsb interface (returning tuples as ns_sets) - configuration values - headers The classical implementation for ns_sets uses separately malloced storage for every attribute name and attribute value. So, e.g., for 1000 ns_sets with 20 members each, this means 1,000*20*2 = 40,000 malloc/free operations, e.g. for a single db query! Although the malloc implementations have improved, these will require many lock operations, especially under load, where many threads might do as much malloc operation. One other consequence is that the allocated memory will be scattered over address space, which has bad implications for CPU caching. The new implementation uses a single Tcl_DString per ns_set keeping all attribute names and attribute values. This reduces the malloc operations and improved memory locality, such that cache hits will improve. One caveat is that modules using ns_set have to be recompiled, since the full data structure of the ns_set is exposed, and adding a member causes a binary incompatibility. One other potential problem is that C-level modules using the Ns_Set* API have to make sure that long-living string values are copied. Copying was necessary in general before as well, but might show up now earlier, when the ns_set sees multiple updates. There was one place, inside NaviServer, where a change was necessary. All of OpenACS is working fine with these changes, openacs.org runs already a version having this feature enabled. However, since this is technically a large change, the initial commit will have this feature deactivated by default (flag NS_SET_DSTRING). My plan is to have this feature by default deactivated for the 4.99* releases, but having it enabled for version 5 of NaviServer. Other goals for NS5 are Tcl9 compatibility (will require source code changes; NSF/XOTcl is already Tcl9 compatible) and the move from MPL 1.1 to 2.0 (as previously [1] announced). Here are some preliminary results from the ns_set reform. The tests were performed on openacs.org (Xeon Gold 6226R CPU @ 2.90GHz, 32 cores, hyper-threading enabled). The test executes the SQL query select * from acs_objects limit 1000 100 times in sequence. This test is run in 1..30 concurrent threads. With 30 threads, 3mio tuples are retrieved, and 72 mio malloc/free operations are needed alone for the retrieved values. Before (classical ns_set with many mallocs): threads 1 total 4606.787 ms avg 3285.25 ms threads 5 total 4595.358 ms avg 3493.07 ms threads 10 total 4804.193 ms avg 3755.93 ms threads 20 total 6279.524 ms avg 4569.16 ms threads 30 total 8966.427 ms avg 6618.58 ms After reform (using common Tcl_DString per tuple): threads 1 total 4524.645 ms avg 3242.54 ms threads 5 total 4251.266 ms avg 3450.09 ms threads 10 total 4656.795 ms avg 3665.31 ms threads 20 total 5934.105 ms avg 4671.38 ms threads 30 total 7384.591 ms avg 5642.76 ms As one can see, the improvement increases under higher load (with more parallel threads). E.g. with 30 threads, the total time improved by 17%.... with a smaller RSS. These tests were not performed under "clinical" conditions. While working on ns_set and OpenACS db operations, having substantial debugging activated, I've optimized the database operations further, such that on high load and large queries, the performance can be now several times (!) faster by avoiding duplicates in the memory (but this is more an OpenACS topic). More changes: Better resource reuse: - keep Ns_Sets for request and response headers instead of deleting/recreating it frequently API extensions: - Provide new interface ending with *Sz to provide string sizes. This reduces the need of strlen() operations. * Ns_SetCreateSz() * Ns_SetIUpdateSz() * Ns_SetPutSz() * Ns_SetPutValueSz() * Ns_SetUpdateSz() - New severity Debug(nsset) for ns_set debugging added, maybe temporary - New API calls * Ns_SetClearValues(): clear the values for all keys * Ns_SetDataPrealloc(): creating ns_sets with pre-allocated values to avoid resize operations * NsSetResize() * NsHeaderSetGet() - Ns_ConfigSet(const char *section, const char *key, const char *name) The last argument is now and allows one to created named sets (previously, all such sets were unnamed) - Tcl API: * provide optional values to "ns_set size" for pre-allocation - extended regression test All the best -g |
|
From: Oscar R. F. <oro...@vr...> - 2022-07-19 21:41:07
|
Dear all,
Just for the sake of completeness. If you need an utf-8 encoded
filename you may need to encode the filename (as per RFC 5987):
ns_set update [ns_conn outputheaders] Content-Disposition
"attachment; filename*=UTF-8''[ns_urlencode $filename]"
ns_set update [ns_conn outputheaders] Content-Disposition
"filename*=UTF-8''[ns_urlencode $filename]"
AFAIK it works well in any modern browser.
Best regards.
-----Mensaje original-----
De: Maksym Zinchenko <siq...@gm...>
Responder a: nav...@li...
Para: nav...@li...
Asunto: Re: [naviserver-devel] ns_returnfile return original file
name
Fecha: Tue, 19 Jul 2022 16:33:58 -0100
Thank you all, that's exactly what I needed.
On Mon, Jul 18, 2022 at 1:00 PM Wolfgang Winkler via naviserver-devel
<nav...@li...> wrote:
> Hi!
> We use
> ns_set update [ns_conn outputheaders] Content-Disposition
> "attachment; filename=\"${filename}\""
> for downloading and
> ns_set update [ns_conn outputheaders] Content-Disposition
> "filename=\"${filename}\""
> for viewing files
> Am 15.07.22 um 16:50 schrieb Maksym Zinchenko:
>
> > Hello, I have a question about how to return the original file
> > name. For example:
> >
> > ns_register_proc GET /dev/rtrn_file ::dev::rtrn_file
> > proc rtrn_file {args} {
> > set f [file join /tmp test.csv]
> > ns_returnfile 200 [ns_guesstype "$f"] $f
> > }
> >
> > When I do GET request I'm getting "rtrn_file.csv" instead of
> > "test.csv"
|
|
From: Maksym Z. <siq...@gm...> - 2022-07-19 17:34:18
|
Thank you all, that's exactly what I needed.
On Mon, Jul 18, 2022 at 1:00 PM Wolfgang Winkler via naviserver-devel <
nav...@li...> wrote:
> Hi!
>
> We use
>
> ns_set update [ns_conn outputheaders] Content-Disposition "attachment;
> filename=\"${filename}\""
>
> for downloading and
>
> ns_set update [ns_conn outputheaders] Content-Disposition
> "filename=\"${filename}\""
>
> for viewing files
>
>
> Am 15.07.22 um 16:50 schrieb Maksym Zinchenko:
>
> Hello, I have a question about how to return the original file name. For
> example:
>
> ns_register_proc GET /dev/rtrn_file ::dev::rtrn_file
> proc rtrn_file {args} {
> set f [file join /tmp test.csv]
> ns_returnfile 200 [ns_guesstype "$f"] $f
> }
>
> When I do GET request I'm getting "rtrn_file.csv" instead of "test.csv"
>
> Maybe I'm doing it wrong.
>
> Thank you.
>
>
> _______________________________________________
> naviserver-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
> --
>
> *Wolfgang Winkler*
> Geschäftsführung
> wol...@di...
> mobil +43.699.19971172
>
> dc:*büro*
> digital concepts Novak Winkler OG
> Software & Design
> Landstraße 68, 5. Stock, 4020 Linz
> www.digital-concepts.com
> tel +43.732.997117.72
> tel +43.699.1997117.2
>
> Firmenbuchnummer: 192003h
> Firmenbuchgericht: Landesgericht Linz
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
|
|
From: Wolfgang W. <wol...@di...> - 2022-07-18 14:00:16
|
Hi!
We use
ns_set update [ns_conn outputheaders] Content-Disposition "attachment;
filename=\"${filename}\""
for downloading and
ns_set update [ns_conn outputheaders] Content-Disposition
"filename=\"${filename}\""
for viewing files
Am 15.07.22 um 16:50 schrieb Maksym Zinchenko:
> Hello, I have a question about how to return the original file name.
> For example:
>
> ns_register_proc GET /dev/rtrn_file ::dev::rtrn_file
> proc rtrn_file {args} {
> set f [file join /tmp test.csv]
> ns_returnfile 200 [ns_guesstype "$f"] $f
> }
>
> When I do GET request I'm getting "rtrn_file.csv" instead of "test.csv"
>
> Maybe I'm doing it wrong.
>
> Thank you.
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
*Wolfgang Winkler*
Geschäftsführung
wol...@di...
mobil +43.699.19971172
dc:*büro*
digital concepts Novak Winkler OG
Software & Design
Landstraße 68, 5. Stock, 4020 Linz
www.digital-concepts.com <http://www.digital-concepts.com>
tel +43.732.997117.72
tel +43.699.1997117.2
Firmenbuchnummer: 192003h
Firmenbuchgericht: Landesgericht Linz
|
|
From: Gustaf N. <ne...@wu...> - 2022-07-16 12:08:01
|
Dear Maksym, If no name is provided with the download, the browser can provide a name; the behavior might be different dependent on the browser. Therefore, it is recommended to provide the name via the return header field "Content-Disposition", ... or via the "download" attribute in the link. For details, see [1] all the best -gn [1] https://stackoverflow.com/questions/1628260/downloading-a-file-with-a-different-name-to-the-stored-name ns_register_proc GET /dev/rtrn_file ::dev::rtrn_file namespace eval ::dev { proc rtrn_file {args} { ns_set put [ns_conn outputheaders] Content-Disposition {attachment; filename="test.csv"} set f [file join /tmp test.csv] ns_returnfile 200 [ns_guesstype $f] $f } } |
|
From: Maksym Z. <siq...@gm...> - 2022-07-15 14:51:03
|
Hello, I have a question about how to return the original file name. For
example:
ns_register_proc GET /dev/rtrn_file ::dev::rtrn_file
proc rtrn_file {args} {
set f [file join /tmp test.csv]
ns_returnfile 200 [ns_guesstype "$f"] $f
}
When I do GET request I'm getting "rtrn_file.csv" instead of "test.csv"
Maybe I'm doing it wrong.
Thank you.
|
|
From: Gustaf N. <ne...@wu...> - 2022-07-11 10:48:48
|
Dear all, One of the feature of the NaviServer configuration file is that these are extensible, i.e. that arbitrary values can also be added for application purposes. However, this flexibility comes with the price that it is sometimes a problem to detect typos in the configuration file, or obsolete settings (e.g. some names from AOLserverver), etc. The new version on Bitbucket addresses this disadvantage by supporting now additional information about configuration values, such as - value read during startup - value is defaulted (was not set in the configuration file) - default of a value. The information is provided via tool-tips and color coding in nsstats: - black: value is set from the configuration file (showing the default between parenthesis when non-empty) - gray: value is defaulted - orange: value was set in the configuration file, but is identical to the default (not necessary to set it) - red: value was not read during startup (not necessarily wrong, but might hint to a problem) Please note, that in order to use this new feature, also the nsstats module has to be updated all the best -g |
14 messages has been excluded from this view by a project administrator.
