From xk@gilawa.com Mon Nov 20 12:20:31 2023 From: Xenofon Karamanos To: sr-dev@lists.kamailio.org Subject: [sr-dev] Route $hfl negative index strange behaviour: Date: Mon, 20 Nov 2023 12:20:19 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1958001079==" --===============1958001079== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, I am working on extending $hfl and $hflc supporting some more headers. During= some experimentation, i stumbled in some weird behavior regarding $(hfl(Rout= e)[-1]) and negative indexing of $hfl pseudo-variable. Here is a breakdown of what's happening: in kamailio.cfg: request_route { =E2=80=82=E2=80=82=E2=80=82=E2=80=82xlog("L_INFO", "Route headers hdr: $hdr(R= oute)\n"); =E2=80=82=E2=80=82=E2=80=82=E2=80=82xlog("L_INFO", "Route headers hfl: $hfl(R= oute)\n"); xlog("L_INFO", "Route headers count: $hflc(Route)\n"); xlog("L_INFO", "Route headers 0: $(hfl(Route)[0])\n"); xlog("L_INFO", "Route headers 1: $(hfl(Route)[1])\n"); xlog("L_INFO", "Route headers 4: $(hfl(Route)[4])\n"); xlog("L_INFO", "Route headers -1: $(hfl(Route)[-1])\n"); xlog("L_INFO", "Route headers -2: $(hfl(Route)[-2])\n"); =E2=80=82=E2=80=82=E2=80=82=E2=80=82xlog("L_INFO", "Route headers -3: $(hfl(R= oute)[-3])\n"); ... } Now when sending a SIP message containing multiple headers that have comma se= parated values ie: OPTIONS_MSG_2CONTACTS=3D"OPTIONS sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=3Dz9hG4bK123456789 Max-Forwards: 70 From: ;tag=3D123456789 To: Call-ID: 987654321(a)192.168.1.100 CSeq: 1 OPTIONS Contact: ;expires=3D3600,;expi= res=3D3600,;expires=3D3600 Route: , , Route: , Content-Length: 0 " the logs show the weird behavior: Negative -1 should print the last header fo= und and so on (as stated by https://www.kamailio.org/wikidocs/cookbooks/devel= /pseudovariables/#hflname-header-field-with-list-of-bodies $hdr $hfl doc). Currently, -1 prints null and -2 prints the last one, -3 second to last and s= o on. This is probably a bug and not the expected behavior, or am i missing s= omething? INFO: {1 1 OPTIONS 987654321(a)192.168.1.100}