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