ID: 16810
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Session related
Operating System: Linux RedHat
PHP Version: 4.0CVS-2002-04-2
New Comment:
XHTML 1.1
<form method="post" action="/de/search.html">
<input type="hidden" name="sid"
value="7957363932547bc30cec8978468736bf" />
<input type="submit" name="submit" value="Test" />
</form>
=> Error: element "input" not allowed here; possible cause is an inline
element containing a block- level element
You have to wrap the form in a table to be valid. An other aproach is
to change url_rewriter.tags form=fakeentry to form=action. But php
doesn't overwrite the default php.ini.
btw. I have to change the arg_separator.output to "&" instead of
"&" to be valid.
Previous Comments:
------------------------------------------------------------------------
[2002-04-25 18:13:35] [EMAIL PROTECTED]
now you're just making up reasons to waste bandwidth and create a silly
configuration knob. the patch has been reverted. the existing output is
entirely sufficient for all of the purposes you've listed, and
perfectly standards compliant.
------------------------------------------------------------------------
[2002-04-25 16:09:34] [EMAIL PROTECTED]
We're generating an element to be used in one known way (for reference
by the PHP session library) and that can also be used in other
legitimate ways: addressed via a fragment or XPointer, via DHTML, etc.
PHP doesn't generate markup that conforms only to its own needs, it
generates it to meet authors' needs, user agents expectations, and spec
requirements; the current patch does not conflict with existing specs,
allows for more reliable UA recognition under certain circumstances,
and makes the element more accessible to the author for legal
addressing or manipulation.
The value of session.name is configurable. So if an author finds that
the hidden field's id conflicts with another element's id, they already
have the option to modify either or both elements in order to avoid
conflicts.
Preventing side-effects of rewriting on multi-form pages is an
interesting issue. Perhaps this could be remedied with a configuration
option (session.rewriting.hidden) allowing the author to designate
whether the hidden input should be written with an id attribute, name
attribute, or both. That would permit for flexibility under differing
contexts, including text/html, text/xhtml, and text/xml. The default
value would remain as before: "name" (only); but give authors the
option to change the behavior when needed.
------------------------------------------------------------------------
[2002-04-25 14:59:20] [EMAIL PROTECTED]
we are *not* generating fragments that are expected to identified by
their url. we are generating a (hidden) form input element with a name.
we expect the browser to submit the value of that element with the
associated name. setting an id is pointless. (and potentially *wrong*
if there is more than one form on the page, which means we'll have
created two fragments with the same id.)
------------------------------------------------------------------------
[2002-04-25 14:26:36] [EMAIL PROTECTED]
It should not be reversed.
The XHTML DTDs defines "id" as one of the core attributes (see
parameter entity "coreattrs") for most elements, including the input
element.
Section C.8 states "In XML, URI-references [RFC2396] that end with
fragment identifiers of the form "#foo" do not refer to elements with
an attribute name="foo"; rather, they refer to elements with an
attribute defined to be of type ID, e.g., the id attribute in HTML 4.
Many existing HTML clients don't support the use of ID-type attributes
in this way, so identical values may be supplied for both of these
attributes to ensure maximum forward and backward compatibility (e.g.,
<a id="foo" name="foo">...</a>)."
One of the features of XML (and therefore XHTML), is that anchor
elements are no longer the only elements addressable by a fragment
identifier. Note that section 3.2 states "When a user agent processes
an XHTML document as generic XML, it shall only recognize attributes of
type ID (e.g. the id attribute on most XHTML elements) as fragment
identifiers." So while "script.php#PHPSESSID" may sound like an
unlikely path, it is a legal one.
------------------------------------------------------------------------
[2002-04-25 13:05:18] [EMAIL PROTECTED]
note that this is not correct with regards to input elements. the name
attribute is only deprecated for the a, applet, form, frame, iframe,
img, and map elements. (see C.8 of the xhtml spec, and the dtds.)
in fact, reverting this part of the patch would be a good idea. we're
defining input element names here, not fragment identifiers.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/16810
--
Edit this bug report at http://bugs.php.net/?id=16810&edit=1
