Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #16978 > unrolled thread

Rant: http_build_query() and arg_separator.output

Back to article view | Back to comp.lang.php

Contents

  Rant: http_build_query() and arg_separator.output Arno Welzel <usenet@arnowelzel.de> - 2016-08-26 09:05 +0200
    Re: Rant: http_build_query() and arg_separator.output "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-08-26 11:48 +0200
      Re: Rant: http_build_query() and arg_separator.output Arno Welzel <usenet@arnowelzel.de> - 2016-08-29 07:43 +0200
        Re: Rant: http_build_query() and arg_separator.output Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-29 13:16 +0100
          Re: Rant: http_build_query() and arg_separator.output Arno Welzel <usenet@arnowelzel.de> - 2016-08-30 08:39 +0200
            Re: Rant: http_build_query() and arg_separator.output Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-30 15:10 +0100
              Re: Rant: http_build_query() and arg_separator.output Arno Welzel <usenet@arnowelzel.de> - 2016-09-01 08:43 +0200
                Re: Rant: http_build_query() and arg_separator.output Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-07 22:18 +0200
        Re: Rant: http_build_query() and arg_separator.output "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-08-29 14:53 +0200
          Re: Rant: http_build_query() and arg_separator.output Arno Welzel <usenet@arnowelzel.de> - 2016-09-01 08:53 +0200

#16978 — Rant: http_build_query() and arg_separator.output

I just spend nearly an hour to debug a very strange problem with a
WordPress plugin in a shared hosting environment which caused endless
redirect loops and didn't work at all.

In the end I found out that the cause of all the trouble was, that the
plugin uses http_build_query().

According to <http://php.net/manual/en/function.http-build-query.php>
this function got an *optional* parameter in PHP 5.1.2 to specify the
separator for arguments in the generated URL - so one can not only use
"&" but also "&amp;" if needed. I can't think of any other use for this
parameter - but hey, maybe one needs ":" or some other crazy variant.

Anway - the original behaviour of http_build_query() was to use single
ampersands.

But NOW the default behaviour is just unpredictable, since the function
uses either a single ampersand OR if set the runtime configuration
arg_separator.output.

Furthermore the shared hoster where I had to debug the problem had
arg_separator.output set to &amp; so all URLs generated using
http_build_query() had "&amp;" where the should be "&" only!

The workaround was to add the following line to .htaccess:

php_value arg_separator.output "&"

That's why I really hate PHP sometimes. It's their typical way to break
things. At some point someone decided that it may be neccessary to have
URLs with "&amp;" instead of "&" so they can be used in HTML output.
That's a legitimate request. But why didn't they just add an optional
bool parameter to http_build_query() for this or better another function
http_build_query_escaped()? Why a runtime option in the PHP
configuration and why can the seperator be set to *anything* and not
just "&" or "&amp";? Or did I miss some important thing?

-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [next] | [standalone]

#16979

On 26.08.2016 at 09:05, Arno Welzel wrote:

> Anway - the original behaviour of http_build_query() was to use single
> ampersands.
> 
> But NOW the default behaviour is just unpredictable, since the function
> uses either a single ampersand OR if set the runtime configuration
> arg_separator.output.

That's not quite correct.  Actually, arg_separator.output is available
as of PHP 4.0.5, but http_build_query() has been introduced in PHP 5.0.0
only, and the function used the ini setting from the beginning.  So
there has not been a BC break here.

Furthermore, http_build_query()'s behavior is not unpredictable, but it
rather depends on a PHP_INI_ALL ini setting (unless the $arg_separator
argument is set).  A portable software is supposed to either set
$arg_separator or arg_separator.output when using http_build_query() (or
at the very least to document the issue).

So I suggest that you file a ticket for the software that doesn't do so.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#16986

Christoph M. Becker schrieb am 2016-08-26 um 11:48:

> On 26.08.2016 at 09:05, Arno Welzel wrote:
> 
>> Anway - the original behaviour of http_build_query() was to use single
>> ampersands.
>>
>> But NOW the default behaviour is just unpredictable, since the function
>> uses either a single ampersand OR if set the runtime configuration
>> arg_separator.output.
> 
> That's not quite correct.  Actually, arg_separator.output is available
> as of PHP 4.0.5, but http_build_query() has been introduced in PHP 5.0.0
> only, and the function used the ini setting from the beginning.  So
> there has not been a BC break here.

Well then - than the behaviour was always unpredictable.

