ID: 32535
Updated by: [EMAIL PROTECTED]
Reported By: a at b dot c dot de
Status: Bogus
Bug Type: Documentation problem
Operating System: *
PHP Version: 5.0.3
New Comment:
>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.
Previous Comments:
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
[2005-04-01 17:01:59] a at b dot c dot de
Description:
------------
As indicated several times in the manual, the "filenames" that result
from using stream wrappers are to be regarded as URLs, just as http,
ftp and file schemes already are.
However, ALL such wrappers separate the scheme (what the manual refers
to as the "protocol" from the rest of the URL with "://" - an example
being the "var://myvar" in the example of the stream_wrapper_register()
page.
This conflicts with RFC3986, the official specification for URIs (of
which URLs are a subclass). The separator is just ":"; the double slash
should only appear if what follows is a hierarchical structure in the
sense given in section 3 of that document.
This is explicitly stated as improper in RFC2718, section 2.1.2 (which
refers to the previous URI standard, RFC2396).
If these streams are supposed to be URLs, then the above example from
the manual should read "var:myvar".
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=32535&edit=1
