php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #32619 ext/session: Valid XHTML output
Submitted: 2005-04-07 10:05 UTC Modified: 2015-02-02 09:02 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: nick at terado dot co dot uk Assigned: yohgaki (profile)
Status: Wont fix Package: Session related
PHP Version: * OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: nick at terado dot co dot uk
New email:
PHP Version: OS:

 

 [2005-04-07 10:05 UTC] nick at terado dot co dot uk
Description:
------------
Firstly, this relates to bug #23694
I warrant this being reopened.  Upsetting the validity of a webpages code by using php is a bug.  The method to correct this is neither logical nor sensible.  The requirement should not be on the server administrator to dictate what HTML version should be used to create webpages.

There are two problems here:

1. first ampersands withing url query strings when modified to append the session information.

2. Forms, where a hidden session id input tag will be inserted, however not enclosed by a block level element.


Details and Resolution:

1. The recommended fix so far by the php team is to enable in php.ini the modifier arg_separator.output="&".

Firstly, modification of the php.ini is restrictive.  Secondly, using &amp; in HTML 4 works also, it is standard practice to encode ampersands properly and there is no reason at all not to have this enabled by default.  If there is any other reason, then just as you would output <br> as <br /> then you should output correctly & as &amp; when using XHTML.

However, I repeat using &amp; should be default practice.


2. The recommended fix given so far is to change to

url_rewriter.tags = "a=href,area=href,frame=src,input=src,fieldset="

therefore, omitting form=fakeentry.

Again, the practice of modifying (if possible) the php.ini to set the HTML is bad news and restrictive.  Also by now omitting the form= setting of the modifier we now cant guarantee the session variable will be added, fieldset is not the only choice of block level element within the form element.  Therefore, to complement this often an empty <fieldset> must be inserted, simply to accommodate the session variable addition.

There are simple fixes to this.  If the HTML version is known then <fieldset> can be output around the hidden element.  This is no way upset layout, having no content or white space nothing is output and no shifting on the webpage occurs.  Secondly, <div> can be used.  This therefore allows backwards compatibility and can be output as a rule.  However, I wouldnt know how older browsers would deal with the div - that is whether it would cause spacing issues.  However, the point here is this should be a default or transparent action, the effort to "fix" this is nothing more than asking the coder to hack there way out of what exists as a bug.

This may not be a bug in performance or operation of php itself, but when php itself is outputting HTML and this output is incorrect, this completely warrants a bug report being opened.  The solutions recommended are both not fixes and have other problems associated with them.  The solution to this seems quite simple however.

Nick





Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-04-08 21:48 UTC] jani@php.net
-Package: Feature/Change Request +Package: Session related -Operating System: Debian +Operating System: * -PHP Version: 4.3.10 +PHP Version: *
 [2013-06-27 21:59 UTC] yohgaki@php.net
-Assigned To: +Assigned To: yohgaki
 [2015-02-02 09:02 UTC] yohgaki@php.net
-Status: Assigned +Status: Wont fix
 [2015-02-02 09:02 UTC] yohgaki@php.net
I think we are OK now. If you think there is issue with HTML5, please open new bug for HTML5.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 10:01:26 2024 UTC