[PHP-DEV] Bug #1249 Updated: url_parse() is a bit too strict

2001-05-14 Thread sniper

ID: 1249
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Critical
Status: Closed
Bug Type: URL related
Operating system: 
PHP Version: 4.0
Assigned To: 
Comments:

Fixed in CVS. 

Now it behaves more consistently. 
ie. if ? is present, the query key is set.
And if # is present, the fragment key is set.

--Jani


Previous Comments:
---

[2001-05-07 12:54:49] [EMAIL PROTECTED]
marking as fix before 4.0.6

---

[2001-05-07 07:57:14] [EMAIL PROTECTED]
If this isn't a bug, it is at least an inconsistency.

parse_url('?') doesn't set a query key
parse_url('?#fragment') does

Neither URL has what I would consider a query string, but the query key is set in the 
second case.  That behavior should be consistent one way or the other, imho.

---

[2001-05-02 21:12:26] [EMAIL PROTECTED]
To PHP-developers: Does anyone have any thoughts about this?
(IMO, this isn't any bug)

--Jani




---

[2001-02-22 12:23:56] [EMAIL PROTECTED]
If you get URL as user input it can be bogus. parse_url could
be very useful to find if the URL is bogus and what parts
of it are bogus. Another point is, that even bogus looking
URL's could be valid (partial only). Also i believe
that parse_url('path?') wouldnt have quere set (although i
cant verify it at the moment).
And the last point is correctness. Even if it is not
significant, it would be nice if it behaved the expected way.

---

[2001-02-22 10:56:18] [EMAIL PROTECTED]
I, personally, don't see why it has to parse such bogus URLs
at all... Any arguments?

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=1249edit=2


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #1249 Updated: url_parse() is a bit too strict

2001-05-07 Thread derick

ID: 1249
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Critical
Bug Type: URL related
Operating system: 
PHP Version: 4.0
Assigned To: 
Comments:

marking as fix before 4.0.6

Previous Comments:
---

[2001-05-07 07:57:14] [EMAIL PROTECTED]
If this isn't a bug, it is at least an inconsistency.

parse_url('?') doesn't set a query key
parse_url('?#fragment') does

Neither URL has what I would consider a query string, but the query key is set in the 
second case.  That behavior should be consistent one way or the other, imho.

---

[2001-05-02 21:12:26] [EMAIL PROTECTED]
To PHP-developers: Does anyone have any thoughts about this?
(IMO, this isn't any bug)

--Jani




---

[2001-02-22 12:23:56] [EMAIL PROTECTED]
If you get URL as user input it can be bogus. parse_url could
be very useful to find if the URL is bogus and what parts
of it are bogus. Another point is, that even bogus looking
URL's could be valid (partial only). Also i believe
that parse_url('path?') wouldnt have quere set (although i
cant verify it at the moment).
And the last point is correctness. Even if it is not
significant, it would be nice if it behaved the expected way.

---

[2001-02-22 10:56:18] [EMAIL PROTECTED]
I, personally, don't see why it has to parse such bogus URLs
at all... Any arguments?

---

[2001-02-10 14:56:42] [EMAIL PROTECTED]
refiled against 4.0.

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=1249edit=2


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #1249 Updated: url_parse() is a bit too strict

2001-05-06 Thread cardinal

ID: 1249
Updated by: cardinal
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: URL related
Operating system: 
PHP Version: 4.0
Assigned To: 
Comments:

If this isn't a bug, it is at least an inconsistency.

parse_url('?') doesn't set a query key
parse_url('?#fragment') does

Neither URL has what I would consider a query string, but the query key is set in the 
second case.  That behavior should be consistent one way or the other, imho.

Previous Comments:
---

[2001-05-02 21:12:26] [EMAIL PROTECTED]
To PHP-developers: Does anyone have any thoughts about this?
(IMO, this isn't any bug)

--Jani




---

[2001-02-22 12:23:56] [EMAIL PROTECTED]
If you get URL as user input it can be bogus. parse_url could
be very useful to find if the URL is bogus and what parts
of it are bogus. Another point is, that even bogus looking
URL's could be valid (partial only). Also i believe
that parse_url('path?') wouldnt have quere set (although i
cant verify it at the moment).
And the last point is correctness. Even if it is not
significant, it would be nice if it behaved the expected way.

---

[2001-02-22 10:56:18] [EMAIL PROTECTED]
I, personally, don't see why it has to parse such bogus URLs
at all... Any arguments?

---

[2001-02-10 14:56:42] [EMAIL PROTECTED]
refiled against 4.0.

---

[2001-02-10 13:12:04] [EMAIL PROTECTED]
this is a real bug, although relatively minor.

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=1249edit=2


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #1249 Updated: url_parse() is a bit too strict

2001-05-02 Thread sniper

ID: 1249
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: URL related
PHP Version: 4.0
Assigned To: 
Comments:

To PHP-developers: Does anyone have any thoughts about this?
(IMO, this isn't any bug)

--Jani




Previous Comments:
---

[2001-02-22 12:23:56] [EMAIL PROTECTED]
If you get URL as user input it can be bogus. parse_url could
be very useful to find if the URL is bogus and what parts
of it are bogus. Another point is, that even bogus looking
URL's could be valid (partial only). Also i believe
that parse_url('path?') wouldnt have quere set (although i
cant verify it at the moment).
And the last point is correctness. Even if it is not
significant, it would be nice if it behaved the expected way.

---

[2001-02-22 10:56:18] [EMAIL PROTECTED]
I, personally, don't see why it has to parse such bogus URLs
at all... Any arguments?

---

[2001-02-10 14:56:42] [EMAIL PROTECTED]
refiled against 4.0.

---

[2001-02-10 13:12:04] [EMAIL PROTECTED]
this is a real bug, although relatively minor.

---

[1999-03-20 18:26:16] [EMAIL PROTECTED]
it is a minor glitch, though parse_url('?') returns path
set, but query unset. After looking at url_parse() it seeems,
that is would be more rational to test for subs[7].rm_so = lentgh
Equality case makes more sense for all the comparisons (maybe
except for scheme where it wouldnt matter). Result of this
would be, that any part that has its prefix present but value
absent and is at the end of string would be set (though empty)
Examples: '?' - query should be set, 'path#' fragment should
be set, 'http://' hostname should be set to empty
Another glitch is regexp for user:pass@host:port part. Now
the regexp is ^(([^@:]+)(:([^@:]+))?@)?([^:@]+)(:([^:@]+))?
while i suggest ^(([^@:]*)(:([^@:]*))?@)?([^:@]*)(:([^:@]*))?
This is also in accordance with regex for the whole url.

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=1249edit=2


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]