[workerbee]

I'm trying to solve a language redirect problem: an index.php that uses http://sourceforge.net/projects/l-redirector/. This works beautifully in Mozilla, Firefox, IE, IE5 win, IE6 win, iCab, Opera.
It chokes in Safari and OmniWeb and outputs "too many redirects", because the page is redirected to itself.

Now I've been testing a little and have found something interesting: the HTTP_ACCEPT_LANGUAGE header is handled differently in Safari (I assume Webcore to be at fault, as OmniWeb also shows "too many redirects").

Here's the output from non-Webcore-based browsers:
HTTP ACCEPT LANGUAGE: en,ja;q=0.93,fr;q=0.86
language after str to lower: en
language after sub str: en
language after str to lower: ja
language after sub str: ja
language after str to lower: fr
language after sub str: fr

Here's the output from Safari:
HTTP ACCEPT LANGUAGE: en, ja;q=0.92, ja-jp;q=0.96, fr;q=0.88, de-de;q=0.85, de;q=0.81
language: en, ja, ja-jp, fr, de-de, de
language after str to lower: en
language after sub str: en
language after str to lower: ja
language after sub str: j
language after str to lower: ja-jp
language after sub str: j
language after str to lower: fr
language after sub str: f
language after str to lower: de-de
language after sub str: d

Notice how PHP outputs only one character after applying "substr ($language, 0, 2);"! This is very strange, as the string the substring command is applied to looks very much the same to me in Firefox and Safari, e.g. Opera/Mozillas/IEs: "fr" -> "fr" whereas Safari: "fr" -> "f".

As PHP is executed on the server, I don't think it has anything to do with Cache, Cookies or somesuch.

Anyone more knowledgeable than me know what is happening here? Thanks!

[workerbee]

Found it: the PHP script was not prepared for the space character in WebCore's HTTP_ACCEPT_LANGUAGE between one definition and the next (because every other browser does not send it that way?).

[Wevah]

Yeah; AFAIK spaces are allowed like that. I think it'd be better to not use substr and use a regex instead.