Bug #54369 [Opn]: [PATCH] parse_url() incorrectly determines the start of query and fragment parts

From: Date: Fri, 05 Jun 2015 14:45:44 +0000
Subject: Bug #54369 [Opn]: [PATCH] parse_url() incorrectly determines the start of query and fragment parts
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-193146@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=54369&edit=1

 ID:                 54369
 Updated by:         cmb@php.net
 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:

Oh, I forgot: <http://3v4l.org/PKG0q>.


Previous Comments:
------------------------------------------------------------------------
[2015-06-05 14:43:56] cmb@php.net

I'm not sure whether the issue qualifies as *bug* in PHP. The
documentation contains the following note[1]:

> This function is intended specifically for the purpose of
> parsing URLs and not URIs.

Therefore RFC 1738 is relevant, not RFC 3986. However, RFC 1738 is
obsolete...

Anyhow, I had a look at the tests patch, and quite obviously the
main patch enforces some behavioral changes. That might be
considered a BC break for PHP 5, so perhaps it's best to treat
this ticket as feature request, and to improve parse_url() for PHP
7 only.

As the behavioral changes don't appear to cause profound BC
breaks, it seems to me that these changes don't require an RFC. A
PR[2] might be helpful to get more attention to this issue,
though. Are you willing to make a PR, Tomas?

[1] <http://php.net/manual/en/function.parse-url.php#refsect1-function.parse-url-notes>
[2] <https://github.com/php/php-src/pulls>

------------------------------------------------------------------------
[2013-05-31 13:09:55] woody dot gilk at gmail dot com

According to RFC, the URL http://www.example.com?foo=bar is a completely valid 
URL. To quote:

> For example, the URI <mailto:fred@example.com> has
> a path of "fred@example.com",
  whereas the URI <foo://info.example.com?fred> has an empty path.

There is nothing in the RFC spec that says a path must be included in the URL. 
Please fix this bug.

------------------------------------------------------------------------
[2011-06-29 21:37:39] lenzai2004-dev at yahoo dot com

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.

------------------------------------------------------------------------
[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.

------------------------------------------------------------------------


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


Thread (15 messages)

« previous php.bugs (#193146) next »