HTTP_ACCEPT_LANGUAGE not working

#1
Hello!

I have two servers online with litespeed on them, one free version, and one enterprise. Neither of the two hosts put anything in the $_SERVER['HTTP_ACCEPT_LANGUAGE'] variable with PHP, nothing at all.

Apache sets it correctly to "sv" for my browser.

I need this to work, what should I do?
 

mistwang

LiteSpeed Staff
#2
It is a bug in LSAPI code, if you build your own PHP binary, you can fix it by changing two line of code at beginning of "lsapilib.c".
search for "HTTP_ACCEPT_LANG", change it to "HTTP_ACCEPT_LANGUAGE", then serch "11, 19, 20, 16,", change "16" to "20", then rebuild your lsphp binary.

If you are not comfortable with code changes, please wait for next LSAPI code release.
 
#3
It worked like a charm as usual mistwang. :D

After fixing this and trying to enable GD for PHP as well I ran into the next problem, PHP:s extensions do not configure properly because the configure script gets confused on 64-bit machines where /usr/lib64/lib doesn't exist. Solved by http://www.fabnat.com/linux/Php4_FC4_x86_64.html . Could be nice to know if someone asks. 8) Don't know why the PHP-freaks haven't fixed this, it's an old bug report.
 

xing

LiteSpeed Staff
#4
PHP 5.1.2 and its extensions compile correctly under CentOS 4.2 x86_64.

Perhaps the the problem got fixed in the late php releases but didn't get backported to the earlier ones.

Which php version were you trying to build extensions for on 64bit distro and failed? We definitely would like to keep track of all the weird php problems that litespeed users find and the fixes for them as the forums get as much php questions as litespeed ones. =)
 
#5
We're using 4.4.1, should upgrade to 4.4.2 in the future. Changelog for 4.4.2 has no info about this configuration error so I don't think it has been fixed.

Server OS is SLES9.
 
#6
Not fixed

Just wanted to say that the issue with 64-bit library directories in PHP 4.4.2 has not been fixed. GD still fails when configuring, complaining about "configure: error: libpng.(a|so) not found." etc. It will likely not be fixed since it works in PHP 5.

Here's the guide to fix it since the original site is not available anymore (www.fabnat.com/linux/Php4_FC4_x86_64.html)

1. Add the following lines to configure.in:
Code:
dnl Support systems with system libraries in e.g. /usr/lib64
AC_ARG_WITH(libdir,
[  --with-libdir=NAME     Look for libraries in .../NAME rather than .../lib],
[PHP_LIBDIR=$withval], [PHP_LIBDIR=lib])
Add them right at the beginning, after 'dnl AC_PROG_CXXCPP'.

Keep in mind we want to run ./configure --with-libdir=lib64 and have it cause ./configure to look for libraries in, for example, /usr/lib64 rather than /usr/lib.

2. Edit the config.m4 file for the extension you want to compile (for example, ext/gd/config.m4), and change 'lib', when used to indicate a directory part such as /usr/lib, into '$PHP_LIBDIR'. You have to look at all instances manually; automated replacing for example might replace libjpeg.so with $PHP_LIBDIRjpeg.so which is not what you want.

You can download a fixed config.m4 for GD in PHP 4.4.2 here: http://lowtech.dyndns.org/config.m4.zip

3. Once you're happy and ready to go, type: autoconf to generate your new ./configure

4. Run ./configure but make sure you add --with-libdir=lib64.
 
Top