#46745 [NEW]: Multipart/form-data field names truncated at semicolon in certain cases
From: david at sickmiller dot com Operating system: Linux PHP version: 5.2.6 PHP Bug Type: HTTP related Bug description: Multipart/form-data field names truncated at semicolon in certain cases Description: When a form is submitted using multipart-/form-data enctype, PHP will truncate field names if they contain semicolons and certain other characters. It seems to happen when there is an uneven number of quotation marks that precede the semicolon. Reproduce code: --- Expected result: Array ( [before_;_after] => ["_before_;_after] => ['_before_;_after] => ['_'_before_;_after] => ['_"_before_;_after] => ["_'_before_;_after] => ["_"_before_;_after] => ["_'_'_before_;_after] => ["_'_"_before_;_after] => ["_"_'_before_;_after] => ["_"_"_before_;_after] => ['_'_'_before_;_after] => ['_'_"_before_;_after] => ['_"_'_before_;_after] => ['_"_"_before_;_after] => ) Actual result: -- Array ( [before_;_after] => ["_before_] => ['_before_;_after] => ['_'_before_;_after] => ['_"_before_] => ["_'_before_;_after] => ["_"_before_;_after] => ["_'_'_before_] => ["_'_"_before_;_after] => ["_"_'_before_;_after] => ["_"_"_before_] => ['_'_'_before_;_after] => ['_'_"_before_] => ['_"_'_before_;_after] => ['_"_"_before_;_after] => ) -- Edit bug report at http://bugs.php.net/?id=46745&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46745&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46745&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46745&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46745&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46745&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46745&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46745&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46745&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46745&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46745&r=support Expected behavior: http://bugs.php.net/fix.php?id=46745&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46745&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46745&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46745&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46745&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46745&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46745&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46745&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46745&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46745&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46745&r=mysqlcfg
#46745 [Fbk->Opn]: Multipart/form-data field names truncated at semicolon in certain cases
ID: 46745 User updated by: david at sickmiller dot com Reported By: david at sickmiller dot com -Status: Feedback +Status: Open Bug Type: HTTP related Operating System: Linux PHP Version: 5.2.6 New Comment: For a web application, I have written a PHP file that is a general form handler. Various different forms all post to this same file, which does a foreach through $_POST and essentially produces a table with each field question and answer. Some of the forms include file uploads, so I have to use multipart/form-data. The forms are generated dynamically in a moderately expensive operation and result in HTML like this: What's your first name? The questions actually come from different systems, so I don't have the flexibility to change them to remove the non-alphanumeric characters. And it shouldn't be necessary according to the HTML spec. It's generally been working, except for the peculiar combinations of apostophes, quotation marks, and semicolons that I inadvertently ran into recently and have documented in this bug. I checked the header, and it looks like Firefox is correctly submitting the data. I realize this is a niche case. How difficult does the fix look? Previous Comments: [2008-12-08 11:52:46] [EMAIL PROTECTED] Eh..what's the actual bug here? If you pass crap to PHP, you get crap back. ---- [2008-12-03 21:54:47] david at sickmiller dot com Description: When a form is submitted using multipart-/form-data enctype, PHP will truncate field names if they contain semicolons and certain other characters. It seems to happen when there is an uneven number of quotation marks that precede the semicolon. Reproduce code: --- Expected result: Array ( [before_;_after] => ["_before_;_after] => ['_before_;_after] => ['_'_before_;_after] => ['_"_before_;_after] => ["_'_before_;_after] => ["_"_before_;_after] => ["_'_'_before_;_after] => ["_'_"_before_;_after] => ["_"_'_before_;_after] => ["_"_"_before_;_after] => ['_'_'_before_;_after] => ['_'_"_before_;_after] => ['_"_'_before_;_after] => ['_"_"_before_;_after] => ) Actual result: -- Array ( [before_;_after] => ["_before_] => ['_before_;_after] => ['_'_before_;_after] => ['_"_before_] => ["_'_before_;_after] => ["_"_before_;_after] => ["_'_'_before_] => ["_'_"_before_;_after] => ["_"_'_before_;_after] => ["_"_"_before_] => ['_'_'_before_;_after] => ['_'_"_before_] => ['_"_'_before_;_after] => ['_"_"_before_;_after] => ) -- Edit this bug report at http://bugs.php.net/?id=46745&edit=1
[PHP-BUG] Bug #52373 [NEW]: XPath returns inconsistent results
From:
Operating system: Cent OS 5
PHP version: 5.2.13
Package: DOM XML related
Bug Type: Bug
Bug description:XPath returns inconsistent results
Description:
Sometimes the DOMXpath->evaluate() function returns unreliable results.
This seems to happen when the document has at least a depth of 3 and
selectors are used at multiple levels. There may be other conditions that
trigger it; I'm not sure. The test script below is consistently showing
errors for me.
Test script:
---
';
$rawxpath = "/root[1]/fie...@attr1='val1']";
$results = array();
for ($i = 0; $i < 1; $i++) {
$xmlDocument = new DOMDocument();
$xmlDocument->loadXML($rawxml);
$xp = new DOMXPath($xmlDocument);
$xpr = $xp->evaluate($rawxpath, $xmlDocument->documentElement);
if (isset($results[(string) $xpr->length]))
$results[(string) $xpr->length]++;
else
$results[(string) $xpr->length] = 1;
}
foreach ($results as $matches => $count)
printf("In %5d instances, found $matches match(es) for
$rawxpath\n", $count);
Expected result:
In 1 instances, found 1 match(es) for /root[1]/fie...@attr1='val1']
Actual result:
--
The exact numbers seem to vary, but I get roughly this response:
In 9924 instances, found 1 match(es) for /root[1]/fie...@attr1='val1']
In76 instances, found 2 match(es) for /root[1]/fie...@attr1='val1']
--
Edit bug report at http://bugs.php.net/bug.php?id=52373&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52373&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52373&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52373&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52373&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52373&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52373&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52373&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52373&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52373&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52373&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52373&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52373&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52373&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52373&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52373&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52373&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52373&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52373&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52373&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52373&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52373&r=mysqlcfg
Bug #52373 [Opn]: XPath returns inconsistent results
Edit report at http://bugs.php.net/bug.php?id=52373&edit=1
ID: 52373
User updated by: david at sickmiller dot com
Reported by: david at sickmiller dot com
Summary: XPath returns inconsistent results
Status: Open
Type: Bug
Package: DOM XML related
Operating System: Cent OS 5
PHP Version: 5.2.13
New Comment:
I wonder if this may be related to the libxml2 library. I am using
v2.6.26-2.1.2.8 from the CentOS distribution.
Previous Comments:
[2010-07-19 07:59:35] m dot philipp at coreto dot de
Cannot repeat with php 5.3.2.
All test runs resulted in:
"In 1 instances, found 1 match(es) for
/root[1]/fie...@attr1='val1']"
----
[2010-07-19 01:37:51] david at sickmiller dot com
Description:
Sometimes the DOMXpath->evaluate() function returns unreliable results.
This seems to happen when the document has at least a depth of 3 and
selectors are used at multiple levels. There may be other conditions
that trigger it; I'm not sure. The test script below is consistently
showing errors for me.
Test script:
---
';
$rawxpath = "/root[1]/fie...@attr1='val1']";
$results = array();
for ($i = 0; $i < 1; $i++) {
$xmlDocument = new DOMDocument();
$xmlDocument->loadXML($rawxml);
$xp = new DOMXPath($xmlDocument);
$xpr = $xp->evaluate($rawxpath, $xmlDocument->documentElement);
if (isset($results[(string) $xpr->length]))
$results[(string) $xpr->length]++;
else
$results[(string) $xpr->length] = 1;
}
foreach ($results as $matches => $count)
printf("In %5d instances, found $matches match(es) for
$rawxpath\n", $count);
Expected result:
In 1 instances, found 1 match(es) for /root[1]/fie...@attr1='val1']
Actual result:
--
The exact numbers seem to vary, but I get roughly this response:
In 9924 instances, found 1 match(es) for /root[1]/fie...@attr1='val1']
In76 instances, found 2 match(es) for /root[1]/fie...@attr1='val1']
--
Edit this bug report at http://bugs.php.net/bug.php?id=52373&edit=1
#42055 [NEW]: FR: Allow access to non-mangled form field names regardless of enctype.
From: david at sickmiller dot com
Operating system: Irrelevant
PHP version: 5.2.3
PHP Bug Type: Feature/Change Request
Bug description: FR: Allow access to non-mangled form field names regardless
of enctype.
Description:
It should be possible to access to non-mangled form field names regardless
of enctype.
Background: PHP automagically formats $_POST by treating square brackets
([]) in the form names as array indicators. PHP also converts whitespaces
and other special characters to underscores (_). Normally, this is useful.
However, it causes problems when using complicated form field names, such
as those with square brackets, whitespaces, and punctuation. Using special
characters in form field names is valid HTML.
When the form enctype="application/x-www-form-urlencoded", the raw data is
accessible via file_get_contents('php://input'), and it is possible to
construct a non-mangled version of the submitted form fields.
When the form enctype="multipart/form-data", the raw data is NOT
accessible via file_get_contents('php://input') or any other means. Thus,
it is not possible to accept file uploads and still access the original
field names.
This is similar to Bug #34882, except that I am not aware of any
work-around.
I understand that mangling the form field names is often convenient, but
it shouldn't be *impossible* to access the raw field names.
--
Edit bug report at http://bugs.php.net/?id=42055&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42055&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42055&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42055&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42055&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42055&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42055&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42055&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42055&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42055&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42055&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42055&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42055&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42055&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42055&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42055&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42055&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42055&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42055&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42055&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42055&r=mysqlcfg
[PHP-BUG] Req #63485 [NEW]: I don't think the mssql_min_error_severity() function works as it should.
From: david at sickmiller dot com
Operating system: CentOS 5.8
PHP version: 5.3.18
Package: MSSQL related
Bug Type: Feature/Change Request
Bug description:I don't think the mssql_min_error_severity() function works as
it should.
Description:
Hi,
I don't think the mssql_min_error_severity() function works as it should.
At a minimum, the one example in the manual does not make sense
(http://www.php.net/function.mssql-min-error-severity#refsect1-function.mssql-min-error-severity-examples).
The example uses a SQL statement with a syntax error. Regardless of what
you set mssql_min_error_severity to, a syntax error is always going to
trigger both (a) a PHP Warning and (b) a false return value from
mssql_query(). This behavior contradicts the comment above
mssql_min_error_severity(1);. Also, since the code checks the return value
from mssql_query(), it's most likely the user will want to use @ to
suppress the PHP Warning but that is not shown in the example.
Here's an example that at least shows the mssql_min_error_severity()
function doing something:
, >=
or when the subquery is used as an expression. (severity 16)
// PHP Warning: mssql_query(): General SQL Server error: Check messages
from the SQL Server (severity 16)
mssql_min_error_severity(17);
mssql_min_message_severity(17);
$query = mssql_query('SELECT *, (select error from master.dbo.sysmessages)
as bad_subquery from master.dbo.sysmessages');
// Prints nothing
Now, the behavior I disagree with relates to the return value from
mssql_query(). Unlike the PHP Warnings, it seems to be unaffected by the
min severity settings. Please see the test script section.
Test script:
---
https://bugs.php.net/bug.php?id=63485&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63485&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63485&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63485&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63485&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63485&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63485&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63485&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63485&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63485&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63485&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63485&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63485&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63485&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63485&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63485&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63485&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63485&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63485&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63485&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63485&r=mysqlcfg
