Project

General

Profile

Bug #1159

Cannot set server.port from environment variable

Added by Anonymous over 9 years ago. Updated about 8 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
core
Target version:
Start date:
Due date:
% Done:

0%

Missing in 1.5.x:

Description

Given the environment:


PORT=80
export PORT

the following line in the lighty configuration file:


server.port = env.PORT

fails with the message:


(configfile-glue.c.91) got a string but expected a short: server.port 80

This means that port numbers cannot be set from environment variables, but code was introduced in source:trunk/src/configfile-glue.c@r1349 (3-Oct-2006) to handle this case. It would appear that the `buffer_isdigit()` test in source:trunk/src/configfile-glue.c is broken somehow.

-- andrewb

lighttpd-ticket-1159-patch.txt View - Here is a patch that fixes the problem. -- andrewb (997 Bytes) Anonymous, 2007-09-07 11:25


Related issues

Duplicated by Feature #1403: Can conf file parser auto type cast a string value to integer? Fixed

Associated revisions

Revision 65f4e4a8 (diff)
Added by stbuehler about 8 years ago

Try to convert string options to shorts for numeric options in config file; allows to use env-vars for numeric options. (#1159, thx andrewb)

git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2321 152afb58-edef-0310-8abb-c4023f1b3aa9

History

#1 Updated by darix over 9 years ago

what i dont like about this patch is that it limits the number to 65535. while this might be ok for your use case (server.port) this is not a valid solution for the problem. what if i want to set the max request size from the environment?

the number shouldnt be limited at that position but checked later on in the code if it fits into the limits in this scope.

#2 Updated by Anonymous over 9 years ago

The hard-coded limit of 65535 is completely justified.

The case in question is for "T_CONFIG_SHORT", which generally suggests that a two-byte signed (or unsigned) value is wanted. This is confirmed, and the signed-vs-unsigned question is settled, a few lines further on, where an error message has the 65535 value hard-coded in. Good design dictates that the numeric limits of the lighty config language should be platform independent, not determined by the built-in types of the C compiler used to build it (ie, we don't really want 65536 overflowing on one platform but not on another). All the C standards I've ever read say that `sizeof(short)` is guaranteed to be at least two on all architectures. So I deduced that the assumption of two-byte shorts was deliberate on the part of the lighty developers, and respected that.

Incidentaly, Just a few lines higher, data_integer.value (which is of type int) is assigned to a `*(unsigned short *)` without checking for overflow. That is clearly a bug, but it further strengthens my argument.

-- andrewb

#3 Updated by Anonymous about 9 years ago

Is this going to be fixed any time soon? The patch looks OK to me (if not, it's trivial to #define the maximum unsigned short as (1 << (sizeof(unsigned short) * 8)) - 1), and I just ran into this problem today myself.

#4 Updated by stbuehler over 8 years ago

Workaround: have a shell script that does this for you:


#!/bin/sh

echo "server.port = ${PORT}" 

#5 Updated by stbuehler about 8 years ago

  • Status changed from New to Fixed
  • Resolution set to fixed

Applied in r2321

Also available in: Atom