On Tue, 8 Dec 2015 20:52:45 +0000
Laurent Penot <[email protected]> wrote:

> Thx for your answer Thierry.
> 
> If you try with the URI : 
> /dump_headers.php?p1=value1&ua=word1;word2;word3&otherparam=test
> 
> Urlp called in haproxy configuration will return : “word1” which corresponds 
> to your answer.
> But if you use urlp from lua, it will return you the correct value, see my 
> dump :
> [info] 341/214152 (2580) : ua=word1;word2;word3
> 
> The difference of answer between theses 2 urlp call looks strange from my 
> side.
> As far as I know, a parameter value starts after the “=“ and ends either at 
> the first “&” encoutered or at the end of the URI.
> 
> So using urlp from lua, I thing there is only something wrong when there is 
> “;+” or “+;” in the value of the parameter.
> Using urlp from haproxy should have the same behaviour as using urlp from lua.
> 
> Does that make sense ? Or I’m really mistaken ?


Its a good question. I will see this ASAP because I'm curious. In
facts, the "txn.f:urlp()" is a wrapper on the "urlp" fucntion used
in the HAProxy config file.

Two differents behaviour hides probably a bug.

I just tested, and I reproduce the same behaviour in both cases.

Juste for information, the special compilation flag
"DEBUG=-DDEBUG_EXPR", enables a debug tools whih dump on screen some
contents:

   http-request set-var(sess.a) urlp(ua),debug

The previous line affect the content of the urlp to a variable (it is
useles), and the keyword "debug" dumps the result of "urlp(ua)" on
screen.

The Lua is your code. The result is:

   [debug converter] type: str <word1>
   [info] 341/224620 (8053) : ua=word1

So, the same response for both cases. I try with:

   QS: ?p1=value1&ua=word1;word2;word3&otherparam=test

   [debug converter] type: str <word1>
   [info] 341/224620 (8053) : ua=word1

   QS: ?p1=value1&ua=word1;+word2&otherparam=test

   [debug converter] type: str <word1>
   [info] 341/225213 (8080) : ua=word1

   QS: ?p1=value1&ua=word1+;word2&otherparam=test

   [debug converter] type: str <word1+>
   [info] 341/225421 (8080) : ua=word1+

In all cases, there are the expected results and the same results.

I agree with a previous email "+;" and ";+" are valid url encoding.

Do I forgot or missed something ?

Thierry 


> 
> Best
> Laurent
> 
> 
> 
> 
> 
> 
> 
> On 08/12/15 11:23, "Thierry FOURNIER" <[email protected]> wrote:
> 
> >Hi,
> >
> >I agree with you, but in HAProxy, the ';' is considered as parameter
> >delimiter. Its hardcoded, and I don't known the reason.
> >
> >So the behaviour that you observe is the normal HAProxy behaviour.
> >
> >Thierry
> >
> >
> >
> >On Tue, 8 Dec 2015 09:17:38 +0000
> >Laurent Penot <[email protected]> wrote:
> >
> >> HI,
> >> 
> >> I received URL from which i need to extract several parameters, I do that 
> >> using urlp in lua. Values of parameters are urlencoded.
> >> And I notice something strange : urlp seems to get only the first part of 
> >> the value when the 2 char “;+” or “+;” are in the value of the parameter.
> >> 
> >> From the php point of view, using 
> >> http://php.net/manual/en/function.urlencode.php , the 2 char “;+” or “+;” 
> >> is valid in an urlencoded string.
> >> 
> >> 
> >> Here are 2 tests URL and the dumped value from lua:
> >> /dump_headers.php?p1=value1&ua=word1+;word2&otherparam=test
> >> [info] 341/090330 (130491) : ua=word1+
> >> The dumped value should be : word1+;word2
> >> 
> >> /dump_headers.php?p1=value1&ua=word1;+word2&otherparam=test
> >> [info] 341/090951 (130491) : ua=word1
> >> The dumped value should be : word1;+word2
> >> 
> >> Here is the haproxy config file (I removed everything not related to my 
> >> question) :
> >> global
> >>     debug
> >>     # lua file
> >>     lua-load url.lua
> >> 
> >> defaults
> >>     mode            http
> >> 
> >> frontend fe
> >>     bind :80
> >>     acl testurl url_beg /dump_headers.php
> >>     http-request lua.logValue if testurl
> >>     use_backend beok
> >> 
> >> backend beok
> >>     server mysrv 127.0.0.1:8080 check inter 1000ms fall 3 rise 1 weight 100
> >> 
> >> 
> >> Here is the lua file :
> >> core.register_action("logValue", {"http-req"}, function(txn)
> >>     local var = txn.f:urlp("ua");
> >>     core.Info("ua=" .. var);
> >> end)
> >> 
> >> 
> >> 
> >> haproxy -vv
> >> HA-Proxy version 1.6.2 2015/11/03
> >> Copyright 2000-2015 Willy Tarreau <[email protected]>
> >> 
> >> Build options :
> >>   TARGET  = linux2628
> >>   CPU     = generic
> >>   CC      = gcc
> >>   CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
> >>   OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=yes USE_DEVICEATLAS=1 
> >> USE_PCRE=1
> >> 
> >> Default settings :
> >>   maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
> >> 
> >> Encrypted password support via crypt(3): yes
> >> Built with zlib version : 1.2.3
> >> Compression algorithms supported : identity("identity"), 
> >> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
> >> Built with OpenSSL version : OpenSSL 1.0.2d 9 Jul 2015
> >> Running on OpenSSL version : OpenSSL 1.0.2d 9 Jul 2015
> >> OpenSSL library supports TLS extensions : yes
> >> OpenSSL library supports SNI : yes
> >> OpenSSL library supports prefer-server-ciphers : yes
> >> Built with PCRE version : 7.8 2008-09-05
> >> PCRE library supports JIT : no (USE_PCRE_JIT not set)
> >> Built with Lua version : Lua 5.3.1
> >> Built with transparent proxy support using: IP_TRANSPARENT 
> >> IPV6_TRANSPARENT IP_FREEBIND
> >> 
> >> Available polling systems :
> >>       epoll : pref=300,  test result OK
> >>        poll : pref=200,  test result OK
> >>      select : pref=150,  test result OK
> >> Total: 3 (3 usable), will use epoll.
> >> 
> >> Running on centos 6.
> >> I notice the same thing with haproxy 1.6.1 and lua 5.3.1 or 5.3.0
> >> 
> >> Note : in the frontend, if I use :     http-request set-header X-debugua 
> >> %[urlp(ua)]
> >> I get the same value as I get from Lua.
> >> 
> >> 
> >> Can you tell me if I do something the wrong way or if it is a bug or if it 
> >> is intended ?
> >> 
> >> Best regards
> >> Laurent
> >> 
> >> 
> >> 

Reply via email to