is that still a problem if you set arg_separator.input = ";&"
this should BC with <form action="get"> why not use arg_separator.output = ";" the doc told me there's some browser can't recognize ";", but can anyone tell me when browser need to do something with it? parsing the "Location"? i just found it problem on meta refresh On Wed, 23 Mar 2005 14:12:52 -0800, Sharif Ibrahim <[EMAIL PROTECTED]> wrote: > In the manual, http_build_query's documented behavior is to generate a > "URL-encoded query string." The documentation does not specify what > is used as a separator between the array elements, but testing and/or > source perusal easily show that it is arg_separator.output. This > makes sense when generating links to your own server, although it > would be nice to be able to specify the separator to use via an > optional third argument (one could emulate this with ini_set but a > third argument would be preferable). > > The only other use that I am aware of for arg_separator.output at this > time is for the session URL rewriting engine. However, these two uses > have quite different semantics: whereas the separators the rewriter > uses must be HTML-escaped in the output (in order to emit valid code), > those used by http_build_query must not be. > > That is, the URI http://example.com/foo?bar=1&baz=2 is transmitted > without any further escaping in an HTTP header. When represented in > an HTML document, however, it must (not considering the CDATA contents > of <script> and <style>) be escaped and may look something like <a > href="http://example.com/foo?bar=1&baz=2";>. > > The default setting for arg_separator.output is "&" but anyone who > wants to use URL rewriting and emit valid HTML code is currently > forced to use "&". While a bit inelegant (it would be preferable > for PHP to generate valid code by default), this workaround didn't > cause any real problems until PHP 5 and the introduction of > http_build_query. With "&" as arg_separator.output, > http_build_query will create query strings that are not suitable for > inclusion in an HTTP header. > > The root of the problem is that session URL rewriting interprets > arg_separator.output as already HTML-escaped while http_build_query > interprets it as not. Notice that arg_separator.input is clearly not > HTML-escaped so the most consistent view would be to have > arg_separator.output also be unescaped. That way, if a certain use of > the setting requires escaping, it can be applied. This model is > preferable to that of magic_quotes_gpc whereby it's escaped for one > particular use and in order to use it for any other, one must unescape > it and then re-escape it as needed. > > So there are two basic issues: > > 1. The combination of the default setting of arg_separator.output and > the way the session URL rewriter works causes PHP to emit invalid > code. > > 2. The way the session URL rewriter interprets arg_separator.output is > different from the way in which http_build_query interprets it. > > To address these, I see three possible solutions: > > 1. Define the semantics of arg_separator.output to be an unescaped > string. Have the session URL rewriter HTML-escape the value of > arg_separator.output and use that result when it adds the SID to > links. > > This approach makes the default setting of PHP generate valid code and > standardizes the interpretation of arg_separator.output. However, > there is a minor BC issue for those who have installed an older > version of PHP, modified arg_separator.output to be "&" and then > upgrade with the same configuration file. This really only applies to > those who have proactively modified their configuration in order to > achieve HTML validity and represent the group most easily able to > adapt to the change, however. > > 2. Define another configuration directive (yuck) for http_build_query to use. > > This would have a BC issue for someone using ini_set to control the > separator used by arg_separator.output in order to generate (for > example) off-site links to a server that uses an input separator that > differs from the output separator currently in use. Also, the default > configuration of session URL rewriting would still emit invalid code. > > 3. Define the semantics of arg_separator.output to be an escaped > string and revise http_build_query to unescape before applying. The > default would need to be changed to "&". > > Possible BC issue on upgrade for anyone who had a default > arg_separator.output ("&") in their php.ini as they'd no longer have a > valid setting. Also, this approach would generate cognitive > dissonance between arg_separator.input and arg_separator.output. > > A variation on this solution doesn't revise http_build_query but > instead documents it as generating HTML-escaped strings. However, > this would be a BC break for those using it to create Location headers > or the like, as well as those who conscientiously apply htmlentities > to its output before sticking it in an HTML document. > > My preferred solution is 1 (revise URL rewriting engine) but it's > quite possible that I've neglected to consider some other way to fix > it or some argument for or against those I've presented. > > Bug report reference: http://bugs.php.net/bug.php?id=30049 > Additional information: http://www.sitepoint.com/blog-post-view.php?id=245295 > > - Sharif > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
