[naviserver-devel] Content-Disposition: form-data - Apparently wrong format

[Iuri de Araujo Sampaio]

Hello there,
How would I achieve such format for a POST data request, using ns_procs?


[24/Feb/2021:14:52:13][30433.7efbf3d70700][-conn:qonteo:default:0:162-] Notice: 
COENTNT 674349094811372605992454\x0d
:Content-Disposition: form-data; name="To"\x0d
:\x0d
:whatsapp:+18474048771\x0d
:674349094811372605992454\x0d
:Content-Disposition: form-data; name="From"\x0d
:\x0d
:whatsapp:+14155238886\x0d
:674349094811372605992454\x0d
:Content-Disposition: form-data; name="Body"\x0d
:\x0d
:Your appointment is coming up on July 21 at 3PM\x0d
:674349094811372605992454--\x0d
:



Following official documentation, I’ve changed Content-Type to 
multipart/form-data,  however the body of the request got a different format. 
So the API on the other side complains about that fields have not been passed 
correctly,

[24/Feb/2021:14:52:23][30433.7efbf3d70700][-conn:qonteo:default:0:167-] Notice: 
COENTNT To=whatsapp:%2b+18474048771 From=whatsapp:%2b14155238886 
Body=%22Your&1%22

###
 # construct POST data
 ###
 set post_data {}
 foreach {key value} {q NaviServer} {
   lappend post_data "[ns_urlencode $key]=[ns_urlencode $value]"
 }
 set post_data [join $post_data &]
###
 # submit POST request
 ###
 set requestHeaders [ns_set create]
 set replyHeaders [ns_set create]
 ns_set update $requestHeaders "Content-type" "multipart/form-data"
set h [ns_http queue -method POST \
   -headers $requestHeaders \
   -timeout 10.0 \
   -body $post_data https://duckduckgo.com/]
 set r [ns_http wait $h]





___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] What's the replacement of [curl -u] in [ns_http]

[Iuri de Araujo Sampaio]

Thanks Gustaf,

[join $hash “”] was the solution.  It works now!

Even though, I still have no idea why that happens. I’m using ns_* procs,  
simple and straight forward. As in:

>   % set h [ns_set create]
>   % ns_set update $h Authorization "Basic [ns_base64encode guest:guest]"
>   % ns_http run -headers $h https://jigsaw.w3.org/HTTP/Basic/ 
>  
> >


the only different is because strings are longer than “guest:guest"


Best wishes,
I


> On Raj. 13, 1442 AH, at 00:03, Gustaf Neumann  wrote:
> 
> Dear Iuri,
> 
> The problem, you are probably facing is probably that ns_base64encode 
> produces line breaks as required for MIME encoded text strings [1].
> 
> % ns_base64encode 
> Afrewf564DFSFSF54jgnfhgGDGdfRGRT43:7584fjhfjhf84jkrugrefAFFD9449474
> QWZyZXdmNTY0REZTRlNGNTRqZ25maGdHREdkZlJHUlQ0Mzo3NTg0ZmpoZmpo
> Zjg0amtydWdyZWZBRkZEOTQ0OTQ3NA==
> Converting to and from a string with these linebreaks should be fine for all 
> base64 codecs (you see, colon is not the problem)
> 
> % ns_base64decode [ns_base64encode 
> Afrewf564DFSFSF54jgnfhgGDGdfRGRT43:7584fjhfjhf84jkrugrefAFFD9449474]
> Afrewf564DFSFSF54jgnfhgGDGdfRGRT43:7584fjhfjhf84jkrugrefAFFD9449474
> But probably, the header field has problems with linebreaks. Therefore, 
> simply remove the newlines by e.g.
> set credentials [join [ns_base64encode 
> Afrewf564DFSFSF54jgnfhgGDGdfRGRT43:7584fjhfjhf84jkrugrefAFFD9449474] ""]
> set req_headers [ns_set create headers Authorization "Basic $credentials"]
> All the best
> -g
> 
> PS: In order to see, what is sent via and and/or node, use tcpdump and/or 
> wireshark, then you do not have to do any guessing, what is exactly sent by 
> which command in which implementation
> 
> [1] 
> https://unix.stackexchange.com/questions/447191/whats-the-right-way-to-base64-encode-a-binary-file-on-centos-7#:~:text=base64%20inserts%20line%20breaks%20after,Transfer%2DEncoding%20for%20emails
>  
> ).
> 
> 
> ___
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] What's the replacement of [curl -u] in [ns_http]

[Iuri de Araujo Sampaio]

Hi everyone, 

So far, It seems ns_base64encode generates a different hash key, and the colon 
is the problem somehow. 


A valid request from Postman or CURL, has the following Authorization block 
within it :

Authorization {Basic 
HGTRFHTYhththtyhotyhtyjotjytjojg956456346n64ui5n4436346nu4y4iuyn4iutGRENDM3OWQwNmFkMWsFmNg==}

Meaning the authorization hash is:

HGTRFHTYhththtyhotyhtyjotjytjojg956456346n64ui5n4436346nu4y4iuyn4iutGRENDM3OWQwNmFkMWsFmNg==




While the Authorization block generated by [ns_base64encode] is: 

Authorization {Basic 
HGTRFHTYhththtyhotyhtyjotjytjojg956456346n64ui5n4436346nu4y4} 

So, it’s only the first part. 
HGTRFHTYhththtyhotyhtyjotjytjojg956456346n64ui5n4436346nu4y4


and the last part, after ":” has been missing (i.e. password) 
iuyn4iutGRENDM3OWQwNmFkMWsFmNg==



However, the same credentials were used to generate the 64 bits hash key 
encoded. 
set req_headers [ns_set create]
ns_set update $req_headers Authorization "Basic [ns_base64encode 
Afrewf564DFSFSF54jgnfhgGDGdfRGRT43:7584fjhfjhf84jkrugrefAFFD9449474]"


My guess is that [ns_base64encode] breaks in the colon char, and encodes only 
the first part as a 64 bits hash key.

How would the entire string  be encode as a 64 bits hash then?

How would the proc ns_base64encode support colon “:" (if the colon is the 
problem actually)?


p.s. logs are attached bellow.


Best wishes,
I





A valid request from Postman or CURL, contains the entire 64 bits hash key 
encoded 

