ID: 32535
User updated by: a at b dot c dot de
Reported By: a at b dot c dot de
Status: Bogus
Bug Type: Documentation problem
Operating System: *
PHP Version: 5.0.3
New Comment:
Withdrawing the original report: it _is_ a documentation problem as
reclassified. The examples shouldn't be using // indiscriminately (as
in the "var://myvar" example), but only when appropriate. The
distinction should be made, otherwise broken usages of parse_url()
would become common (as in the given example, where the indicated
variable name is in the "host" part of the URL, rather than the
"path").
Nowhere is it actually stated how PHP decides which wrapper to use -
the fact that it reads up to ':' (and not '://') is only _implicit_. No
mention is made of the fact that the scheme name must not contain ':'
(which one might be led to expect is possible if the scheme only ends
with a "://"; especially since it would be succesfully registered. But
that's a story for another bug (#32563).
Rewriting the documentation to use URL terminology ("scheme" rather
than "protocol", for example) may also be a good idea.
Previous Comments:
------------------------------------------------------------------------
[2005-04-03 16:03:48] a at b dot c dot de
Well, to quote the cited section of RFC2718:
2.1.2 Improper use of "//" following "<scheme>:"
Contrary to some examples set in past years, the use of double slashes
as the first component of the <scheme-specific-part> of a URL is not
simply an artistic indicator that what follows is a URL: Double slashes
are used ONLY when the syntax of the URL's <scheme-specific-part>
contains a hierarchical structure as described in RFC 2396. In URLs
from such schemes, the use of double slashes indicates that what
follows is the top hierarchical element for a naming authority. (See
section 3 of RFC 2396 for more details.) URL schemes which do not
contain a conformant hierarchical structure in their
<scheme-specific-part> should not use double slashes following the
"<scheme>:" string.
This has not changed with RFC3986. Note, too, the eight examples given
in section 1.1.2 of 3986; three do not have the requisite hierarchical
structure, and hence do not have //.
------------------------------------------------------------------------
[2005-04-02 22:41:10] [EMAIL PROTECTED]
>From RFC 3986:
'...
The term "Uniform Resource Locator" (URL) refers to the subset of URIs
that, in addition to identifying a resource, provide a means of
locating the resource by describing its primary access mechanism (e.g.,
its network "location").
...'
I do not see the conflict, the use of URL syntax is akin to the use of
the valid location address of a file in a local filesystem, i.e. (as
mentioned in the document quoted above):
'...
URIs that identify in relation to the end-user's local context should
only be used when the context itself is a defining aspect of the
resource, such as when an on-line help manual refers to a file on the
end-user's file system
(e.g., "file:///etc/hosts").
...'
A URN is also an URI (from which URLs are also a subset), and in that
case, the syntax mentioned by the user is valid, although URNs are
names, and usually used for resources without regard to their
accessibility. For example, URNs are used for LSIDs to refer to unique
DNA sequences.
Furthermore, in 1.2.3, it is said:
'...
The generic syntax uses the slash ("/"), question mark ("?"), and
number sign ("#") characters to delimit components that are significant
to the generic parser's hierarchical interpretation of an identifier. In
addition to aiding the readability of such identifiers through the
consistent use of familiar syntax, this uniform representation of
hierarchy across naming schemes allows scheme-independent references to
be made relative to that hierarchy.
...'
In any case, to make it more consistent, we should use then:
stream://authority/path/to/remote/fileorresource
where authority, can be the name of a server.
accordingly, if addressing a local resource:
stream:///path/to/local/resource
All of these will require modification of the code for handling stream
names.
------------------------------------------------------------------------
[2005-04-02 13:23:58] [EMAIL PROTECTED]
Nuno,
your statement does not anwser anything, sorry.
So you are saying that the current docs are in line with the mentioned
RFC`s?
Yes or no?
Friedhelm
------------------------------------------------------------------------
[2005-04-02 13:16:18] [EMAIL PROTECTED]
I can't see any problem in the documentation. Everything about wrappers
is well explained.
------------------------------------------------------------------------
[2005-04-02 08:08:14] [EMAIL PROTECTED]
reclassified
------------------------------------------------------------------------
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
http://bugs.php.net/32535
--
Edit this bug report at http://bugs.php.net/?id=32535&edit=1
