openLuup and url parameters

Currently using openLuup Version 2019.09.02 Have to say I’m enjoying the additions to the Console.

Lately a plugin I’ve been using stopped working. Now this may be coincidence but may be not. In my readings, it seems that the http stuff in openLuup has been changed in more recent times. So imagine a url with these parameters on the end like so:

...?parm1=abc&parm2=xyz&parm3=

In the case of parm3 it has no value set. The plugin tested for:

(lul_parameters["parm3" ~= nil)

but now it needs to test for:

(lul_parameters["parm3" ~= "")

So wondering if any changes in openLuup may have changed how empty parms are handled ie nil versus empty string?

1 Like

mea culpa

Yes the HTTP server has undergone very extensive changes – for very good reasons – and now uses the Kepler project Web Server API (WSAPI) request library, cutting out a lot of flakey homemade code and fixing handling of POST content encoding, but obviously changing a few things in the process.

I’ve just run a check on Vera using a tiny little bit of server code which returns its parameters:

function Callback (_, p)
    local x = {}
    for n,v in pairs (p) do
        x[#x+1] = table.concat {n,'=',v}
    end
    return table.concat (x,','), "text/plain"
end

luup.register_handler ("Callback", "Callback")

(This has to be my favourite feature of Luup – it makes user-defined handlers SO easy!)

So calling this (on Vera) with:

http://Vera_IP/port_3480/data_request?id=lr_Callback&a=foo&b=garp&c=

returns

a=foo,b=garp

…so no sign of ‘c’ at all.

I recall checking this when I first wrote the server, because I think that the Vera convention is, in fact, non-standard (surprise!). Obviously, this slipped through my unit tests after the latest change.

I will fix it explicitly for Luup callbacks, but feel inclined to retain it for internal purposes, unless someone tells me that this is very wrong.

Sorry for the inconvenience!

AK

Fixed in the latest development version 19.10.12

Thanks for pointing this out.