[23/Feb/2021:15:59:08][23531.7efbf356f700][-conn:qonteo:default:1:0-] Notice: 
HEADER 
: t0
[23/Feb/2021:15:59:08][23531.7efbf356f700][-conn:qonteo:default:1:0-] Notice: 
HEADERS 11
[23/Feb/2021:15:59:08][23531.7efbf356f700][-conn:qonteo:default:1:0-] Notice: 
Host dashboard.qonteo.com X-Real-IP 187.127.207.76 Connection close 
Content-Length 454 Authorization {Basic 
HGTRFHTYhththtyhotyhtyjotjytjojg956456346n64ui5n4436346nu4y4iuyn4iutGRENDM3OWQwNmFkMWsFmNg==
  User-Agent PostmanRuntime/7.26.8 Accept */* Cache-Control no-cache 
Postman-Token 6bd5b753-bc8e-4447-bc85-155f517d6c72 Content-Type 
{multipart/form-data; 
boundary=--494740493183890794196511} Cookie 
{ad_locale="es_ES"; 
ad_session_id="34040084%2c0%2c0%2c1614106611%20{362%201614107811%201133CEC432ACA1B0529F80D7603EFD5D38289E85}”}





The request from Naviserver, contains a different Authorization 64 bits hash 
key encoded. The has key is only correspondent to the first part of the 
authorization (i.e. username).
 
[23/Feb/2021:15:58:01][1207.7efbb67fc700][-conn:qonteo:default:3:3251-] Notice: 
HEADER 
: t0
[23/Feb/2021:15:58:01][1207.7efbb67fc700][-conn:qonteo:default:3:3251-] Notice: 
HEADERS 6
[23/Feb/2021:15:58:01][1207.7efbb67fc700][-conn:qonteo:default:3:3251-] Notice: 
Host dashboard.qonteo.com X-Real-IP 192.199.241.132 Connection close 
Content-Length 178 Authorization {Basic 
HGTRFHTYhththtyhotyhtyjotjytjojg956456346n64ui5n4436346nu4y4}  User-Agent 
NaviServer/4.99.19







> On Raj. 11, 1442 AH, at 16:08, Iuri de Araujo Sampaio  wrote:
> 
> So far, I've found a previous post, from myself :-), regarding quite the same 
> problem.
> 
> https://www.mail-archive.com/naviserver-devel@lists.sourceforge.net/msg03818.html
>  
> <https://www.mail-archive.com/naviserver-devel@lists.sourceforge.net/msg03818.html>
> 
> > 
> > Ok, now add some Authorization. As defined by RFC 7617, one has to add an
> > Authorization request header field with user:id:password encoded in base64.
> >   % set h [ns_set create]
> >   % ns_set update $h Authorization "Basic [ns_base64encode guest:guest]"
> >   % ns_http run -headers $h https://jigsaw.w3.org/HTTP/Basic/ 
> > <https://jigsaw.w3.org/HTTP/Basic/> 
> > <https://jigsaw.w3.org/HTTP/Basic/ <https://jigsaw.w3.org/HTTP/Basic/>>
> 
> 
> However, I’m still having a hard time to figure out what would be the 
> replacement of the following NodeJS sample for a Basic Auth header on 
> Naviserver, proc
>  ns_http 
> 
> 
> NodeJS sample
> 
> ...
>  axios
> .post(url, new URLSearchParams(messageBody), {
> auth: {
> username: authSID,
> password: authToken
> }
> })
> 
> ...
> 
> 
> 
> TCL Sample
> 
> ...
> set req_headers [ns_set create]
> ns_set update $req_headers Authorization "Basic [ns_base64encode 
> ${username}:${token}]"
> 
> set data [list]
> lappend "[ns_urlencode To]=[ns_urlencode whatsapp:+55454545571]"
> lappend "[ns_urlencode From]=[ns_urlencode whatsapp:+14155238886]"
> lappend "[ns_urlencode Body]=[ns_urlencode \"Your Yummy Cupcakes Company 
> order of 1 dozen frosted cupcakes has shipped and should be delivered\"]"
> 
> 
> set res [ns_http run -metho

Re: [naviserver-devel] What's the replacement of [curl -u] in [ns_http]

[Iuri de Araujo Sampaio]

So far, I've found a previous post, from myself :-), regarding quite the same 
problem.

https://www.mail-archive.com/naviserver-devel@lists.sourceforge.net/msg03818.html
 
<https://www.mail-archive.com/naviserver-devel@lists.sourceforge.net/msg03818.html>

> 
> Ok, now add some Authorization. As defined by RFC 7617, one has to add an
> Authorization request header field with user:id:password encoded in base64.
>   % set h [ns_set create]
>   % ns_set update $h Authorization "Basic [ns_base64encode guest:guest]"
>   % ns_http run -headers $h https://jigsaw.w3.org/HTTP/Basic/ 
> <https://jigsaw.w3.org/HTTP/Basic/> 
> <https://jigsaw.w3.org/HTTP/Basic/ <https://jigsaw.w3.org/HTTP/Basic/>>


However, I’m still having a hard time to figure out what would be the 
replacement of the following NodeJS sample for a Basic Auth header on 
Naviserver, proc
 ns_http 


NodeJS sample

...
 axios
.post(url, new URLSearchParams(messageBody), {
auth: {
username: authSID,
password: authToken
}
})

...



TCL Sample

...
set req_headers [ns_set create]
ns_set update $req_headers Authorization "Basic [ns_base64encode 
${username}:${token}]"

set data [list]
lappend "[ns_urlencode To]=[ns_urlencode whatsapp:+55454545571]"
lappend "[ns_urlencode From]=[ns_urlencode whatsapp:+14155238886]"
lappend "[ns_urlencode Body]=[ns_urlencode \"Your Yummy Cupcakes Company order 
of 1 dozen frosted cupcakes has shipped and should be delivered\"]"


set res [ns_http run -method POST -headers $req_headers -body $data $url]
ns_log Notice "RES2 $res"



Based on this TCL sample, it returns 401 , meaning authentication step had 
failure.


22/Feb/2021:16:07:21][1207.7efbb6ffd700][-conn:qonteo:default:2:1647-] Notice: 
RES2 status 401 time 0:203450 headers d5 body {{"code": 20003, "detail": "", 
"message": "Authenticate", "more_info": 
"https://www.twilio.com/docs/errors/20003;, "status": 401}} https {sslversion 
TLSv1.2 cipher ECDHE-RSA-AES128-GCM-SHA256}




Best wishes,
I




> On Raj. 10, 1442 AH, at 20:14, Iuri de Araujo Sampaio  wrote:
> 
> Hello there,
> I’m trying to rewrite a CURL request to Naviserver. 
> 
> curl 
> 'https://api.twilio.com/2010-04-01/Accounts/ACe13c882f57e87c4b4db37/Messages.json
>  
> <https://api.twilio.com/2010-04-01/Accounts/ACe13c882f57e87c4b4db37/Messages.json>'
>  -X POST \
> --data-urlencode 'To=whatsapp:+5511998865465' \
> --data-urlencode 'From=whatsapp:+14155238886' \
> --data-urlencode 'Body=Your Yummy Cupcakes Company order of 1 dozen frosted 
> cupcakes has shipped and should be delivered on July 10, 2019. Details: 
> http://www.yummycupcakes.com/' <http://www.yummycupcakes.com/'> \
> -u [Authkey]:[AuthToken]
> 
> 
> man url 
>  -u, --user 
>   Specify the user name and password to use for server 
> authentication. Overrides -n, --netrc and --netrc-optional.
> 
>   If you simply specify the user name, curl will prompt for a 
> password.
> …
> 
> 
> 
> So basically, data-urlencode becomes posta_data. How could -u argument can be 
> rewritten to [ns_http run …] arguments
> 
> 
> set post_data [list]
> lappend "[ns_urlencode to]=[ns_urlencode whatsapp:+5511998865465]"
> lappend "[ns_urlencode From]=[ns_urlencode whatsapp:+14155238886]"
> lappend "[ns_urlencode Body]=[ns_urlencode \"Your Yummy Cupcakes Company 
> order of 1 dozen frosted cupcakes has shipped and should be deli\
> vered\"]"
> 
> set url 
> "https://api.twilio.com/2010-04-01/Accounts/ACe13c431f82f57e87c4b4db37/Messages.json
>  
> <https://api.twilio.com/2010-04-01/Accounts/ACe13c431f82f57e87c4b4db37/Messages.json>"
> 
> set res [ns_http run -method POST -headers $req_headers -body $post_data $url]
> ns_log Notice "RES2 $res"
> 
> 
> 
> I was looking for references in the documentation, however I haven’t found 
> any matches. What's the replacement of curl -u in ns_http?
> 
> References: 
> https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html 
> <https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html>
> 
> 
> Best wishes,
> I

___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

[naviserver-devel] What's the replacement of [curl -u] in [ns_http]

[Iuri de Araujo Sampaio]

Hello there,
I’m trying to rewrite a CURL request to Naviserver. 

curl 
'https://api.twilio.com/2010-04-01/Accounts/ACe13c882f57e87c4b4db37/Messages.json'
 -X POST \
--data-urlencode 'To=whatsapp:+5511998865465' \
--data-urlencode 'From=whatsapp:+14155238886' \
--data-urlencode 'Body=Your Yummy Cupcakes Company order of 1 dozen frosted 
cupcakes has shipped and should be delivered on July 10, 2019. Details: 
http://www.yummycupcakes.com/' \
-u [Authkey]:[AuthToken]


man url 
 -u, --user 
  Specify the user name and password to use for server 
authentication. Overrides -n, --netrc and --netrc-optional.

  If you simply specify the user name, curl will prompt for a 
password.
…



So basically, data-urlencode becomes posta_data. How could -u argument can be 
rewritten to [ns_http run …] arguments


set post_data [list]
lappend "[ns_urlencode to]=[ns_urlencode whatsapp:+5511998865465]"
lappend "[ns_urlencode From]=[ns_urlencode whatsapp:+14155238886]"
lappend "[ns_urlencode Body]=[ns_urlencode \"Your Yummy Cupcakes Company order 
of 1 dozen frosted cupcakes has shipped and should be deli\
vered\"]"

set url 
"https://api.twilio.com/2010-04-01/Accounts/ACe13c431f82f57e87c4b4db37/Messages.json;

set res [ns_http run -method POST -headers $req_headers -body $post_data $url]
ns_log Notice "RES2 $res"



I was looking for references in the documentation, however I haven’t found any 
matches. What's the replacement of curl -u in ns_http?

References: 
https://naviserver.sourceforge.io/n/naviserver/files/ns_http.html 



Best wishes,
I___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] ns_conn auth

[Iuri de Araujo Sampaio]

There we go!  ;)

> On Rab. II 6, 1442 AH, at 17:05, Gustaf Neumann  wrote:
> 
> Dear Maksym,
> 
> [ns_conn auth] handles Digest authentication (i've never used it), but 
> "Bearer" is not handled. 
> The fields in the "Authorization" request header field are not always 
> structured the same way,
> so NaviServer tries it interprete it based on the first word. The known types 
> are enumerated
> in the C code.
> 
> I've added a sensible result for the "Bearer" Authorization to bitbucket.
> 
> all the best -g
> 
> 
> 
> 
> 
> On 21.11.20 17:59, Maksym Zinchenko wrote:
>> Hello, hope you are doing well.
>> I have a little question. Maybe a bug, would be so kind to help me out.
>> According to documentation [ns_conn auth] should return all authorization 
>> headers as a ns_set. 
>> It works fine when using "Basic Authentication scheme", i've seen in the 
>> source code it should work with "Digest"
>> But when im trying to use "Bearer Authentication scheme" or "Custom" it 
>> returns empty ns_set, but i can see Authentication part in [ns_conn headers].
>> 
>> P.S.
>> Im using https://reqbin.com/  to test my API request.
>> 
>> Thank you
>> 
>> 
>> 
>> ___
>> naviserver-devel mailing list
>> naviserver-devel@lists.sourceforge.net 
>> 
>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel 
>> 
> ___
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] ns_conn auth

[Iuri de Araujo Sampaio]

Hi Maksym,
Indeed I got it now. And I’m able to replicate your scenario on my end.


Unless there's a bug (i.e. malformed list in the ns_auth assignment), it seems 
ns_set supports only reserved keys for “auth”. So, I believe it’s because NS 
source only assigns default values (basic headers to it). Even because 
documentation points to that direction [1] and [2]

[1] https://naviserver.sourceforge.io/n/naviserver/files/ns_conn.html#4 
<https://naviserver.sourceforge.io/n/naviserver/files/ns_conn.html#4>
[2] https://naviserver.sourceforge.io/n/naviserver/files/ns_set.html#2 
<https://naviserver.sourceforge.io/n/naviserver/files/ns_set.html#2>



So, the question is how do we make NS aware of customs auth headers?

Here it's a situation when we must call the academy within their super powers… 

@Gustaf we need your help, please!



Here it’s a draft that I’ve written to test and confirm your assumption. It was 
supposed to return: 

Authorization {Bearer 
eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9.eydzdWInOiAnNzA0JywgJ2lhdCc6IDE1OTA1MzAxODZ9.20f471933ae0a9c58d525f4ab0c1eef7adab03f17c3bbe18a00cf30a1ef06948}

but it returns void as yours.  I’m running version 4.99.19  Notice: nsmain: 
NaviServer/4.99.19 (tar-4.99.19) running


Best wishes,
I



ns_log Notice "Running REST upload-image"

ns_log Notice "AUTH [ns_conn auth]”
ns_log Notice “ARRAY AUTH [ns_set array [ns_conn auth]]”
set l_auth [ns_set list [ns_conn auth]]
ns_log Notice "LIST AUTH $l_auth"
foreach elem $l_auth {
ns_log Notice "[ns_set array $elem]"
}


[21/Nov/2020:17:03:27][29540.7efbf356f700][-conn:qonteo:default:1:7-] Notice: 
Running REST upload-image
[21/Nov/2020:17:03:27][29540.7efbf356f700][-conn:qonteo:default:1:7-] Notice: 
AUTH t4
[21/Nov/2020:17:03:27][29540.7efbf356f700][-conn:qonteo:default:1:7-] Notice: 
LIST AUTH t4 t0 d1 d2 d3
[21/Nov/2020:17:03:27][29540.7efbf356f700][-conn:qonteo:default:1:7-] Notice: 
[21/Nov/2020:17:03:27][29540.7efbf356f700][-conn:qonteo:default:1:7-] Notice: 
Host dashboard.qonteo.com X-Real-IP 186.241.25.44 Connection close 
Content-Length 124783 Authorization {Bearer 
eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9.eydzdWInOiAnNzA0JywgJ2lhdCc6IDE1OTA1MzAxODZ9.20f471933ae0a9c58d525f4ab0c1eef7adab03f17c3bbe18a00cf30a1ef06948}
 Content-Type application/json User-Agent PostmanRuntime/7.26.5 Accept */* 
Cache-Control no-cache Postman-Token 11c80053-7900-40d9-9a4c-688202241247 
Cookie {ad_locale="es_ES"; 
ad_session_id="1433%2c0%2c0%2c1605988670%20{451%201605989870%20AD31BFFB853E3AF51C2782F7F62798E155436A99}"}
[21/Nov/2020:17:03:27][29540.7efbf356f700][-conn:qonteo:default:1:7-] Notice: 
site_node__node_id 219402
[21/Nov/2020:17:03:27][29540.7efbf356f700][-conn:qonteo:default:1:7-] Notice: 
permission_p 1
[21/Nov/2020:17:03:27][29540.7efbf356f700][-conn:qonteo:default:1:7-] Notice: 
permission_p 0






> On Rab. II 6, 1442 AH, at 16:27, Maksym Zinchenko  wrote:
> 
> Hello Iuri, I think you misunderstood my question.
> My problem is not to set but to get "ns_set"
> 
> I'm using this: 
> https://naviserver.sourceforge.io/n/naviserver/files/ns_conn.html#4 
>  <https://naviserver.sourceforge.io/n/naviserver/files/ns_conn.html#4>
> 
> When client sends request to my server i want to get authentication method 
> using [ ns_conn auth <> ]
> Here is simple example code:
> ...
> ns_register_proc GET /test_api ::api::test_api
> 
> proc test_api {args} {
> set url [file split [ns_conn url]]
> set api_version [lindex $url 2]
> set resource [lindex $url 3]
> set method [ns_conn method]
> set auth [ns_conn auth]
> 
> puts "AUTHORIZATION: [ns_set array $auth]"
> puts "HEADERS: [ns_set array [ns_conn headers]]"
> ns_respond -status 200 -type "application/txt" -string "OK"
> }
> ...
> 
> This is what i get when use basic, looks good:
> ...
> AUTHORIZATION: AuthMethod Basic Password admin Username admin
> HEADERS: Host dev.testdomain.org <http://dev.testdomain.org/> Accept */* 
> Accept-Encoding {deflate, gzip} Authorization {Basic YWRtaW46YWRtaW4=} 
> User-Agent {Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 
> Firefox/83.0} X-Real-IP 
> xxx.90.xxx.244
> ...
> 
> This is what I get using bearer:
> 
> ...
> AUTHORIZATION: 
> HEADERS: Host dev.testdomain.org <http://dev.testdomain.org/> Accept */* 
> Accept-Encoding {deflate, gzip} Authorization {Bearer } 
> User-Agent {Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 
> Firefox/83.0} X-Real-IP xxx.90.xxx.244
> 
> ...
> 
> I was expecting [ns_conn auth <>] to return something like: AuthMethod bearer 
> Token 
> 
> 
> 
> 
> 
> 
> 
> On Sat, Nov 21, 2020 at 4:50 PM Iuri

Re: [naviserver-devel] Connect to a web socket in the background

[Iuri de Araujo Sampaio]

Thanks Gustaf,  

I’m going to uninstall the older version of TCLLIB.


Yes it works! It’s more than enough!
In fact, since your previous commit, last Sunday the weekend, I was able to 
understand the implementation "workflow" and aspects of writing a client app in 
the backend scene. 

I’m going to download the latest commit and try it out. 

Furthermore, Chat and log-viewer samples are very nice and clean. You guys have 
separated very well the frontend app and backend in the ADP and TCL files 
respectively. 

Best wishes,
I



> On Dhuʻl-Q. 23, 1441 AH, at 08:08, Gustaf Neumann  wrote:
> 
> On 12.07.20 02:14, Iuri de Araujo Sampaio wrote:
> 
>> However, when I run the first version of the code, and it returns an error 
>> related to: Error: can't set "formMap": variable is array
>> 
>> /usr/local/src/ns-4.9.17/tcl8.6.8/library/http/http.tcl: return [string 
>> map $formMap $string]
>> /usr/local/src/tcl8.6.9/library/http/http.tcl:   variable formMap [array 
>> get map]
>> 
>> The error is related to core packages, and I believe it happens to fail 
>> because that source is some sort of an old code. Thus, it’s not a good idea 
>> to fork it at all.
> Dear Iuri, 
> 
> this error comes form the tcllib (and it seems, you have two versions of 
> tcllib installed). This error is not related with NaviServer, i have no 
> knowledge about the internals of the tcllibs' http package.
> 
> As you have noticed, i have added a simple client side interface to the 
> websocket package of NaviServer on bitbucket. In essence, this means to add 
> support for "masked" messages, which are required for client frames
> for WebSockets. 
> I've also added client-side SNI support to ns_connchan to be able to connect 
> to a server with virtual hosting via HTTPS that provides multiple 
> certificates via SNI (Server Name Indication). So the current version of the 
> NaviServer websocket module (just committed) requires as well the current 
> version of NaviServer.
> 
> Don't expect this little interface (client-side websocket: ~150 LOC) to be 
> feature complete. It does not handle e.g. WebSocket continuations, etc. ... 
> but the following snippet should work ok.
> 
> -gn
> 
> ===
> 
>   set WSURL wss://javascript.info/article/websocket/demo/hello 
> 
>   set chan [ws::client::open $WSURL]
> 
>   # Send "Hello Wörld" to the echo service
>   ws::client::send $chan "Hello Wörld"
> 
>   # Get the reply and decode it (will return "Hello from server, Wörld!")
>   set replyText [ws::client::receive $chan]
> 
>   # ... do some more work and finally close the channel
>   ws::client::close $chan
> 
> 
> ___
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] Connect to a web socket in the background

