Streams and wrappers

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Here is another post concerning stream wrappers. I'm trying to implement
a urn: scheme stream wrapper but this does not seem possible with PHP.

Why? Because PHP analyzes URI with the following syntax:

scheme "://" target

Where _scheme_ is what they incorrectly call a "protocol" in the
documentation and _target_ the actual target of the URI.

When dealing with things like http://www..., ftp://ftp..., everything is ok.

But how are we supposed to support things like,
urn:xmpp:..., h323:host... and other schemes that are NOT followed by
"://" but only ":"?

If you try to register the mailto "protocol" (which is, again, not the
correct term), you will do:

stream_wrapper_register('mailto',  'MyMailToClass');

But this wrapper class will not be used at all by PHP if you try this:

fopen('', 'w');

Instead you will have to write:

fopen('mailto://', 'w');

Which is wrong (see ).

PHP consider that '' falls into the default
(file://) scheme as it does not find the "://" string after the
so-called "protocol".

We may intercept URI's not containing those "://" characters with a
custom file:// stream wrapper. When the wrapper is called by PHP and the
"path" starts with a recognized scheme like "mailto:", it may delegate
the work to the actual mailto: wrapper. But this is just a workaround as
it is supposed to handle resources on the local filesystem only.

I understand that this behavior is probably caused by
fopen('some:file.dat'); being mostly used to open a file that has a
column character in its name and located in the current working
directory (: character is not allowed in file names on windows, I
guess). It simply demonstrates once again a problem that may arise with
the default implicit file:// scheme in URI's.

Anyway, I'm still posting to read your thoughts on this. Maybe someone
will see another solution than the workaround I explained above.

Thank you!


Re: Streams and wrappers

Quoted text here. Click to load it

you can also use a wrapper around stream_wrapper_register()!! hee hee

in the end, the usefulness of this kind of statement is surely pretty
small - well my imagination is limited I suppose, can it really be
called a "stream protocol"?
fopen('', 'w');
stream_wrapper_register_even_the_fake_ones( $p, $m='r' )
 //if first 7 chars are 'mailto',
 //{ replace
 //mailto: with mailto:// and do it
 //stream_wrapper_register(str_replace('mailto:','mailto://',$p, $r);

etc blah.

stream_wrapper_register_even_the_fake_ones( '',
'w' );

if you come up with a class that codes for the entire mailto thing
with imap support and so on please send it along, it would be useful I

Re: Streams and wrappers

shimmyshack wrote:
Quoted text here. Click to load it

Thank you for your reply but I'm not quite sure I understand your idea
and my guess is that you mixed up stream_wrapper_register() and fopen()

When I read

stream_wrapper_register_even_the_fake_ones( '',
'w' );

I think you meant

fopen('', 'w');


I don't see how a wrapper around stream_wrapper_register() will help
because what is important is the scheme being actually registered and
the str_replace() trick still register "mailto://" and not "mailto:",
from PHP internals point of view.



Re: Streams and wrappers

Quoted text here. Click to load it

I was just questioning what it would /mean/ to register mailto: rather
than mailto:// - its just symantics, the work around is needed because
mailto isn't really like http://
fopen with allow_url_fopen set to true acting on http produces a
mailto: has always been just a device for passing local variables to a
local program.
mailto doesnt have the sam in built status and usefulness as a stream
protocol, you would have to work hard to create this functionality,
whereas at the moment, we would simple gather variables and pass them
to a mail() call, where mail() would wrap an smtp/local mta.
I suppose I just don't see the requirement to add functionality to
mailto: server side, where it is essentially a client side "hint" for
convenience written as a fake protocol.
The next question is what does the javascript: "protocol"  mean and
how to implement that. You could do it, usefulness?

Re: Streams and wrappers

shimmyshack wrote:
Quoted text here. Click to load it

The thing is I used mailto: as an example but I'm actually interested in
URNs as I explained in the first post. The point of using URNs is
obvious - at least to me - within XML documents, etc.

I think URNs fall into what the stream wrappers were designed to within
PHP, unfortunatly their syntax is not that compatible with PHP streams.

Re: Streams and wrappers

Quoted text here. Click to load it

I can see your point there, it would be lovely to parse a markup
stream, extract all links and treat them as URNs, and php does have
some way to go in many areas, I'm just waiting for php6 so that
unicode arrives along with other useful bits and pieces!!
 In the real world of href="javascript:call();" and so on, is that
people will use just about anything that works for them, and then ftp
up to their space, regardless of the rights and wrongs.

Re: Streams and wrappers

On 25.06.2007 17:11 Julien Biezemans wrote:
Quoted text here. Click to load it

Well, I don't think 'fopen' arguments are urls or urns although  
sometimes it may seem so.  Just take it as php own format that only  
accidentally matches some kinds of url.

On widnows, ':' is used to denote a drive, e.g.  
fopen("C:\WINDOWS\blah") is perfectly valid.

gosha bine

extended php parser ~
blok ~

Re: Streams and wrappers

gosha bine wrote:
Quoted text here. Click to load it

That makes sense, thank you for this thought. Anyway it's a pity because
  libraries like DOM make us of the PHP streams system to interpret what
are strict URIs (think about Xinclude "include" elements that have
"href" attributes accepting anyURI values).

In other words, when PHP DOM extension (or libxml if you prefer)
executes an include element, its href attribute value is strictly an URI
that may be under any scheme!

In conclusion, concerning my own application it will be an assumption
that fopen() treats its path argument as URIs and I'll keep using the
workaround I described earlier.



Site Timeline