> Furthermore, http_build_query()'s behavior is not unpredictable, but it
> rather depends on a PHP_INI_ALL ini setting (unless the $arg_separator
> argument is set).  A portable software is supposed to either set

"Depends on a PHP_INI_ALL ini setting" is what I call "unpredictable". A
function should have a defined default behaviour which is not depending
on some global setting. You never know what will come out unless you
also check the runtime configuration or use a parameter which was not
there before PHP 5.1.2.

> $arg_separator or arg_separator.output when using http_build_query() (or
> at the very least to document the issue).
> 
> So I suggest that you file a ticket for the software that doesn't do so.

I already did.

But why is the argument separator for URLs a configurable runtime
option? It makes no sense at all.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#16988

Arno Welzel <usenet@arnowelzel.de> writes:
<snip>
> But why is the argument separator for URLs a configurable runtime
> option? It makes no sense at all.

It's configurable at run time because the separator can't be known (for
sure) ahead of that.  That fact my be what makes no sense to you, but
given that the PHP authors don't know what separator might be used,
there has to be some way to specify it.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#16990

Ben Bacarisse schrieb am 2016-08-29 um 14:16:

> Arno Welzel <usenet@arnowelzel.de> writes:
> <snip>
>> But why is the argument separator for URLs a configurable runtime
>> option? It makes no sense at all.
> 
> It's configurable at run time because the separator can't be known (for
> sure) ahead of that.  That fact my be what makes no sense to you, but
> given that the PHP authors don't know what separator might be used,
> there has to be some way to specify it.

I talk about the separator for arguments in URLs. This is usually "&"
and not unknown. Nobody expects something else as separator, except when
using it in strings within an HTML document - but for this
http_build_query() could have used a boolean paramter to control if
separators should be output as "&" or "&amp;". And in fact the default
for argument separators in URLs is "&".

Also see <http://php.net/manual/en/ini.core.php#ini.sect.data-handling>.


-- 
Arno Welzel
https://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#16997

Arno Welzel <usenet@arnowelzel.de> writes:

> Ben Bacarisse schrieb am 2016-08-29 um 14:16:
>
>> Arno Welzel <usenet@arnowelzel.de> writes:
>> <snip>
>>> But why is the argument separator for URLs a configurable runtime
>>> option? It makes no sense at all.
>> 
>> It's configurable at run time because the separator can't be known (for
>> sure) ahead of that.  That fact my be what makes no sense to you, but
>> given that the PHP authors don't know what separator might be used,
>> there has to be some way to specify it.
>
> I talk about the separator for arguments in URLs. This is usually "&"
> and not unknown.

We may be taking at cross purposes because we seem to be agreeing but
using different emphasis.  Yes, it is usually "&" but unless is always
is, you need to be able to specify it.  I've seen services (rather old
ones now) that used ";".  In fact ";" was specified in some very early
RFCs for URLs for what were then called URL parameters (IIRC).  This was
not the query portion of the URL, but the habit of using ";" did cross
over into the query portion, at least for a while.

> Nobody expects something else as separator, except when
> using it in strings within an HTML document - but for this
> http_build_query() could have used a boolean paramter to control if
> separators should be output as "&" or "&amp;". And in fact the default
> for argument separators in URLs is "&".

Are you saying that "&" is now so universal that PHP need not concern
itself with any URLs that use some other separator?  If so, I don't feel
qualified to comment.  The last URL that I saw using something else is
long dead, so maybe PHP should just assume "&" will always be wanted.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#17003

Ben Bacarisse schrieb am 2016-08-30 um 16:10:

> Arno Welzel <usenet@arnowelzel.de> writes:
> 
>> Ben Bacarisse schrieb am 2016-08-29 um 14:16:
>>
>>> Arno Welzel <usenet@arnowelzel.de> writes:
>>> <snip>
>>>> But why is the argument separator for URLs a configurable runtime
>>>> option? It makes no sense at all.
>>>
>>> It's configurable at run time because the separator can't be known (for
>>> sure) ahead of that.  That fact my be what makes no sense to you, but
>>> given that the PHP authors don't know what separator might be used,
>>> there has to be some way to specify it.
>>
>> I talk about the separator for arguments in URLs. This is usually "&"
>> and not unknown.
> 
> We may be taking at cross purposes because we seem to be agreeing but
> using different emphasis.  Yes, it is usually "&" but unless is always
> is, you need to be able to specify it.  I've seen services (rather old
> ones now) that used ";".  In fact ";" was specified in some very early
> RFCs for URLs for what were then called URL parameters (IIRC).  This was