[Iuri de Araujo Sampaio]

The errors related to [dict] have been fixed, adding the following lines within 
websocket-procs.tcl

…
 nsf::proc ::ws::client::open {url} {
...
line 437
 if {[dict exists $d path] ne ""} {
set path [dict get $d path]
append request_url /$path
}
if {[dict exists $d tail] ne ""} {
set tail [dict get $d tail]
append request_url /$tail
}


Even though, I still see no reason your code would break, because the wss 
sample does return “path”.
The case of failure is when the websocket  doesn’t return neither path nor tail.

>> The websocket sample is  "wss://javascript.info/article/websocket/demo/hello 
>> "

[12/Jul/2020:21:44:37][23102.7efbf356f700][-conn:iurix:1:92-] Notice: D
 proto wss host javascript.info path article/websocket/demo tail hello
 



Now, I’ve hit another situation. That error seems more serious. :)


12/Jul/2020:21:44:37][23102.7efbf356f700][-conn:iurix:1:92-] Notice: Running 
TCL script luna.tcl
[12/Jul/2020:21:44:37][23102.7efbf356f700][-conn:iurix:1:92-] Notice: D
 proto wss host javascript.info path article/websocket/demo tail hello
[12/Jul/2020:21:44:37][23102.7efbf356f700][-conn:iurix:1:92-] Notice: 
SockConnect: target host  has associated multiple IP addresses 
<104.26.12.17 104.26.13.17 172.67.74.41>
[12/Jul/2020:21:44:37][23102.7efbf356f700][-conn:iurix:1:92-] Notice: async 
connect to 104.26.12.17 on sock 27 returned EINPROGRESS
[12/Jul/2020:21:44:37][23102.7efbf356f700][-conn:iurix:1:92-] Error: ssl 
connect failed: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure
while executing
"ns_connchan open -headers $headers -version 1.1 $request_url"
(procedure "ws::client::open" line 30)
invoked from within
"ws::client::open $url"
("uplevel" body line 8)
invoked from within
"uplevel {
  
