Recent Posts
1
Web Server - Ask For Help / Re: Content-Security-Policy and Content-Security-Policy-Report-Only:
« Last post by osquiabro on Today at 05:50:23 AM »Bruce i see inconsistency in this two .inc
NetAll.inc:
ContentSecurityPolicy string(256)
ContentSecurityPolicyReportOnly string(256)
NetWeb.inc
ContentSecurityPolicy string(1024)
ContentSecurityPolicyReportOnly string(256)
But after changing everything to 1024, it works for what I wanted.
NetAll.inc:
ContentSecurityPolicy string(256)
ContentSecurityPolicyReportOnly string(256)
NetWeb.inc
ContentSecurityPolicy string(1024)
ContentSecurityPolicyReportOnly string(256)
But after changing everything to 1024, it works for what I wanted.
2
Web Server - Ask For Help / ALPN / HTTP/2
« Last post by osquiabro on August 29, 2026, 12:04:36 PM »Is possible to the next version of NT this is available?
3
Web Server - Ask For Help / Content-Security-Policy and Content-Security-Policy-Report-Only:
« Last post by osquiabro on August 29, 2026, 05:14:47 AM »Hi Bruce is posible to expand this variables for more characters in Web Server?
set:ContentSecurityPolicy
set:ContentSecurityPolicyReportOnly
set:ContentSecurityPolicy
set:ContentSecurityPolicyReportOnly
4
Web Server - Ask For Help / Re: (Much) slower response handling in netwebclient when using compact json
« Last post by AtoB on August 27, 2026, 07:20:21 AM »Additionally:
- turns out the production server had a much smaller payload returned than was in my mind (roughly 1/10th of the heavily tested payload), there was actually a 2/3 second delay too when the non-compacted json was to be displayed.
- I measure the duration of the whole process and this included the ?SomeControl{PROP:Text} statement too, that was a little misleading too (and made netwebclient suspect)
I guess text controls (at least in c10) really like linefeeds in the data to be displayed ...
Sorry for the inconvenience
- turns out the production server had a much smaller payload returned than was in my mind (roughly 1/10th of the heavily tested payload), there was actually a 2/3 second delay too when the non-compacted json was to be displayed.
- I measure the duration of the whole process and this included the ?SomeControl{PROP:Text} statement too, that was a little misleading too (and made netwebclient suspect)
I guess text controls (at least in c10) really like linefeeds in the data to be displayed ...
Sorry for the inconvenience
5
Web Server - Ask For Help / Re: (Much) slower response handling in netwebclient when using compact json
« Last post by AtoB on August 27, 2026, 05:29:15 AM »FOUND IT !
(It's NOT Nettalk !)
In net.pagereceived I've got this code:
?SomeControl{PROP:Text} = SELF.ThisPage.GetValue()
For some reason this thing goes haywire when I throw compacted json against it ... It also is not the "SELF.ThisPage.Getvalue()" itself, it's the assignment to the control ... have to dive into this a little deeper
(It's NOT Nettalk !)
In net.pagereceived I've got this code:
?SomeControl{PROP:Text} = SELF.ThisPage.GetValue()
For some reason this thing goes haywire when I throw compacted json against it ... It also is not the "SELF.ThisPage.Getvalue()" itself, it's the assignment to the control ... have to dive into this a little deeper
6
Web Server - Ask For Help / Re: Nettalk, LetsEncrypt and wildcard certificates
« Last post by PaulMacFarlane on August 26, 2026, 11:58:27 AM »We are trying to handle obtain a certificate to use on an internal server for communicating with Office365.
The communication is handled from our internal server to O365, but it does require a cert to identify itself.
Doesn't need to be access from the public network.
We've gone down the road of using Caddy, etc. but the issue is that Godaddy no longer supports DNS Challenge using v1 of their API. V3 requires OAuth/Bearer token.
So, looking into somehow obtaining a wildcard on a public server and then distributing it to the internal server.
I did not know the wildcards were limited to DNS Challenge which puts us right back to where we started!
The communication is handled from our internal server to O365, but it does require a cert to identify itself.
Doesn't need to be access from the public network.
We've gone down the road of using Caddy, etc. but the issue is that Godaddy no longer supports DNS Challenge using v1 of their API. V3 requires OAuth/Bearer token.
So, looking into somehow obtaining a wildcard on a public server and then distributing it to the internal server.
I did not know the wildcards were limited to DNS Challenge which puts us right back to where we started!
7
Web Server - Ask For Help / Re: (Much) slower response handling in netwebclient when using compact json
« Last post by AtoB on August 26, 2026, 08:12:34 AM »I forgot to include the request headers:
Full http header for slow request/response (compact json):
GET /wsPurchases/ordersCoils HTTP/1.1
Accept: application/json
Accept-Language: en
Authorization: yadayada
Accept-Encoding: gzip
User-Agent: NetTalk 14.38
Host: 127.0.0.1:8091
Content-Length: 0
Connection: Keep-Alive
Full http header for fast request/response (human readable json)
GET /wsPurchases/ordersCoils?&readable=1 HTTP/1.1
Accept: application/json
Accept-Language: en
Authorization: yadayada
Accept-Encoding: gzip
User-Agent: NetTalk 14.38
Host: 127.0.0.1:8091
Content-Length: 0
Connection: Keep-Alive
(edit 27th aug ... also noticed the log files were not present)
Full http header for slow request/response (compact json):
GET /wsPurchases/ordersCoils HTTP/1.1
Accept: application/json
Accept-Language: en
Authorization: yadayada
Accept-Encoding: gzip
User-Agent: NetTalk 14.38
Host: 127.0.0.1:8091
Content-Length: 0
Connection: Keep-Alive
Full http header for fast request/response (human readable json)
GET /wsPurchases/ordersCoils?&readable=1 HTTP/1.1
Accept: application/json
Accept-Language: en
Authorization: yadayada
Accept-Encoding: gzip
User-Agent: NetTalk 14.38
Host: 127.0.0.1:8091
Content-Length: 0
Connection: Keep-Alive
(edit 27th aug ... also noticed the log files were not present)
8
Web Server - Ask For Help / (Much) slower response handling in netwebclient when using compact json
« Last post by AtoB on August 26, 2026, 07:11:06 AM »HI all,
(using nettalk 14.38 for both server/client, clarion 10)
I ran into a strange but a little concerning issue:
all my endpoints have the option to request for human readable (non-compact) json or json without these spaces/line breaks (compact). I control this via parameter "readable=1" and use the human readable mostly only during testing. This in itself works ok.
Today I (by accident) I ran a GET with the option omitted, so effectively asking for "compact" json against a somewhat larger result/response and this took ages (cpu of het client app hitting the max)
- Human readable response takes 3 seconds
- Non-human readable json (so effectively less data) takes 90 seconds!
If tested all my endpoints and even small results take double time (when compacted) (40 ms process time becomes 80 ms), but the larger the response, the time to process the response seems to explode somehow.
Now the strange observations:
- I've tried both requests with Curl and both response are shown in somewhat the same time (roughly 3 seconds), to be complete this is the Curl command (with parameter active):
curl --header "Accept: application/json" --compressed --header "Accept-Language: en" --header "Authorization: yadayada" --header "Connection: Keep-Alive" --user-agent "NetTalk 14.38" "https://127.0.0.1:8091/wsPurchases/ordersCoils?&readable=1"
- I've tried another set of requests against a nettalk 12.45 (production) server and then I see no (
!!?) difference (so it's not only the client?)
I (no evidence) suspect compression might be at play here. So I also tried net.AcceptEncoding = 'plain' and net.AcceptEncoding = '', but this doesn't make any differenct (compact stays way slower).
Below are both (nettalk client) headers to be complete and I've attached two log files (one slow and one fast) that show the difference. And a screenshot where the difference occurs.
Problem is there no more data between the delay in the log file ...
I'm a little clueless about where to start searching now and/or what settings might influence this slowdown.
Any tips are most appreciated
Thanks in advance
Regards,
Ton
(using nettalk 14.38 for both server/client, clarion 10)
I ran into a strange but a little concerning issue:
all my endpoints have the option to request for human readable (non-compact) json or json without these spaces/line breaks (compact). I control this via parameter "readable=1" and use the human readable mostly only during testing. This in itself works ok.
Today I (by accident) I ran a GET with the option omitted, so effectively asking for "compact" json against a somewhat larger result/response and this took ages (cpu of het client app hitting the max)
- Human readable response takes 3 seconds
- Non-human readable json (so effectively less data) takes 90 seconds!
If tested all my endpoints and even small results take double time (when compacted) (40 ms process time becomes 80 ms), but the larger the response, the time to process the response seems to explode somehow.
Now the strange observations:
- I've tried both requests with Curl and both response are shown in somewhat the same time (roughly 3 seconds), to be complete this is the Curl command (with parameter active):
curl --header "Accept: application/json" --compressed --header "Accept-Language: en" --header "Authorization: yadayada" --header "Connection: Keep-Alive" --user-agent "NetTalk 14.38" "https://127.0.0.1:8091/wsPurchases/ordersCoils?&readable=1"
- I've tried another set of requests against a nettalk 12.45 (production) server and then I see no (
!!?) difference (so it's not only the client?)I (no evidence) suspect compression might be at play here. So I also tried net.AcceptEncoding = 'plain' and net.AcceptEncoding = '', but this doesn't make any differenct (compact stays way slower).
Below are both (nettalk client) headers to be complete and I've attached two log files (one slow and one fast) that show the difference. And a screenshot where the difference occurs.
Problem is there no more data between the delay in the log file ...
I'm a little clueless about where to start searching now and/or what settings might influence this slowdown.
Any tips are most appreciated
Thanks in advance
Regards,
Ton
9
Web Server - Ask For Help / Re: DNSimple DNS method for Lets encrypt fails.
« Last post by rjolda on August 26, 2026, 02:42:23 AM »Hi,
I am using dnssimple.
NT does have a DNS app which connects to DNSsimple account and can edit it.
Ron
I am using dnssimple.
NT does have a DNS app which connects to DNSsimple account and can edit it.
Ron
10
Web Server - Ask For Help / Re: Nettalk, LetsEncrypt and wildcard certificates
« Last post by Bruce on August 26, 2026, 02:31:17 AM »Hi Paul,
I believe so, although it's not a road I've gone down myself yet.
It is limited to DNS-Challenge though. You can't get one with HTTP challenge.
I'm not sure the use-case with NetTalk is clear though. So perhaps you want to tell us more about your setup, and we can dig into that a bit deeper.
Cheers
Bruce
I believe so, although it's not a road I've gone down myself yet.
It is limited to DNS-Challenge though. You can't get one with HTTP challenge.
I'm not sure the use-case with NetTalk is clear though. So perhaps you want to tell us more about your setup, and we can dig into that a bit deeper.
Cheers
Bruce