On 9/26/19 3:11 PM, Tim Duesterhus wrote:
Lua arrays start at the index 1 by convention:
However, it is customary in Lua to start arrays with index 1. The Lua
libraries adhere to this convention; so, if your arrays also start with 1,
you will be able to use their functions directly.
This patch makes the array 1-indexed. To preserve backwards compatibility
the first value for each header is duplicated into the index 0. While the
duplication might cause harm where a specific value order is expected or
required by HTTP standards (e.g. Transfer-Encoding) I consider the breakage
to be higher if index 0 ceases to exist.
While I agree that using zero based array indexing is a mistake (wearing
my Lua hat), I don't think your proposal will make situation any better.
Actually ot might hurt existing Lua code in unforeseen ways.
e.g. what happens if you have a Lua action or service which uses request
headers for its own nefarious purposes (like copying headers and using
them for new requests). It now sends duplicate headers (name, value)
which some upstream servers might not like.
Second thing, with Lua 5.2(?), "one" based arrays can use '#' operator
to get the array length. With your proposal, we'd have tables of length
N, where # operator would report N - 1 length
(That's just confusing, we'd have "1" based arrays which are not "1" based)
The last, but not the least, I am not fond of modifying request data by
the HAProxy Lua layer. Suddenly, existing Lua code would see duplicate
header values out of blue.
In my book, an improvement would be a new function, let's call it
hlua_http_get_headers_kv(), which returns table with header names as
keys, and values would be either "string" or array in case of multiple
header values (we can fold multiple values easily with Lua)...
Just my 2c.
HAProxy Technologies - Powering your uptime!
375 Totten Pond Road, Suite 302 | Waltham, MA 02451, US
+1 (844) 222-4340 | https://www.haproxy.com