(procedure "code::tcl::/var/www/iurix//packages/ix-websocket/www/ws-sample" 
line 2)
invoked from within
"code::tcl::$__adp_stub"
("uplevel" body line 12)
invoked from within
"uplevel {

if { [file exists $__adp_stub.tcl] } {

# ensure that data source preparation procedure exists and is 
up-to-date
  ..."
(procedure "adp_prepare" line 2)
invoked from within
"adp_prepare"
invoked from within
"template::adp_parse $themed_template {}"
(procedure "adp_parse_ad_conn_file" line 14)
invoked from within
"$handler"
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
        $handler
    } ad_script_abort val {
# do nothing
}"
invoked from within
"rp_serve_concrete_file [ad_conn file]"







> On Dhuʻl-Q. 21, 1441 AH, at 21:14, Iuri de Araujo Sampaio  
> wrote:
> 
> … I've hit “send” button by mistake….
> 
> Hi Gustaf
> I’ve noticed you had  uploaded a simple client interface to 
> websocket-procs.tcl. 
> https://bitbucket.org/naviserver/websocket/src/master/websocket-procs.tcl 
> <https://bitbucket.org/naviserver/websocket/src/master/websocket-procs.tcl>
> 
> However, I hit another error related to [dict], because the url doesn’t 
> return a path, when [dict get $d path] runs. 
> 
> The websocket sample is  "wss://javascript.info/article/websocket/demo/hello 
> ”,which returns the 
> following content
> 
> [12/Jul/2020:21:10:09][22414.7efbf37fe700][-conn:iurix:0:9-] Notice: D
>  proto wss host javascript.info <http://javascript.info/> path 
> article/websocket/demo tail hello
> 
> 
> 
> I’m going to continue writing this client. I don’t know if you are in the 
> middle the implementation but I shall thank you in advance. That’s been very 
> helpful already.
> 
> Best wishes,
> I
> 
> 
>> On Dhuʻl-Q. 21, 1441 AH, at 21:08, Iuri de Araujo Sampaio > <mailto:i...@iurix.com>> wrote:
>> 
>> Hi Gustaf,
>> I’ve noticed you had  uploaded a simple client interface to 
>> websocket-procs.tcl. 
>> https://bitbucket.org/naviserver/websocket/src/master/websocket-procs.tcl 
>> <https://bitbucket.org/naviserver/websocket/src/master/websocket-procs.tcl>
>> 
>> However, I hit another error related to [dict], because the url doesn’t 
>> return a path, when [dict get $d path] runs. 
>> The websocket sample is  "wss://javascript.info/article/websocket/demo/hello 
>> "
>> 
>> Best wishes,
>> I
>> 
>> 
>> 
> [12/Jul/2020:21:10:09][22414.7efbf37fe700][-conn:iurix:0:9-] Notice: D
>  proto wss host javascript.info <http://javascript.info/> path 
> article/websocket/demo tail 

Re: [naviserver-devel] Connect to a web socket in the background

[Iuri de Araujo Sampaio]

… I've hit “send” button by mistake….

Hi Gustaf
I’ve noticed you had  uploaded a simple client interface to 
websocket-procs.tcl. 
https://bitbucket.org/naviserver/websocket/src/master/websocket-procs.tcl 
<https://bitbucket.org/naviserver/websocket/src/master/websocket-procs.tcl>

However, I hit another error related to [dict], because the url doesn’t return 
a path, when [dict get $d path] runs. 

The websocket sample is  "wss://javascript.info/article/websocket/demo/hello 
”,which returns the 
following content

[12/Jul/2020:21:10:09][22414.7efbf37fe700][-conn:iurix:0:9-] Notice: D
 proto wss host javascript.info path article/websocket/demo tail hello



I’m going to continue writing this client. I don’t know if you are in the 
middle the implementation but I shall thank you in advance. That’s been very 
helpful already.

Best wishes,
I


> On Dhuʻl-Q. 21, 1441 AH, at 21:08, Iuri de Araujo Sampaio  
> wrote:
> 
> Hi Gustaf,
> I’ve noticed you had  uploaded a simple client interface to 
> websocket-procs.tcl. 
> https://bitbucket.org/naviserver/websocket/src/master/websocket-procs.tcl 
> <https://bitbucket.org/naviserver/websocket/src/master/websocket-procs.tcl>
> 
> However, I hit another error related to [dict], because the url doesn’t 
> return a path, when [dict get $d path] runs. 
> The websocket sample is  "wss://javascript.info/article/websocket/demo/hello 
> "
> 
> Best wishes,
> I
> 
> 
> 
[12/Jul/2020:21:10:09][22414.7efbf37fe700][-conn:iurix:0:9-] Notice: D
 proto wss host javascript.info path article/websocket/demo tail hello
> [12/Jul/2020:21:03:33][22342.7efbf37fe700][-conn:iurix:0:36-] Error: can't 
> read "path": no such variable
> while executing
> "append request_url /$path"
> (procedure "ws::client::open" line 19)
> invoked from within
> "ws::client::open $url"
> ("uplevel" body line 8)
> invoked from within
> "uplevel {
> ns_log Notice "Running TCL script luna.tcl"
> 
> (procedure "code::tcl::/var/www/iurix//packages/ix-websocket/www/luna" 
> line 2)
> invoked from within
> "code::tcl::$__adp_stub"
> ("uplevel" body line 12)
> invoked from within
> "uplevel {
> 
> if { [file exists $__adp_stub.tcl] } {
> 
> # ensure that data source preparation procedure exists and is 
> up-to-date
>   ..."
> (procedure "adp_prepare" line 2)
> invoked from within
> "adp_prepare"
> invoked from within
> "template::adp_parse $themed_template {}"
> (procedure "adp_parse_ad_conn_file" line 14)
> invoked from within
> "$handler"
> ("uplevel" body line 2)
> invoked from within
> "uplevel $code"
> invoked from within
> "ad_try {
> $handler
>     } ad_script_abort val {
> # do nothing
> }"
> invoked from within
> "rp_serve_concrete_file [ad_conn file]"
> (procedure "::nsf::procs::rp_serve_abstract_file" line 60)
> invoked from within
> "rp_serve_abstract_file "$root/$extra_url""
> ("uplevel" body line 2)
> invoked from within
> 
> 
>> On Dhuʻl-Q. 20, 1441 AH, at 21:14, Iuri de Araujo Sampaio > <mailto:i...@iurix.com>> wrote:
>> 
>> Hi there,
>> 
>> My code's intended to open a websocket connection to the echo service, wait 
>> 400ms to ensure that the connection is really established and send a textual 
>> message, which should be echoed back by the echo service. 
>> 
>> The last part will be handling/parsing that message (i.e. TXT or JSON 
>> message, which was echoed in that channel). Thus, every time a message comes 
>> through the channel a callback will be in charge to parse that message and 
>> store its content.
>> 
>> However, when I run the first version of the code, and it returns an error 
>> related to: Error: can't set "formMap": variable is array
>> 
>> 
>> /usr/local/src/ns-4.9.17/tcl8.6.8/library/http/http.tcl: return [string 
>> map $formMap $string]
>> /usr/local/src/tcl8.6.9/library/http/http.tcl:   variable formMap [array 
>> get map]
>> 
>> 
>> The error is related to core packages, and I believe it happens to fail 
>> because that source is some sort of an old code. Thus, it’s not a good idea 
>> to fork it at all.  
>> How would refactor a "background websocket connection", using the new 
>> implementation available at: 
>> https://bitbucket

Re: [naviserver-devel] Connect to a web socket in the background

[Iuri de Araujo Sampaio]

Hi Gustaf,
I’ve noticed you had  uploaded a simple client interface to 
websocket-procs.tcl. 
https://bitbucket.org/naviserver/websocket/src/master/websocket-procs.tcl 
<https://bitbucket.org/naviserver/websocket/src/master/websocket-procs.tcl>

However, I hit another error related to [dict], because the url doesn’t return 
a path, when [dict get $d path] runs. 
The websocket sample is  "wss://javascript.info/article/websocket/demo/hello"

Best wishes,
I



