According to Ted Stresen-Reuter: > 1) You can set the argument separator for php in the php.ini file as in the > following: > arg_separator.output = ";" > arg_separator.input = ";" > > (be sure to use the quotes as the semi-colon is seen as an "end of line" > marker in the php.ini file)
If you do this, will PHP still recognize the "&" as a valid argument separator as well? Ideally, you'd want a way of configuring it to allow either. If your PHP page is called from the action attribute of an HTML <form> tag, using the GET method, it will get its parameters separated by ampersands, as this is the CGI standard. However, if the same PHP page is called from an HTML <a href=...> tag, it should be able to recognize the semicolon as separator, as the HTML 4.0 standard recommends. As far as I can tell, the susansexton.com web site's results page does allow both, but it keeps crashing my Netscape 4.x browser so I'm not completely certain of this. On the other hand, if PHP can only allow one separator and not the other, then I can see the value in leaving it as the ampersand separator, but then patching htsearch to use "&", or better still, "&" (for HTML 4.0 compliance) as the parameter separator for page button URLs. If this is the case, it would be a good argument for adding a new config attribute to htsearch for this purpose, as "fix your wrapper" wouldn't be a solution in this case. ... > Ted Stresen-Reuter > (trying really hard to provide quality feedback ;-) Thanks, Ted. I'm really out of my element when it comes to PHP questions, so I appreciate your fielding this one. > On 4/22/02 3:05 PM, "Christopher Murtagh" <[EMAIL PROTECTED]> > wrote: > > > On Fri, 15 Mar 2002, Gilles Detillieux wrote: > >> According to Christopher Murtagh: > >>> So, what I did instead was modify the Display.cc file in htsearch so that > >>> it generated properly formatted query strings. All this meant was changing > >>> ';' for '&' in the Display::createURL method (16 of them to change). > >> ... > >>> Maybe it would be nice to have a config option in 3.2 where it could > >>> compile a php friendly version? Just a thought. > >> > >> Are you using the latest version of PHP? I thought I had read previously > >> on this list that it now can parse CGI parameters separated by semicolons. > >> Maybe I'm remembering wrong? I know the latest CGI.pm for Perl does. > >> HTML 4.0 is hardly a new standard, and we've actually been slow to bring > >> ht://Dig into compliance with it, so I don't know why other web application > >> developers are so slow to get with the program. See FAQ 5.21 if you > >> haven't already. > > > > > > Hi Gilles, > > > > Thanks for the note... sorry it took so long for me to reply. Your reply > > got filtered badly and I just saw it today! > > > > Sorry I didn't see the FAQ, I didn't realize that this was a PHP problem > > not being compliant. FWIW, I tried the following with PHP version 4.1.2 > > (the lastest): > > > > <HTML> > > <? > > print"foo: $foo<BR>"; > > print"foobar: $foobar<BR>"; > > ?> > > </HTML> > > > > with this URL: > > > > http://server/file.php?foo=hey&foobar=there > > > > Output is as expected: > > > > foo: hey > > foobar: there > > > > However, this URL: > > > > http://server/file.php?foo=hey;foobar=there > > > > produces: > > > > foo: hey;foobar=there > > foobar: > > > > Perhaps there is a compile option in PHP? Anyone else solve this issue? A > > compile time option with PHP maybe? -- Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada) _______________________________________________ htdig-general mailing list <[EMAIL PROTECTED]> To unsubscribe, send a message to <[EMAIL PROTECTED]> with a subject of unsubscribe FAQ: http://htdig.sourceforge.net/FAQ.html
