php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #45915 xmlrpc_encode_request() does not encode numeric keys properly
Submitted: 2008-08-25 21:26 UTC Modified: 2021-04-13 13:54 UTC
Votes:4
Avg. Score:5.0 ± 0.0
Reproduced:4 of 4 (100.0%)
Same Version:4 (100.0%)
Same OS:4 (100.0%)
From: matt at waggoner dot com Assigned: cmb (profile)
Status: Wont fix Package: XMLRPC-EPI related
PHP Version: 5.2.6 OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: matt at waggoner dot com
New email:
PHP Version: OS:

 

 [2008-08-25 21:26 UTC] matt at waggoner dot com
Description:
------------
This issue has been marked as bogus or wontfix before, but I believe this is a bad idea and that this issue should be fixed.

Bug #21949 ends with this comment:

"Not a bug, XML-RPC is ambigous as to the value that the <name> field can contain.  However, all indications point to it being a string value, in XML this represents a value that is non-numeric."

This is false; XML's string type is not restricted to "non-numeric" values.  http://www.w3.org/TR/xmlschema-2/#string says that a string's value space is "the set of finite-length sequences of characters (as defined in [XML 1.0 (Second Edition)]) that match the Char production".  The "Char production" is the following grammar:

char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

The characters 0-9 are within the [#x20-#xD7FF] range, ergo the string XML datatype can validly contain a set of only numeric characters such as "123", which eliminates that objection.

The XML-RPC spec does indeed not specify what value a <name> element may contain, but it seems fairly useless to simply drop numeric keys; a string is a string regardless of whether it contains letters or not.  

Re bug #37746: "It has been this way for a long time" is not a valid reason to avoid fixing this (see any number of longstanding bugs in PHP's history); "this might break existing code" is also not a valid reason (see any number of backward-incompatible changes in PHP's history).

Please fix this bug.

Reproduce code:
---------------
See bugs #21949 and #37746.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-01-23 21:30 UTC] jani@php.net
-Package: Feature/Change Request +Package: XMLRPC-EPI related
 [2021-04-13 13:54 UTC] cmb@php.net
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2021-04-13 13:54 UTC] cmb@php.net
The xmlrpc extension is unbundled and moved to PECL as of PHP
7.4.0.  I'm temporarily maintaining the extension, but I will not
do any feature additions.  Actually, everybody is likely better
off to switch to something else.  Thus, I'm closing this ticket.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 31 23:01:28 2024 UTC