Here we go:

Still building the FPro site, I replaced everything with <div>s (thanks Rich + Ben) but now I have a different kind of problem.....

I am retrieving the values of sections from my database, and linking to them from the main page (see fpro.snibworks.com to see what I'm talking about). The links do not have any PHPSESSID stuff after them, as I am using ini_set() to make sure they are off (using a remote host...).

You may think I'm crazy, but I'm trying to keep this page 100% valid HTML blah blah. When I click the link on my page that proves its validity, it says it's not valid because of the '&' in the link to each section.

I didn't put the '&'s there, and PHP shouldn't have either!

Is there some way to get it to stop, or is the w3 validator screwed up?

Thanks in advanced,

Snib

<><

__________________
-Snib - http://www.snibworks.com
Where will you be in 100 years?

Snib,
It isn't the ampersand character that isn't allowed, it's the fact that it is inserted unencoded. HTML entities must be encoded when they appear literally in a document. The W3C recommends that a semi-colon be used instead of the ampersand to separate URL embedded arguments, php.net recommends the encoded HTML entity.. &amp; which is what I use personally.

I wrote an article on this a long time ago:
http://p2p.wrox.com/topic.asp?TOPIC_ID=4028

This includes all the proper ini settings and relevant links that discuss query strings and the argument separator.

Regards,
Rich

::::::::::::::::::::::::::::::::::::::::::
The Spicy Peanut Project
http://www.spicypeanut.net
::::::::::::::::::::::::::::::::::::::::::

Rich,

I understood that the & was allowed encoded, but now I see I didn't really make that clear.

Anyway.....

You're a lifesaver! It works!

Still, I have one question: why is PHP putting the PHPSESSID in the querystring, when I have the ini setting for it OFF? This isn't a problem, but I'm curious.

Thanks lots Rich!

Snib

<><

I really don't know. I don't use session.use_trans_sid, I prefer to handle all of the inserting of the SID myself. This isn't enabled by default. To figure out if it is the ini setting do a simple test script. Start a session, then make a link and output the page. If the PHPSESSID is magically included then you have a problem with that directive, if not then there's something else in your code doing this. Techniques like this help you to narrow down the source of the problem. If all else fails, consult php.net and look to see if anyone has reported a bug about it. If you think that it could be a bug, make sure you've upgraded to the latest PHP and can still reproduce it before filing a report.

Also don't forget to restart your HTTP server after ini changes, I realize you probably already know this but sometimes we forget the simplest things.

Regards,
Rich

::::::::::::::::::::::::::::::::::::::::::
The Spicy Peanut Project
http://www.spicypeanut.net
::::::::::::::::::::::::::::::::::::::::::

Rich,

I think the problem may be how I'm setting use_trans_sid.

Here are some details:

I am using ini_set(), on a remote host. It seems to work well, getting rid of the PHPSESSID on every link. It does NOT appear to work with the w3 validator.... not a problem anymore, as I've set the arg_separator.input and .output statements with ini_set() also....

So, no big deal why it does this, I'm just curious.

Thanks for your time, Rich.

Snib

<><

This is another unfortunate topic of mine that has risen again, if differently.... (it never was solved, but that didn't really end up mattering)

PHP dynamically puts the SID in forms using a hidden <input/> element. For some reason, it puts it right after the opening form tag, which is not allowed in XHTML 1.1 (the standard I'm following).

Is there a way to get it to stop at least putting the input there??

Thanks,

Snib

<><

Snib, I noticed your comment in reference to using XHTML 1.1 with the Validator. I take it you're aware that the Validator doesn't send HTTP_ACCEPT? If serving XHTML to the Validator, it is best to use a MIME header rewrite test such as that suggested by Richard Allsebrook as a modification to the code in this articlehttp://www.xml.com/pub/a/2003/03/19/dive-into-xml.html on O'Reilly's excellent XML.com - namely:

if ( isset($_SERVER["HTTP_ACCEPT"]) and stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml") ) {
 header("Content-type: application/xhtml+xml");
 }
 else {
 header("Content-type: text/html");
 }
}

This will send the correct MIME header (and incidentally trns Mozilla into an excellent XML debugging tool.

I just thought I'd mention it, in case you hadn't come across this before.

Dan