Bug #54369 [Com]: [PATCH] parse_url() incorrectly determines the start of query and fragment parts
Edit report at https://bugs.php.net/bug.php?id=54369&edit=1
ID: 54369
Comment by: lenzai2004-dev at yahoo dot com
Reported by:tomas dot brastavicius at quantum dot lt
Summary:[PATCH] parse_url() incorrectly determines the start
of query and fragment parts
Status: Open
Type: Bug
Package:URL related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The point is not about wether the patch is relevant or not.
But for this bug and other cases, parse_url is returning corrupt result.
It could be fixed in 2 ways:
- patch it
- or detect invalid url and return error.
I've been trying to use this function and after significant volume of URLs I
always find cases where it returns incorrect data.
I had to rewrite everything in PHP and it's quite slow.
Previous Comments:
[2011-05-17 20:12:50] tomas dot brastavicius at quantum dot lt
Changed report name as described in the bug report spec.
[2011-04-03 19:36:33] tokul at users dot sourceforge dot net
You can't argue that function is broken and needs fixes, if you feed broken
data and expect good output. Use valid urls in your tests, if you want to show
that function is broken.
[2011-04-03 18:36:42] tomas dot brastavicius at quantum dot lt
One more comment about this issue:
http://marc.info/?l=php-internals&m=130183094107548&w=2
[2011-04-03 18:09:08] tomas dot brastavicius at quantum dot lt
Another comment about this issue:
http://marc.info/?l=php-internals&m=130183032307080&w=2
@Peter
Yes, according to RFC 1738 the test URLs are not valid. But:
1. It is not defined that parse_url() parses URLs according to RFC 1738.
2. parse_url() "is not meant to validate given URL". See
http://php.net/manual/en/function.parse-url.php
3. Why it is better to return invalid hostname ("#" and "/" are invalid
characters, current parse_url() version) instead of invalid query or fragment
(patched parse_url() version) ?
@tokul at users dot sourceforge dot net
Checked
My arguments for the patch acceptance are as follows:
1. parse_url() documentation's "Return Values" section clearly states that
query and fragment component starts after "?" and "#" character respectively.
2. I don't know any specification that allows "#" and "?" in the hostnames
(someone knows ?) but I know at least RFC3986 (unfortunately I am working with)
that allows "/" character in both query and fragment parts. See
http://tools.ietf.org/html/rfc3986.html#section-3.4 and
http://tools.ietf.org/html/rfc3986.html#section-3.5
3. It has been already stated (although different content) that parse_url()
parses URLs according to RFC3986. See http://bugs.php.net/bug.php?id=50484. May
be Adam Harvey knows more ?
[2011-04-03 14:10:58] tokul at users dot sourceforge dot net
Check url encoding documentation first.
http://en.wikipedia.org/wiki/Percent-encoding
Then fix your $url value. You use reserved character for other purpose.
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
https://bugs.php.net/bug.php?id=54369
--
Edit this bug report at https://bugs.php.net/bug.php?id=54369&edit=1
Req #55149 [Com]: Limit the result of print_r() to facilitate debugging
Edit report at https://bugs.php.net/bug.php?id=55149&edit=1 ID: 55149 Comment by: lenzai2004-dev at yahoo dot com Reported by:victor at cmp dot es Summary:Limit the result of print_r() to facilitate debugging Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Why not writing your own custom php function for that purpose ? Also for debugging var_dump is sometimes more useful than print_r. Previous Comments: [2011-07-06 11:51:03] victor at cmp dot es Description: You could add an additional third parameter to print_r() function in order to limit the nesting level of output. Instead of showing all levels of nested arrays/objects, it could be limited to N nesting levels. If I only want to know my simple class member variables (with 3 or 4 of them) of an object but the object has members with "references/alias" to other big objects/classes, the screen is filled with a lot of (in this case) useless information. If I could limit in this case the output to 1 or 2 nesting levels it would be much easier for me to debug. If this third parameter were ommitted or zero, the whole tree would be shown (as done now). -- Edit this bug report at https://bugs.php.net/bug.php?id=55149&edit=1
Req #55152 [Com]: Mysql relative seek
Edit report at https://bugs.php.net/bug.php?id=55152&edit=1
ID: 55152
Comment by: lenzai2004-dev at yahoo dot com
Reported by:lenzai2004-dev at yahoo dot fr
Summary:Mysql relative seek
Status: Open
Type: Feature/Change Request
Package:MySQL related
Operating System: all
PHP Version:trunk-SVN-2011-07-06 (SVN)
Block user comment: N
Private report: N
New Comment:
Yes Indeed.
Well if mysql API is considered deprecated in PHP 5 the I should drop my
request.
If not, I believe it is a nice a simple addition.
Previous Comments:
[2011-07-08 18:12:17] ka...@php.net
Hi, don't the mysqli module support this already, or with the MySQLi result
iterator from 5.4?
[2011-07-06 15:01:55] lenzai2004-dev at yahoo dot fr
Description:
There is currently a function to do absolute seek in Mysql API.
When you need to to relative seek , you have to implement integer counter to
keep track of the current cursor position. Then call seek
here is a sample code:
//iterating over rows
for/while{
mysql_fetch_();
$current_row++;
[...]
// call relative seek
$current_row+= $seek_offset;
mysql_data_seek($id, $current_row);
This quite simple but when the code gets complicated, it s easy to miss on
$current_row update. The only only solution is to encapsulate php mysql
function in additional abstraction layer to handle counter updates safely.
I suppose the internal counter is already available in mysql module.
What I am suggesting, is to expose this internal counter by adding a new
function to mysql API.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55152&edit=1