[12/Jul/2020:21:03:33][22342.7efbf37fe700][-conn:iurix:0:36-] Error: can't read 
"path": no such variable
while executing
"append request_url /$path"
(procedure "ws::client::open" line 19)
invoked from within
"ws::client::open $url"
("uplevel" body line 8)
invoked from within
"uplevel {
ns_log Notice "Running TCL script luna.tcl"


#set url 
"ws://192.199.241.130:5008/api/subscribe?auth_token=9fb6e731-b342-4952-b0c1-aa1d0..."
(procedure "code::tcl::/var/www/iurix//packages/ix-websocket/www/luna" line 
2)
invoked from within
"code::tcl::$__adp_stub"
("uplevel" body line 12)
invoked from within
"uplevel {

if { [file exists $__adp_stub.tcl] } {

# ensure that data source preparation procedure exists and is 
up-to-date
  ..."
(procedure "adp_prepare" line 2)
invoked from within
"adp_prepare"
invoked from within
"template::adp_parse $themed_template {}"
(procedure "adp_parse_ad_conn_file" line 14)
invoked from within
"$handler"
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
$handler
} ad_script_abort val {
# do nothing
}"
invoked from within
"rp_serve_concrete_file [ad_conn file]"
    (procedure "::nsf::procs::rp_serve_abstract_file" line 60)
invoked from within
"rp_serve_abstract_file "$root/$extra_url""
("uplevel" body line 2)
invoked from within


> On Dhuʻl-Q. 20, 1441 AH, at 21:14, Iuri de Araujo Sampaio  
> wrote:
> 
> Hi there,
> 
> My code's intended to open a websocket connection to the echo service, wait 
> 400ms to ensure that the connection is really established and send a textual 
> message, which should be echoed back by the echo service. 
> 
> The last part will be handling/parsing that message (i.e. TXT or JSON 
> message, which was echoed in that channel). Thus, every time a message comes 
> through the channel a callback will be in charge to parse that message and 
> store its content.
> 
> However, when I run the first version of the code, and it returns an error 
> related to: Error: can't set "formMap": variable is array
> 
> 
> /usr/local/src/ns-4.9.17/tcl8.6.8/library/http/http.tcl:  return [string 
> map $formMap $string]
> /usr/local/src/tcl8.6.9/library/http/http.tcl:variable formMap [array 
> get map]
> 
> 
> The error is related to core packages, and I believe it happens to fail 
> because that source is some sort of an old code. Thus, it’s not a good idea 
> to fork it at all.  
> How would refactor a "background websocket connection", using the new 
> implementation available at: 
> https://bitbucket.org/naviserver/websocket/src/master/ 
> <https://bitbucket.org/naviserver/websocket/src/master/> ?
> 
> Here it’s the code
> 
> package require websocket
> ::websocket::loglevel debug
> proc handler { sock type msg } {
> switch -glob -nocase -- $type {
> co* {
> ns_log Notice "Connected on $sock"
> puts "Connected on $sock"
> 
> }
> te* {
> ns_log Notice "RECEIVED $msg"
> puts "RECEIVED: $msg"
> }
> cl* -
> dis* {
> }
> }
> 
> }
> proc test { sock } {
> puts "[::websocket::conninfo $sock type] from [::websocket::conninfo 
> $sock sockname] to [::websocket::conninfo $sock peername]"
> 
> ::websocket::send $sock text "Testing, testing..."
> }
> set sock [::websocket::open 
> wss://javascript.info/article/websocket/demo/hello 
>  handler]
> ns_log Notice "SOCKET \n $socket"
> after 400 test $sock
> vwait forever
> 
> 
> 
> 
> Documentation Reference: 
> https://core.tcl-lang.org/tcllib/doc/tcllib-1-17/embedded/www/tcllib/files/modules/websocket/websocket.html#1
>  
> <https://core.tcl-lang.org/tcllib/doc/tcllib-1-17/embedded/www/tcllib/files/modules/websocket/websocket.html#1>
> 
> 
> Best wishes,
> I
> 
&

[naviserver-devel] Connect to a web socket in the background

[Iuri de Araujo Sampaio]

Hi there,

My code's intended to open a websocket connection to the echo service, wait 
400ms to ensure that the connection is really established and send a textual 
message, which should be echoed back by the echo service. 

The last part will be handling/parsing that message (i.e. TXT or JSON message, 
which was echoed in that channel). Thus, every time a message comes through the 
channel a callback will be in charge to parse that message and store its 
content.

However, when I run the first version of the code, and it returns an error 
related to: Error: can't set "formMap": variable is array


/usr/local/src/ns-4.9.17/tcl8.6.8/library/http/http.tcl:return [string 
map $formMap $string]
/usr/local/src/tcl8.6.9/library/http/http.tcl:  variable formMap [array get map]


The error is related to core packages, and I believe it happens to fail because 
that source is some sort of an old code. Thus, it’s not a good idea to fork it 
at all.  
How would refactor a "background websocket connection", using the new 
implementation available at: 
https://bitbucket.org/naviserver/websocket/src/master/ 
 ?

Here it’s the code

package require websocket
::websocket::loglevel debug
proc handler { sock type msg } {
switch -glob -nocase -- $type {
co* {
ns_log Notice "Connected on $sock"
puts "Connected on $sock"

}
te* {
ns_log Notice "RECEIVED $msg"
puts "RECEIVED: $msg"
}
cl* -
dis* {
}
}

}
proc test { sock } {
puts "[::websocket::conninfo $sock type] from [::websocket::conninfo $sock 
sockname] to [::websocket::conninfo $sock peername]"

::websocket::send $sock text "Testing, testing..."
}
set sock [::websocket::open wss://javascript.info/article/websocket/demo/hello 
handler]
ns_log Notice "SOCKET \n $socket"
after 400 test $sock
vwait forever




Documentation Reference: 
https://core.tcl-lang.org/tcllib/doc/tcllib-1-17/embedded/www/tcllib/files/modules/websocket/websocket.html#1
 



Best wishes,
I






[11/Jul/2020:20:39:38][471.7efbf37fe700][-conn:iurix:0:91-] Error: can't set 
"formMap": variable is array
while executing
"variable formMap [array get map]"
(procedure "init" line 15)
invoked from within
"init"
(in namespace eval "::http" script line 83)
invoked from within
"namespace eval http {
# Allow resourcing to not clobber existing data

