Recent Posts
1
Web Server - Ask For Help / Is there a way to GET binary files from a rest server, not using encoding?
« Last post by jlavera on Today at 05:21:58 PM »Hi, all.
We have some API Rest servers where the speed had become critical, so if we can reduce the traffic it would be great. We used to upload/download (POST, GET) files using base64 encoding inside json packages. It works great, but it adds 30% to 40% of overhead.
We replaced all the POST with Multipart/form-data, the API rest server recognizes it perfectly, and we receive those files way faster than before.
However, I don't find the way to do the same for GET operations; for what I see, the methods force to use either json or xml (the "default return format" is mandatory and either json or xml).
Is there a way to transmit a Multipart/form-data response? Or any other way to transmit binaries, for example BSON or even CBOR?
Cheers,
Jorge Lavera
We have some API Rest servers where the speed had become critical, so if we can reduce the traffic it would be great. We used to upload/download (POST, GET) files using base64 encoding inside json packages. It works great, but it adds 30% to 40% of overhead.
We replaced all the POST with Multipart/form-data, the API rest server recognizes it perfectly, and we receive those files way faster than before.
However, I don't find the way to do the same for GET operations; for what I see, the methods force to use either json or xml (the "default return format" is mandatory and either json or xml).
Is there a way to transmit a Multipart/form-data response? Or any other way to transmit binaries, for example BSON or even CBOR?
Cheers,
Jorge Lavera
2
Web Server - Ask For Help / Re: GPF on Line=1774 Proc=SSL_OUR_SERVERSWITCHTOSSL
« Last post by jlavera on May 22, 2026, 02:07:28 AM »For others and future references, the debug in NT was disabled, and when I activated it, the GPFs just stopped.
From the General extension, "Log files" tab, activated Force /netall, and the error went away - no more GPFs.
Bruce told me the debug change forces a "full recompile", and that's why it was fixed. As per his request, I recompiled again without the debug.
Indeed after 8 hours the GPFs still didn't return, so there's a magic trick to fix this.
Kind regards,
Jorge Lavera
From the General extension, "Log files" tab, activated Force /netall, and the error went away - no more GPFs.
Bruce told me the debug change forces a "full recompile", and that's why it was fixed. As per his request, I recompiled again without the debug.
Indeed after 8 hours the GPFs still didn't return, so there's a magic trick to fix this.
Kind regards,
Jorge Lavera
3
Web Server - Ask For Help / Re: Restrictok issue
« Last post by wasatchconsulting on May 21, 2026, 11:38:49 AM »Well that workaround worked. Same as you, I cannot figure out why it is returning restricted as I cannot figure out what it was looking at. Maybe CanCall is what needs to be reviewed.
Thanks for the workaround.
Ken
Thanks for the workaround.
Ken
4
Web Server - Ask For Help / Re: GPF on Line=1774 Proc=SSL_OUR_SERVERSWITCHTOSSL
« Last post by jlavera on May 21, 2026, 06:41:46 AM »Hi, Bruce.
You didn't teamviewer that time, we finally did an upgrade of NT to the latest NT 12.x and the error went away.
While the GPF is exactly the same, the situation is different this time. In that time the error was in a single server running alone, this is no longer happening. And we are in the latest of everything.
Kind regards,
Jorge Lavera
You didn't teamviewer that time, we finally did an upgrade of NT to the latest NT 12.x and the error went away.
While the GPF is exactly the same, the situation is different this time. In that time the error was in a single server running alone, this is no longer happening. And we are in the latest of everything.
Kind regards,
Jorge Lavera
5
Web Server - Ask For Help / Re: GPF on Line=1774 Proc=SSL_OUR_SERVERSWITCHTOSSL
« Last post by Bruce on May 21, 2026, 06:03:14 AM »probably not.
My guess is whatever you did wrong in 2022 you've done wrong again.
Since I had to TeamViewer in to see what that was last time, I'm guessing I need to do that again.
My guess is whatever you did wrong in 2022 you've done wrong again.
Since I had to TeamViewer in to see what that was last time, I'm guessing I need to do that again.
6
Web Server - Ask For Help / Re: Restrictok issue
« Last post by seanh on May 20, 2026, 03:41:03 PM »This similar to a situation I had with the logout menu item.
I added this code to webhander procedure in webhandler.p_web, restrictok method, Priority 3000
if pProcedure = 'SecwinLogoutWeb' !smh Hack to get logout ok
ReturnValue = sw:CanAccess
END
It's just after a call to SecwinCurrentUser.getRight
I could never trace why it was coming back restricted when I set everything otherwise.
I also have secwin set to deny by default, which I think was part of the problem.
I added this code to webhander procedure in webhandler.p_web, restrictok method, Priority 3000
if pProcedure = 'SecwinLogoutWeb' !smh Hack to get logout ok
ReturnValue = sw:CanAccess
END
It's just after a call to SecwinCurrentUser.getRight
I could never trace why it was coming back restricted when I set everything otherwise.
I also have secwin set to deny by default, which I think was part of the problem.
7
Web Server - Ask For Help / Restrictok issue
« Last post by wasatchconsulting on May 20, 2026, 11:00:22 AM »I am running NetTalk 14.37 and Secwin 7.6
I have a procedure that was generated called on a webserver project called SecWinLoginWeb. I have had no issues for years and then just recently, the login page stopped appearing on the main page. I can still just type in the procedure and the login page appears and I can login and move forward.
I set some trace up and everything is just fine with GetSessionLoggedIn() and CanCall(), but RestrictOk() is giving a response of "1" and not "0" and so the button does not appear. All other buttons appear without any issues with the logic used.
I tried even bringing in a login page from another application just to see if there is something about the procedure, but there is something else that is giving the wrong response. I don't see any clues as to what RestrictOK() is looking at and the documentation does not mention this procedure.
Any assistance would be greatly appreciated
Ken Watts
I have a procedure that was generated called on a webserver project called SecWinLoginWeb. I have had no issues for years and then just recently, the login page stopped appearing on the main page. I can still just type in the procedure and the login page appears and I can login and move forward.
I set some trace up and everything is just fine with GetSessionLoggedIn() and CanCall(), but RestrictOk() is giving a response of "1" and not "0" and so the button does not appear. All other buttons appear without any issues with the logic used.
I tried even bringing in a login page from another application just to see if there is something about the procedure, but there is something else that is giving the wrong response. I don't see any clues as to what RestrictOK() is looking at and the documentation does not mention this procedure.
Any assistance would be greatly appreciated
Ken Watts
8
Web Server - Ask For Help / Re: GPF on Line=1774 Proc=SSL_OUR_SERVERSWITCHTOSSL
« Last post by jlavera on May 19, 2026, 09:21:33 AM »Can somehow sharing a certificate among servers can cause this? I have two servers sharing a folder and a certificate, and both are showing this sporadic GPF problem. Other servers not sharing, does not.
9
Web Server - Ask For Help / Re: GPF on Line=1774 Proc=SSL_OUR_SERVERSWITCHTOSSL
« Last post by jlavera on May 18, 2026, 04:12:56 AM »Hi, Bruce.
I'm not sure how we solved that, but it was working fine in NT 12.47.
We needed some new features so we migrated to NT 14.37 - now, the problem started again.
With the server sitting idle, just answering "pings", it GPFs each 6 or so hours.
Basically, same GPF as this old case.
I'm sure all the dlls are matching NT 14.37, libcrypto-3.dll is 3.5.1.0, LibSSL-3.dll is 3.5.1, clanet.dll is 14.37.0.0, all in the program's folder.
Note in the GPF there is no mention of any other program, just clanet.dll and clarun.dll.
Is there any other resource I should check?
Why is it calling SSL_OUR_SERVERSWITCHTOSSL? Our "unsecure" port is closed, there is nothing coming from there (all connections are TLS).
Is this needed? Can be disabled somehow?
Program : F:\SMSRestServerMobileDevOps\SMSRestWebServer.exe
Version : 5276.14.4.548
At : 19:23:22 on 2026/05/18
Workstation: : ALCHEMY-RDSH-02
User Name: : ALCHEMY-RDSH-02$
Reported error : EXCEPTION_ACCESS_VIOLATION - Error writing data at : 00000000h
Windows : Win 10 - 10.0.17763
Clarion : 0.9
Thread : 3 Field : 0 Event : 523 Keycode : 0
Error at address : 00000000h no module
Stack Trace
7417CE89h Line=2072 Proc=SSL_OUR_SERVERSWITCHTOSSL@F Src=netdl020.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[01] 7417CE89h Line=2072 Proc=SSL_OUR_SERVERSWITCHTOSSL@F Src=netdl020.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[02] 741706C6h Line=1794 Proc=SIMPLESERVER_ACCEPT@Fll Src=netdl017.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[03] 741487E0h Line=1158 Proc=CALLBACKWINDOWCLIENTCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[04] 76E96D1Bh no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[05] 76E877CCh no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
72F0BDC0h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72F0BDC4h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72F0BDBCh Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[06] 76E8690Bh no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[07] 76E7CC60h no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
[08] 72EA0B48h Line ?=27 no proc Src="Library State" Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
74148C28h Line=819 Proc=CALLBACKWINDOWSRC@F Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
72EE1E3Ah Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EC36E8h Line ?=27 no proc Src="Library State" Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
[09] 74148F1Eh Line=857 Proc=CALLBACKWINDOWSRC@F Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[10] 72E83FC3h no line number no proc Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EFCFC4h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EDDE6Eh Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
[11] 72E83AA1h no line number no proc Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EDDE84h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EFCFC4h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EFD044h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EF1360h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EF1374h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EF1390h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EF1384h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EF13ACh Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EF13A0h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
[12] 77817E4Dh no debug info, Module=C:\windows\SYSTEM32\ntdll.dll 10.0.17763.6292 (WinBuild.160101.0800)
[13] 77817E1Dh no debug info, Module=C:\windows\SYSTEM32\ntdll.dll 10.0.17763.6292 (WinBuild.160101.0800)
Kind regards,
Jorge Lavera
I'm not sure how we solved that, but it was working fine in NT 12.47.
We needed some new features so we migrated to NT 14.37 - now, the problem started again.
With the server sitting idle, just answering "pings", it GPFs each 6 or so hours.
Basically, same GPF as this old case.
I'm sure all the dlls are matching NT 14.37, libcrypto-3.dll is 3.5.1.0, LibSSL-3.dll is 3.5.1, clanet.dll is 14.37.0.0, all in the program's folder.
Note in the GPF there is no mention of any other program, just clanet.dll and clarun.dll.
Is there any other resource I should check?
Why is it calling SSL_OUR_SERVERSWITCHTOSSL? Our "unsecure" port is closed, there is nothing coming from there (all connections are TLS).
Is this needed? Can be disabled somehow?
Program : F:\SMSRestServerMobileDevOps\SMSRestWebServer.exe
Version : 5276.14.4.548
At : 19:23:22 on 2026/05/18
Workstation: : ALCHEMY-RDSH-02
User Name: : ALCHEMY-RDSH-02$
Reported error : EXCEPTION_ACCESS_VIOLATION - Error writing data at : 00000000h
Windows : Win 10 - 10.0.17763
Clarion : 0.9
Thread : 3 Field : 0 Event : 523 Keycode : 0
Error at address : 00000000h no module
Stack Trace
7417CE89h Line=2072 Proc=SSL_OUR_SERVERSWITCHTOSSL@F Src=netdl020.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0[01] 7417CE89h Line=2072 Proc=SSL_OUR_SERVERSWITCHTOSSL@F Src=netdl020.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[02] 741706C6h Line=1794 Proc=SIMPLESERVER_ACCEPT@Fll Src=netdl017.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[03] 741487E0h Line=1158 Proc=CALLBACKWINDOWCLIENTCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0[04] 76E96D1Bh no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0[05] 76E877CCh no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0 72F0BDC0h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72F0BDC4h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72F0BDBCh Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0[06] 76E8690Bh no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0 74147FC4h Line=1267 Proc=CALLBACKWINDOWMAINCALLBACK Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0[07] 76E7CC60h no debug info, Module=C:\windows\System32\USER32.dll 10.0.17763.1 (WinBuild.160101.0800)
[08] 72EA0B48h Line ?=27 no proc Src="Library State" Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
74148C28h Line=819 Proc=CALLBACKWINDOWSRC@F Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0 72EE1E3Ah Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EC36E8h Line ?=27 no proc Src="Library State" Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845[09] 74148F1Eh Line=857 Proc=CALLBACKWINDOWSRC@F Src=netdl003.clw Module=F:\SMSRestServerMobileDevOps\CLAnet.dll 14.37.0.0
[10] 72E83FC3h no line number no proc Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EFCFC4h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EDDE6Eh Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845[11] 72E83AA1h no line number no proc Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845
72EDDE84h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EFCFC4h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EFD044h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EF1360h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EF1374h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EF1390h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EF1384h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EF13ACh Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845 72EF13A0h Line ?=47 no proc Src=wxeh.cpp Module=F:\SMSRestServerMobileDevOps\ClaRUN.dll 11.1.13845[12] 77817E4Dh no debug info, Module=C:\windows\SYSTEM32\ntdll.dll 10.0.17763.6292 (WinBuild.160101.0800)
[13] 77817E1Dh no debug info, Module=C:\windows\SYSTEM32\ntdll.dll 10.0.17763.6292 (WinBuild.160101.0800)
Kind regards,
Jorge Lavera
10
Web Server - Ask For Help / Re: NetWebServiceMethod
« Last post by seanh on May 04, 2026, 10:49:56 PM »If you're only getting XML maybe the client request is the problem?
See:
https://www.capesoft.com/docs/NetTalk14/NetTalkWebServices.htm#ReturnFormatRules
See:
https://www.capesoft.com/docs/NetTalk14/NetTalkWebServices.htm#ReturnFormatRules