Well ";" was mentioned for "FTP url-path" to add *one* optional
parameter to the file path in RFC1738:

<https://tools.ietf.org/html/rfc1738#section-3.2.2>

But I don't think that this is the reason for PHP to offer a runtime
configuration for the separator in URLs.

[...]
> Are you saying that "&" is now so universal that PHP need not concern
> itself with any URLs that use some other separator?  If so, I don't feel

It's not just universal *now* it already was common when the very first
web browsers existed and how the put arguments together when you created
something like a <form> element using method "get".



-- 
Arno Welzel
https://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#17025

Arno Welzel wrote:

> Ben Bacarisse schrieb am 2016-08-30 um 16:10:
>> We may be taking at cross purposes because we seem to be agreeing but
>> using different emphasis.  Yes, it is usually "&" but unless is always
>> is, you need to be able to specify it.  I've seen services (rather old
>> ones now) that used ";".  In fact ";" was specified in some very early
>> RFCs for URLs for what were then called URL parameters (IIRC).  This was
> 
> Well ";" was mentioned for "FTP url-path" to add *one* optional
> parameter to the file path in RFC1738:
> 
> <https://tools.ietf.org/html/rfc1738#section-3.2.2>
> 
> But I don't think that this is the reason for PHP to offer a runtime
> configuration for the separator in URLs.

You are correct.  The reason is that people/Web applications have used “;” 
and perhaps other parameter separators in *HTTP* URLs (IIRC I have also seen 
“|”).  Ben already told you, and I can confirm it.
 
-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#16989

On 29.08.2016 at 07:43, Arno Welzel wrote:

> "Depends on a PHP_INI_ALL ini setting" is what I call "unpredictable". A
> function should have a defined default behaviour which is not depending
> on some global setting. You never know what will come out unless you
> also check the runtime configuration or use a parameter which was not
> there before PHP 5.1.2.

Well, even a simple string conversion of a float depends on several
runtime configuration settings:

  $number = 1/3;
  echo $number; // => 0.33333333333333
  setlocale(LC_NUMERIC, 'de_DE.UTF-8');
  echo $number; // => 0,33333333333333
  ini_set('precision', 2);
  echo $number; // => 0,33

Whether you like it or not, that's PHP, and the behavior is unlikely to
change in the (near) future.

> But why is the argument separator for URLs a configurable runtime
> option? It makes no sense at all.

That *might* be caused because somebody liked to have it to be `&`
instead of `&`.  IMO, a bad idea, but that's how it is.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#17004

Christoph M. Becker schrieb am 2016-08-29 um 14:53:

> On 29.08.2016 at 07:43, Arno Welzel wrote:
> 
>> "Depends on a PHP_INI_ALL ini setting" is what I call "unpredictable". A
>> function should have a defined default behaviour which is not depending
>> on some global setting. You never know what will come out unless you
>> also check the runtime configuration or use a parameter which was not
>> there before PHP 5.1.2.
> 
> Well, even a simple string conversion of a float depends on several
> runtime configuration settings:
> 
>   $number = 1/3;
>   echo $number; // => 0.33333333333333
>   setlocale(LC_NUMERIC, 'de_DE.UTF-8');
>   echo $number; // => 0,33333333333333
>   ini_set('precision', 2);
>   echo $number; // => 0,33

Yes - because the representation of numbers when printing them for
humans depends on the locale. But I am talking about changing the way
how things are handled *technically*.

Even changing the locale does not change how PHP handles

$number = 1.333;

This will always be the same and

<?php
setlocale(LC_NUMERIC, 'de_DE.UTF-8');
$number = 1,3333;
?>

will never work, since PHP expects "." as decimal point and not a comma.

But changing the runtime configuration for URL separators means, that
PHP may create URLs which *itself* does not parse properly - because
there is also one runtime option for the parser and you can even tell
the parser to use a different separator for *reading* than PHP uses for
*creating* URLs.

> Whether you like it or not, that's PHP, and the behavior is unlikely to
> change in the (near) future.

I know. That's why I used "Rant" in my subject ;-).

>> But why is the argument separator for URLs a configurable runtime
>> option? It makes no sense at all.
> 
> That *might* be caused because somebody liked to have it to be `&amp;`
> instead of `&`.  IMO, a bad idea, but that's how it is.

Yes - as usual in PHP. Getting "&amp;" for situations where you need it
would have been possible by just adding a parameter to
http_build_query() and not using a global runtime configuration.


-- 
Arno Welzel
https://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web