You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by pizak <pa...@fremantle.org> on 2007/09/05 08:54:19 UTC
Re: [vfs] Re: Specifying options to FTP etc..
Mario
I think the use of the ?? would not be a good URI scheme. However, maybe we
could simply make the VFS parameters unique. For example add vfs. in front
of them.
For example,
http://www/path/cgi-bin/send.pl?FILE=ABC&TYPE=PDF&vfs.proxyHost=proxy.host&vfs.proxyPort=8080
or
ftp:/fremantle.org/file?vfs.passive.ftp=true
Paul
Mario Ivankovits wrote:
>
> Hi!
>> I don't quite agree with this - this may be the common case for HTTP,
>> but the URI spec does not enforce it.
> Ok, but how should we differentiate between these both use-cases?
>
> If we would like to allow this style of URL we need some special
> delimiter to know what to pass to VFS as configuration and what to pass
> further to the server.
> And no - I don't want to care if we are using the HTTP or any other
> scheme.
>
> Hmmm ..... what we can do might be something like this.
>
> We add a new resolveFile method to the FileSystemManager interface:
> FileObject resolveFileWithUrlConfiguration(String uri)
>
> and we separate the VFS configuration using the double question-mark (??)
>
> A url like:
> http://www/path/cgi-bin/send.pl?FILE=ABC&TYPE=PDF??proxyHost=proxy.host&proxyPort=8080
>
> will work then.
>
> resolveFileWithUrlConfiguration will strip the part after (including) ??
> and create the FileSystemOption stuff (if possible) which means the vfs
> configuration string will not be shown in the filename.
>
> Then
> FileObject fo = manager.resolveFileWithUrlConfiguration(....);
> FileObject fo2 =
> manager.resolveFileWithUrlConfiguration(fo.getName().toString);
>
> will not use the same filesystem configuration.
>
> This limitation makes it look a little bit hacky - we might remove this
> limitation later.
>
>
> What do you think?
>
> Ciao,
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Specifying-options-to-FTP-etc..-tf4346550.html#a12492674
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [vfs] Re: Specifying options to FTP etc..
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> I think the use of the ?? would not be a good URI scheme. However, maybe we
> could simply make the VFS parameters unique. For example add vfs. in front
> of them.
>
> For example,
> http://www/path/cgi-bin/send.pl?FILE=ABC&TYPE=PDF&vfs.proxyHost=proxy.host&vfs.proxyPort=8080
>
Yes, for sure, this could make it too - I thought about it too. Even if
I am still not that happy with this query-string parsing/repacking stuff
I'd commit it if someone contributes a patch.
I'll help with dealing with the details, but have not much time to do it
myself yet.
We have to figure out:
* do we rely on url-escape strings with this url parameters too? (I'd
say no - except for the "&" character itself)
* if we do - how to deal with the used charset? (I'd say we expect them
to be in UTF-8 then, regardless of the charset of the other parameters)
* do we strip these parameters off so that we have a query string
without these special fields when sending to the remote host? (I'd say yes)
* enhance the filename so that we have the queryString (as now) and a
remoteQueryString which will be passed to the remote server
* use the new remoteQueryString e.g. with the http filesystem
implementation.
It would be great if someone could open a JIRA ticket at least that we
don't loose the request.
Thanks!
Ciao,
Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org