variable http
if {![info exists http]} {
array set http {
-ac..."
(file "/usr/local/ns/lib/tcl8/8.6/http-2.9.0.tm" line 16)
invoked from within
"source -encoding utf-8 /usr/local/ns/lib/tcl8/8.6/http-2.9.0.tm"
("package ifneeded http 2.9.0" script)
invoked from within
"package require http 2.7"
(file "/usr/local/ns/lib/tcllib1.19/websocket/websocket.tcl" line 20)
invoked from within
"source /usr/local/ns/lib/tcllib1.19/websocket/websocket.tcl"
("package ifneeded websocket 1.4.1" script)
invoked from within
"package require websocket"
("uplevel" body line 3)
invoked from within
"uplevel {

package require websocket
::websocket::loglevel debug
proc handler { sock type msg } {
switch -glob -nocase -- $type {
co* {
..."
(procedure "code::tcl::/var/www/iurix//packages/ix-websocket/www/ws2" line 
2)
invoked from within
"code::tcl::$__adp_stub"
("uplevel" body line 12)
invoked from within
"uplevel {

if { [file exists $__adp_stub.tcl] } {

# ensure that data source preparation procedure exists and is 
up-to-date
  ..."
(procedure "adp_prepare" line 2)
invoked from within
"adp_prepare"
invoked from within
"template::adp_parse $themed_template {}"
(procedure "adp_parse_ad_conn_file" line 14)
invoked from within
"$handler"
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
$handler
} ad_script_abort val {
# do nothing
}"
invoked from within
"rp_serve_concrete_file [ad_conn file]"
(procedure "::nsf::procs::rp_serve_abstract_file" line 60)
invoked from within
"rp_serve_abstract_file "$root/$extra_url""
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
rp_serve_abstract_file "$root/$extra_url"
set ::tcl_url2file([ad_conn url]) [ad_conn file]
se..."
called from rp_handler
GET http://iurix.com/websocket/ws2? referred by '' peer 192.199.241.135 
user_id 0

 Host:  iurix.com
 X-Real-IP: 179.199.201.237
 Connection:close
 Upgrade-Insecure-Requests: 1
 User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 

Re: [naviserver-devel] [ns_getform] doesn't get form-data fields

[Iuri de Araujo Sampaio]

Indeed! 
In fact, A.I. has been playing a big role in this field already (i.e. 
self-healing). We could bring into TCL’s world! 

Most of the time I get lazy, skipping test-cases, going directly to debug 
without planing and writing unit tests, then I miss the opportunity to get a 
better perspective of the implementation. 

That, I’d call it as "self-sabotage”. As It could save me a lot of time and 
headaches, debugging codes.

Best wishes,
I 

> On Jul 4, 2020, at 14:10, Gustaf Neumann  wrote:
> 
> Maybe, we should add "self-healing" to the feature list of NaviServer :)
> 
> In general, it is a good idea to make test-cases with curl, also for you to 
> understand, what is going on in detail.
> 
> all the best
> 
> -gn
> 
> On 04.07.20 18:37, Iuri de Araujo Sampaio wrote:
>> Hi,
>> I woke up today and Postman requests work fine now. I have no clue what the 
>> error was, and I have done nothing to fix it.
>> 
>> Well, I added a log message in the first line, before calling [ns_getform], 
>> but that would no affect the problem. Maybe the stars were playing with me 
>> last night. Or it was a cache refreshing delay. Who knows? k
>> 
>> ns_log Notice "CTree $cTree  "
>> 
>> Best wishes,
>> I
>> 
>>   
>> 
>>> On Jul 4, 2020, at 00:25, Iuri de Araujo Sampaio >> <mailto:i...@iurix.com>> wrote:
>>> 
>>> Hello there,
>>> 
>>> Reading [ns_getform] documentation, I noticed it supports 
>>> multipart/form-data
>>> https://naviserver.sourceforge.io/n/naviserver/files/ns_getform.html 
>>> <https://naviserver.sourceforge.io/n/naviserver/files/ns_getform.html>
>>> 
>>> However, when I run the chunk bellow, it shows no form, neither fields and 
>>> values at all, in the GET request.  
>>> 
>>> I’ve written [ns_getcontent …] right bellow the chunk, confirming that the 
>>> body of the request has content within it, plus in the proper format (i.e. 
>>> multipart/form-data). 
>>> 
>>> Furthermore, if I switch the request to application/x-www-form-urlencoded 
>>> the chunk works just fine and form fields are properly assigned. Thus, I’m 
>>> lost!
>>> 
>>> Could it be that Postman uses a different format for form-data? (Thus, it 
>>> isn’t supported by ns_getform.)
>>> 
>>> Logs are bellow.
>>> 
>>> Best wishes.
>>> I
>>> 
>>> 
>>>   set myform [ns_getform]
>>> if {[string equal "" $myform]} {
>>> ns_log Notice "No Form was submited"
>>> } else {
>>> ns_log Notice "FORM"
>>> ns_set print $myform
>>> for {set i 0} {$i < [ns_set size $myform]} {incr i} {
>>> set varname [ns_set key $myform $i]
>>> set varvalue [ns_set value $myform $i]
>>> 
>>> ns_log Notice " $varname - $varvalue"
>>> }
>>> }
>>> 
>>> ns_log Notice "BODY \n  [ns_getcontent -as_file false]”
>>> 
>>> 
>>> 
>>> 
>>> 
>>> [04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: 
>>> HEADER 
>>>  t0
>>> [04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: 
>>> HEADERS 11
>>> [04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: Host 
>>> iurix.com <http://iurix.com/> X-Real-IP 
>>> 179.199.203.207 Connection close Content-Length 386 authorization {Bearer 
>>> eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9.eydzdWInOiAnNTk0MycsICdpYXQnOiAxNTkzODI2NjQ0fQ==.20f471933ae0a9c58d525f4ab0c1eef7adab03f17c3bbe18a00cf30a1ef06948}
>>>  User-Agent PostmanRuntime/7.25.0 Accept */* Cache-Control no-cache 
>>> Postman-Token 93e1f2b8-b680-470f-be60-52a25c93db0a Content-Type 
>>> {multipart/form-data; 
>>> boundary=--973675580213918217977892} Cookie 
>>> ad_session_id=\"35550042%2c0%2c0%2c1593831987%20{947%201593833187%20876F0016C8883111AC63B5C6B6D964D76ED2D1DF}\"
>>> [04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: FORM
>>> [04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: BODY 
>>>   973675580213918217977892
>>> Content-Disposition: form-data; name="cTree"
>>> 
>>> featured
>>> 973675580213918217977892
>>> Content-Disposi

Re: [naviserver-devel] [ns_getform] doesn't get form-data fields

[Iuri de Araujo Sampaio]

Hi,
I woke up today and Postman requests work fine now. I have no clue what the 
error was, and I have done nothing to fix it.

Well, I added a log message in the first line, before calling [ns_getform], but 
that would no affect the problem. Maybe the stars were playing with me last 
night. Or it was a cache refreshing delay. Who knows? k

ns_log Notice "CTree $cTree  "

Best wishes,
I

  

> On Jul 4, 2020, at 00:25, Iuri de Araujo Sampaio  wrote:
> 
> Hello there,
> 
> Reading [ns_getform] documentation, I noticed it supports multipart/form-data
> https://naviserver.sourceforge.io/n/naviserver/files/ns_getform.html 
> <https://naviserver.sourceforge.io/n/naviserver/files/ns_getform.html>
> 
> However, when I run the chunk bellow, it shows no form, neither fields and 
> values at all, in the GET request.  
> 
> I’ve written [ns_getcontent …] right bellow the chunk, confirming that the 
> body of the request has content within it, plus in the proper format (i.e. 
> multipart/form-data). 
> 
> Furthermore, if I switch the request to application/x-www-form-urlencoded the 
> chunk works just fine and form fields are properly assigned. Thus, I’m lost!
> 
> Could it be that Postman uses a different format for form-data? (Thus, it 
> isn’t supported by ns_getform.)
> 
> Logs are bellow.
> 
> Best wishes.
> I
> 
> 
>   set myform [ns_getform]
> if {[string equal "" $myform]} {
> ns_log Notice "No Form was submited"
> } else {
> ns_log Notice "FORM"
> ns_set print $myform
> for {set i 0} {$i < [ns_set size $myform]} {incr i} {
> set varname [ns_set key $myform $i]
> set varvalue [ns_set value $myform $i]
> 
> ns_log Notice " $varname - $varvalue"
> }
> }
> 
> ns_log Notice "BODY \n  [ns_getcontent -as_file false]”
> 
> 
> 
> 
> 
> [04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: HEADER 
>  t0
> [04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: 
> HEADERS 11
> [04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: Host 
> iurix.com <http://iurix.com/> X-Real-IP 179.199.203.207 Connection close 
> Content-Length 386 authorization {Bearer 
> eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9.eydzdWInOiAnNTk0MycsICdpYXQnOiAxNTkzODI2NjQ0fQ==.20f471933ae0a9c58d525f4ab0c1eef7adab03f17c3bbe18a00cf30a1ef06948}
>  User-Agent PostmanRuntime/7.25.0 Accept */* Cache-Control no-cache 
> Postman-Token 93e1f2b8-b680-470f-be60-52a25c93db0a Content-Type 
> {multipart/form-data; 
> boundary=--973675580213918217977892} Cookie 
> ad_session_id=\"35550042%2c0%2c0%2c1593831987%20{947%201593833187%20876F0016C8883111AC63B5C6B6D964D76ED2D1DF}\"
> [04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: FORM
> [04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: BODY 
>   973675580213918217977892
> Content-Disposition: form-data; name="cTree"
> 
> featured
> 973675580213918217977892
> Content-Disposition: form-data; name="cTreeName"
> 
> t
> 973675580213918217977892
> Content-Disposition: form-data; name="cTreeIcon"
> 
> t
> 973675580213918217977892--
> 
> [04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: TREE 
> [04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: cTree 
> ___
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

[naviserver-devel] [ns_getform] doesn't get form-data fields

[Iuri de Araujo Sampaio]

Hello there,

Reading [ns_getform] documentation, I noticed it supports multipart/form-data
https://naviserver.sourceforge.io/n/naviserver/files/ns_getform.html 


However, when I run the chunk bellow, it shows no form, neither fields and 
values at all, in the GET request.  

I’ve written [ns_getcontent …] right bellow the chunk, confirming that the body 
of the request has content within it, plus in the proper format (i.e. 
multipart/form-data). 

Furthermore, if I switch the request to application/x-www-form-urlencoded the 
chunk works just fine and form fields are properly assigned. Thus, I’m lost!

Could it be that Postman uses a different format for form-data? (Thus, it isn’t 
supported by ns_getform.)

Logs are bellow.

Best wishes.
I


  set myform [ns_getform]
if {[string equal "" $myform]} {
ns_log Notice "No Form was submited"
} else {
ns_log Notice "FORM"
ns_set print $myform
for {set i 0} {$i < [ns_set size $myform]} {incr i} {
set varname [ns_set key $myform $i]
set varvalue [ns_set value $myform $i]

ns_log Notice " $varname - $varvalue"
}
}

ns_log Notice "BODY \n  [ns_getcontent -as_file false]”





[04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: HEADER 
 t0
[04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: HEADERS 
11
[04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: Host 
iurix.com X-Real-IP 179.199.203.207 Connection close Content-Length 386 
authorization {Bearer 
eyJhbGciOiAiSFMyNTYiLCAidHlwIjogIkpXVCJ9.eydzdWInOiAnNTk0MycsICdpYXQnOiAxNTkzODI2NjQ0fQ==.20f471933ae0a9c58d525f4ab0c1eef7adab03f17c3bbe18a00cf30a1ef06948}
 User-Agent PostmanRuntime/7.25.0 Accept */* Cache-Control no-cache 
Postman-Token 93e1f2b8-b680-470f-be60-52a25c93db0a Content-Type 
{multipart/form-data; 
boundary=--973675580213918217977892} Cookie 
ad_session_id=\"35550042%2c0%2c0%2c1593831987%20{947%201593833187%20876F0016C8883111AC63B5C6B6D964D76ED2D1DF}\"
[04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: FORM
[04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: BODY 
  973675580213918217977892
Content-Disposition: form-data; name="cTree"

featured
973675580213918217977892
Content-Disposition: form-data; name="cTreeName"

t
973675580213918217977892
Content-Disposition: form-data; name="cTreeIcon"

t
973675580213918217977892--

[04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: TREE 
[04/Jul/2020:00:07:19][8773.7efbf2d6e700][-conn:iurix:1:1031-] Notice: cTree ___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] Verifying HMAC signature [ns_crypto::hmac ...]

[Iuri de Araujo Sampaio]

Thanks Gustaf,
Yes, it works fine!
I was not capable to understand the verification part. I was trying to learn it 
by repeating the method of base64* with encode/decode. Then, after decrypting, 
to verify if secret and data were both the same from the original request 
Best wishes,
I



On May 26, 2020, at 13:05, i...@iurix.com  wrote:

Thanks Gustaf,
It works now.

p.s. I don't understand why the subject of this thread got replaced with a 
previous thread that I opened.
The original email that I sent has the subject: "Verifying HMAC signature 
[ns_crypto::hmac ...]"

 Original Message 
Subject: Re: [naviserver-devel] What to do when [ns_base64encode]
doesn't encrypt properly after the 63rd char?
From: Gustaf Neumann mailto:neum...@wu.ac.at>>
Date: Tue, May 26, 2020 12:27 am
To: naviserver-devel@lists.sourceforge.net 


Iuri, 
The nsc_crypto::hmac performs the HMAC  (Keyed-Hashing for 
Message Authentication) as specified in RFC 2104, using a symmetric 
key provided via argument.

The HMAC can be verified the same way as a plain digest (without a secret):
If a received HMAC (or digest) should be verified, it must be recomputed.
In the case of the HMAC, the receiver has to know the secret. 

I see no need for an extra API call:
=== set 
secret_key "foobar1234" set data "This is my data" set HMAC [ns_crypto::hmac 
string -digest sha256 $secret_key $data] # # To verify a received HMAC , one 
needs the key and the data as well # if { $HMAC eq [ns_crypto::hmac string 
-digest sha256 $secret_key $data] } { ns_log notice "Data verified" } 
===
The ns_crypto interface provides as well the interface based on key files
(PEM files) provided for "ns_crypto::md". In the case of the pem 
files, it is more effort to extract keys, since there exists several 
algorithms, key types etc., which are in specified inside the PEM 
files. Therefore, this interface works for multiple key types, 
include RSA and elliptic curves.

In this variant,  the message key can be signed with 

   set sig [::ns_crypto::md string ... -sign PEM ...] 
and verified with 

   ::ns_crypto::md string ... -verify PEM -signature $sig ... 
Below is the example from the man page.

all the best
-gn
=== % 
set sig [::ns_crypto::md string \ -digest sha1 \ -encoding binary \ -sign 
/usr/local/src/naviserver/myprivate.pem \ "abcdefghijklmnopqrstuxvwxyz\n"] % 
set vfy [::ns_crypto::md string \ -digest sha1 \ -verify 
/usr/local/src/naviserver/myprivate.pem \ -signature $sig \ 
"abcdefghijklmnopqrstuxvwxyz\n"] 1 
===



___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net 

https://lists.sourceforge.net/lists/listinfo/naviserver-devel 

___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] What to do when [ns_base64encode] doesn't encrypt properly after the 63rd char?

[Iuri de Araujo Sampaio]

> What do you mean its not encoded correctly? 

item (2) is not encoded correctly using base64url 
(https://tools.ietf.org/html/rfc4648#section-5 
<https://tools.ietf.org/html/rfc4648#section-5>). Note that padding ("=") must 
be omitted as per https://tools.ietf.org/html/rfc7515#section-2 
<https://tools.ietf.org/html/rfc7515#section-2>

How would I use [ns_base64encoding], if i decide to add more content in the 
payload message? Is it possible?





> On May 25, 2020, at 08:55, Gustaf Neumann  wrote:
> 
> NaviServer has native support for base64 and base64url encoding/decoding
> See:
> 
>https://naviserver.sourceforge.io/n/naviserver/files/ns_base64.html 
> <https://naviserver.sourceforge.io/n/naviserver/files/ns_base64.html>
Okay, and what about the wring encrypt, (i.e. within “=“) after the 63rd char?





> On May 24, 2020, at 22:08, Maksym Zinchenko  wrote:
> 
> What do you mean its not encoded correctly? 
> 
> ns_base64decode 
> eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9SRVNUJywgJ3N1Yic
> 6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=
> {'iss': '2697341102', 'aud': 'iurix.com/REST <http://iurix.com/REST>', 
> 'sub': '704', 'iat': 1590365650}
> 
> 
> On Sun, May 24, 2020 at 11:56 PM Maksym Zinchenko  <mailto:siqsu...@gmail.com>> wrote:
> sourcecode/nsd/uuencode.c maybe
> 
> On Sun, May 24, 2020 at 11:23 PM Iuri de Araujo Sampaio  <mailto:i...@iurix.com>> wrote:
> Hi there,
> 
> It looks like [ns_base64encode] generates a wrong payload when message size 
> contains more than 63 characters. 
> 
> https://tools.ietf.org/html/rfc4648#section-5 
> <https://tools.ietf.org/html/rfc4648#section-5>
> An alternative alphabet has been suggested that would use "~" as the
>63rd character.
> 
> 
> (1) Payload, which generates a proper encryption.   
>   
> set payload [ns_base64encode "{'sub': '$user(user_id)', 'it': [ns_time]}”]
> 
> eydzdWInOiAnNzA0JywgJ2lhdCc6IDE1OTAzNjU2ODF9
> 
> (2) Payload, which generates a wrong encryption 
> 
> set payload [ns_base64encode "{'iss': '2697341102', 'aud': 
> 'iurix.com/REST <http://iurix.com/REST>', 'sub': '$user(user_id)', 'iat': 
> [ns_time]}”]
>  
> eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9SRVNUJywgJ3N1Yic6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=
> 
> 
> item (2) is not encoded correctly using base64url 
> (https://tools.ietf.org/html/rfc4648#section-5 
> <https://tools.ietf.org/html/rfc4648#section-5>). Note that padding ("=") 
> must be omitted as per https://tools.ietf.org/html/rfc7515#section-2 
> <https://tools.ietf.org/html/rfc7515#section-2>
> 
> How would I use [ns_base64encoding], if i decide to add more content in the 
> payload message? Is it possible?
> 
>  
> I was trying find where ns_base64encoding is implemented, within Naviserver 
> source code. But I haven’t found yet. 
> Then I’d be able to go deeper into the problem to identify the actual cause 
> and try to write a solution to it. 
> 
> Does anyone know where is the implementation of [ns_base64encode] ?
> 
> Best wishes,
> I 
> ___
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net 
> <mailto:naviserver-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel 
> <https://lists.sourceforge.net/lists/listinfo/naviserver-devel>
> ___
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] Registering/Allowing request method HTTP PUT

[Iuri de Araujo Sampaio]

Right on! Thanks Gustaf!

The error was in the registration call. I had assigned the virtual OACS url as 
the path to the file, instead of the physical path. As you brightly described 
in 
> ns_register_tcl PUT /REST2/ /usr/local/oacs-5-10/openacs-4/www/



and regarding “unfriendly” behavior
> The last request leads to a "method not allowed" result, since a PUT on 
> /shared 
> is indeed not allowed. This is the "unfriendly" behavior part. Clearly, in 
> the file-not-found case, the HTTP method should be changed to GET 
> 
I’ll handle it, using NGINX.

Thanks!



> On May 25, 2020, at 11:24, Gustaf Neumann  wrote:
> 
> On 25.05.20 01:17, Maksym Zinchenko wrote:
>> Sorry, actually I don't know about OpenACS, because Im just running NS with 
>> custom made app, so I assume it may be an OpenACS question. So I suggest  
>> you to ask on OpenACS forum.
> The problem is here a not really OpenACS, but related to typical OpenACS 
> configurations, 
> together with a somewhat unfriendly behavior of NaviServer (same in 
> AOLserver).
> Consider the following three register commands:
> 
>ns_register_tcl PUT /REST1/ test.tcl   ;# 
> /usr/local/oacs-5-10/openacs-4/www/test.tcl   
>ns_register_tcl PUT /REST2/ /usr/local/oacs-5-10/openacs-4/www/
>ns_register_tcl PUT /REST3/;# 
> /www/REST3/test.tcl
> On the right hand side, you see, how the files are actually mapped on my
> instance for requests like:
> 
>curl -X PUT -d 'hello world' http://localhost:8100/REST3/test.tcl 
> 
> 
> When these file exist, everything is fine, also with OpenACS installations.
> 
> However, when one points to a non-existing file, and the error 
> page mapping is configured, then the request leads to
> 
>PageRequest  FILE NOT 
> FOUND
>Interal redirect due to error page mapping to PUT /shared/404 
> The last request leads to a "method not allowed" result, since a PUT on 
> /shared 
> is indeed not allowed. This is the "unfriendly" behavior part. Clearly, in 
> the file-not-found case, the HTTP method should be changed to GET 
> (not sure, if this the best for all methods). 
> 
> Not sure, when i can look into this in more details.
> 
> Hope this helps
> 
> -gn
> 
> ___
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

[naviserver-devel] What to do when [ns_base64encode] doesn't encrypt properly after the 63rd char?

[Iuri de Araujo Sampaio]

Hi there,

It looks like [ns_base64encode] generates a wrong payload when message size 
contains more than 63 characters. 

https://tools.ietf.org/html/rfc4648#section-5 

An alternative alphabet has been suggested that would use "~" as the
   63rd character.


(1) Payload, which generates a proper encryption.   
  
set payload [ns_base64encode "{'sub': '$user(user_id)', 'it': [ns_time]}”]

eydzdWInOiAnNzA0JywgJ2lhdCc6IDE1OTAzNjU2ODF9

(2) Payload, which generates a wrong encryption 

set payload [ns_base64encode "{'iss': '2697341102', 'aud': 
'iurix.com/REST', 'sub': '$user(user_id)', 'iat': [ns_time]}”]
 
eydpc3MnOiAnMjY5NzM0MTAwMDAxMDInLCAnYXVkJzogJ2l1cml4LmNvbS9SRVNUJywgJ3N1Yic6ICc3MDQnLCAnaWF0JzogMTU5MDM2NTY1MH0=


item (2) is not encoded correctly using base64url 
(https://tools.ietf.org/html/rfc4648#section-5). Note that padding ("=") must 
be omitted as per https://tools.ietf.org/html/rfc7515#section-2

How would I use [ns_base64encoding], if i decide to add more content in the 
payload message? Is it possible?

 
I was trying find where ns_base64encoding is implemented, within Naviserver 
source code. But I haven’t found yet. 
Then I’d be able to go deeper into the problem to identify the actual cause and 
try to write a solution to it. 

Does anyone know where is the implementation of [ns_base64encode] ?

Best wishes,
I ___
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] Registering/Allowing request method HTTP PUT

[Iuri de Araujo Sampaio]

Thanks Maksym,
Be sorry for nothing.

At first, I though so too. But then, as the procedure is ns_* , OpenACS 
framework shouldn't interfere.  It’s just the framework running in the 
application level, and there should be no intermediary layer in this scenario.

I’m going to wait for more answers in this forum. Then I’ll post there.  
 

> On May 24, 2020, at 20:17, Maksym Zinchenko  wrote:
> 
> Sorry, actually I don't know about OpenACS, because Im just running NS with 
> custom made app, so I assume it may be an OpenACS question. So I suggest  you 
> to ask on OpenACS forum.
> 
> On Sun, May 24, 2020 at 9:00 PM Iuri de Araujo Sampaio  <mailto:i...@iurix.com>> wrote:
> Hello there! 
> Thanks Maksym, it’s always good to double check fundamentals. 
>   
> I’ve followed standard’s installation, using install-ns.sh script, available 
> on GitHub. https://github.com/gustafn/install-ns/ 
> <https://github.com/gustafn/install-ns/>
> 
> Plus,  http-handlers-init.tcl loads properly when NS starts. (logs are below)
> 
> My box runs NS and OpenACS on top of it. Nevertheless, I don’t think that 
> would be a problem. 
> 
> You may be right, though. I don’t know.
> 
> Please, see logs bellow.
> 
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading 
> packages/iurix-mail/tcl/iurix-mail-init.tcl...
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded 
> packages/iurix-mail/tcl/iurix-mail-init.tcl.
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading 
> packages/ix-currency/tcl/ix-currency-init.tcl...
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded 
> packages/ix-currency/tcl/ix-currency-init.tcl.
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading 
> packages/ix-restapi/tcl/httphandlers-init.tcl...
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded 
> packages/ix-restapi/tcl/httphandlers-init.tcl.
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading 
> packages/xml-rpc/tcl/system-init.tcl...
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded 
> packages/xml-rpc/tcl/system-init.tcl.
> [24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading 
> packages/xml-rpc/tcl/validator-init.tcl...
> [
> 
> 
> 
> 
> 
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: 
> NaviServer/4.99.18 (tar-4.99.18) starting
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: security 
> info: uid=1002, euid=1002, gid=1002, egid=1002
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: Tcl 
> version: 8.6.9
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: max files: 
> soft limit 524288, hard limit 524288
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Warning: nsmain: rl_cur 
> (524288) > FD_SETSIZE (1024), select() calls should not be used
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: pool default: 
> queueLength 90 low water 9 high water 90
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: 
> nsd/init.tcl[iurix]: booting virtual server:  Tcl system encoding: "utf-8"
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
> module nslog from file /usr/local/ns/bin/nslog.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nslog: opened 
> '/var/www/iurix/log//access.log'
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
> module nsdb from file /usr/local/ns/bin/nsdb.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
> module ns/db/driver/postgres from file /usr/local/ns/bin/nsdbpg.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsdbpg: version 
> 2.3 loaded, based on PostgreSQL 9.6.15 and libbpq 90617
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: dbinit: set 
> LogMinDuration for pool pool1 over 0.01 to 0.01
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: dbinit: set 
> LogMinDuration for pool pool2 over 0.01 to 0.01
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
> module nsproxy from file /usr/local/ns/bin/nsproxy.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
> module nssock_v4 from file /usr/local/ns/bin/nssock.so
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nssock_v4:0: 
> enable 0 spooler thread(s) 
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nssock_v4:0: 
> enable 2 writer thread(s) for downloads >= 1024 bytes, bufsize=8192 bytes, 
> HTML streaming 0
> [24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
> module nsssl_v4 from file /usr/local/ns

Re: [naviserver-devel] Registering/Allowing request method HTTP PUT

[Iuri de Araujo Sampaio]

Hello there! 
Thanks Maksym, it’s always good to double check fundamentals. 
  
I’ve followed standard’s installation, using install-ns.sh script, available on 
GitHub. https://github.com/gustafn/install-ns/ 


Plus,  http-handlers-init.tcl loads properly when NS starts. (logs are below)

My box runs NS and OpenACS on top of it. Nevertheless, I don’t think that would 
be a problem. 

You may be right, though. I don’t know.

Please, see logs bellow.

[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading 
packages/iurix-mail/tcl/iurix-mail-init.tcl...
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded 
packages/iurix-mail/tcl/iurix-mail-init.tcl.
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading 
packages/ix-currency/tcl/ix-currency-init.tcl...
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded 
packages/ix-currency/tcl/ix-currency-init.tcl.
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading 
packages/ix-restapi/tcl/httphandlers-init.tcl...
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded 
packages/ix-restapi/tcl/httphandlers-init.tcl.
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading 
packages/xml-rpc/tcl/system-init.tcl...
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loaded 
packages/xml-rpc/tcl/system-init.tcl.
[24/May/2020:18:30:10][30098.7efbff6ea700][-main-] Notice: Loading 
packages/xml-rpc/tcl/validator-init.tcl...
[





[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: 
NaviServer/4.99.18 (tar-4.99.18) starting
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: security 
info: uid=1002, euid=1002, gid=1002, egid=1002
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: Tcl version: 
8.6.9
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsmain: max files: 
soft limit 524288, hard limit 524288
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Warning: nsmain: rl_cur 
(524288) > FD_SETSIZE (1024), select() calls should not be used
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: pool default: 
queueLength 90 low water 9 high water 90
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsd/init.tcl[iurix]: 
booting virtual server:  Tcl system encoding: "utf-8"
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
module nslog from file /usr/local/ns/bin/nslog.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nslog: opened 
'/var/www/iurix/log//access.log'
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
module nsdb from file /usr/local/ns/bin/nsdb.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
module ns/db/driver/postgres from file /usr/local/ns/bin/nsdbpg.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsdbpg: version 2.3 
loaded, based on PostgreSQL 9.6.15 and libbpq 90617
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: dbinit: set 
LogMinDuration for pool pool1 over 0.01 to 0.01
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: dbinit: set 
LogMinDuration for pool pool2 over 0.01 to 0.01
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
module nsproxy from file /usr/local/ns/bin/nsproxy.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
module nssock_v4 from file /usr/local/ns/bin/nssock.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nssock_v4:0: enable 
0 spooler thread(s) 
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nssock_v4:0: enable 
2 writer thread(s) for downloads >= 1024 bytes, bufsize=8192 bytes, HTML 
streaming 0
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
module nsssl_v4 from file /usr/local/ns/bin/nsssl.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl_v4:0: enable 0 
spooler thread(s) 
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl_v4:0: enable 2 
writer thread(s) for downloads >= 1024 bytes, bufsize=16384 bytes, HTML 
streaming 0
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: OpenSSL OpenSSL 
1.1.0l  10 Sep 2019 initialized
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl: disabling 
SSLv2
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nsssl: version 2.1 
loaded, based on OpenSSL 1.1.0l  10 Sep 2019
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: modload: loading 
module libthread from file /usr/local/ns/lib/thread2.8.2/libthread2.8.2.so
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: nx::serializer 
version 2.3
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: XOTcl 2.3 loaded 
featuring: memcount 0 profile 0 memtrace 0 assertions 1 dtrace 0 development 0
[24/May/2020:18:30:06][30098.7efbff6ea700][-main-] Notice: Using ns_cache based 
on NX 2.3