Thread: [Vimprobable-users] Improve handling of file parameters
Vimprobable is a lean web browser optimised for full keyboard control
Brought to you by:
hanness
Menu
▾
▴
vimprobable-users
|
From: Morgan H. <mt...@gm...> - 2013-02-21 08:53:21
|
Greetings, I look at a lot of test generated html output and the like, so I frequently hit problems with file paths. Because of the URI, things would only open properly if I provided a full path, or something that would be expanded by the shell into a full path such as ~/html/index.html. Modified to use realpath() to fix this issue. It would also fail to detect file parameters without a "/" in the path (e.g. "index.html"), so changed to use stat() instead of looking for "/" or "./" when determining if an argument is a file. This takes care of any issues I have run into with using vimprobable to view local files. Regards, Morgan |
|
From: Hannes S. <ha...@yl...> - 2013-02-24 15:16:44
|
Hi! Morgan Howe <mt...@gm...> wrote: > I look at a lot of test generated html output and the like, so I > frequently hit problems with file paths. Because of the URI, things > would only open properly if I provided a full path, or something that > would be expanded by the shell into a full path such as > ~/html/index.html. Modified to use realpath() to fix this issue. It > would also fail to detect file parameters without a "/" in the path > (e.g. "index.html"), so changed to use stat() instead of looking for > "/" or "./" when determining if an argument is a file. This takes care > of any issues I have run into with using vimprobable to view local > files. Hmm... well, this seems to work as advertised, but I'd like to hear some opinions. As far as I can see, your problem boils down to a) relative paths not being recognised (e.g. ../dir/file.htm). b) you assuming that . should be in the search path (e.g. index.htm). The second one, I don't really consider a problem, to be honest. You could easily just write vimprobable ./index.htm on your command line. Your solution would make it impossible to call URLs from a directory which has a file or subdirectory with the same name as the URL. E.g. if your file system looks like this: . .. www.example.org and you call vimprobable www.example.org it will call the local directory instead of the URL. No workaround possible. Before someone argues that this is a rather academic example, I would like to point out that such a directory structure is not so uncommon on machines used for web development. The first one, though, I cannot really argue against. In the end, I would say it is a matter of policy what the browser should 'assume', i.e. what it should give preference to. Right now, by using a very restrictive definition of calling local files, external URLs are always given preference. I'm not totally against changing this a bit in the way you describe. Does anyone else have an opinion? Hannes |
|
From: Daniel C. <dan...@gm...> - 2013-02-24 15:42:42
Attachments:
signature.asc
realpath.patch
|
Hi!
Hannes Schüller <ha...@yl...> wrote:
> The second one, I don't really consider a problem, to be honest. You
> could easily just write
>
> vimprobable ./index.htm
This does not work for me. Because this leads to the URL 'file://./index.html'
which could not be found.
> Does anyone else have an opinion?
In my opinion the stat call isn't required. I think the '/' or './' should
be enough. But out of the none working vimprobable2 ./index.html we should use
the realpath on the file before creating the URL.
By the way we can reduce the code by replacing:
new = g_malloc(sizeof("file://") + len);
strcpy(new, "file://");
memcpy(&new[sizeof("file://") - 1], s, len + 1);
by:
uri = g_strdup_printf("file://%s", s);
I've made a little patch that applies to the master that demonstrates what I
want to have. But this didn't check if the realpath returned a value or not,
but as an example this should be enough.
Daniel
|
|
From: Hannes S. <ha...@yl...> - 2013-02-24 15:51:04
|
Daniel Carl <dan...@gm...> wrote: > Hannes Schüller <ha...@yl...> wrote: > > The second one, I don't really consider a problem, to be honest. You > > could easily just write > > > > vimprobable ./index.htm > > This does not work for me. Because this leads to the URL > 'file://./index.html' which could not be found. Eh? Works for me. Hannes |
|
From: Daniel C. <dan...@gm...> - 2013-02-24 16:03:01
Attachments:
signature.asc
|
Hannes Schüller <ha...@yl...> wrote: > > This does not work for me. Because this leads to the URL > > 'file://./index.html' which could not be found. > > Eh? Works for me. I've tested it with the version of master branch, but it did not work for me. It's independent if vimprobable is started from HOME_DIR or from somewhere else. Also the proxy settings did not change the behaviour for me. I guess that this could be a webkit behaviour. Daniel |
|
From: Hannes S. <ha...@yl...> - 2013-02-24 16:05:38
|
Daniel Carl <dan...@gm...> wrote: > Hannes Schüller <ha...@yl...> wrote: > > > This does not work for me. Because this leads to the URL > > > 'file://./index.html' which could not be found. > > > > Eh? Works for me. > > I've tested it with the version of master branch, but it did not work > for me. It's independent if vimprobable is started from HOME_DIR or > from somewhere else. Also the proxy settings did not change the > behaviour for me. OK, that's definitely buggy behaviour then which needs to be reliably fixed one way or the other. Hannes |
|
From: Morgan H. <mt...@gm...> - 2013-02-25 05:51:42
|
Apologies for the odd means of responding - I'm not on the list, please CC me in the future. :) > Hi! > Morgan Howe <mthowe@...> wrote: > > I look at a lot of test generated html output and the like, so I > > frequently hit problems with file paths. Because of the URI, things > > would only open properly if I provided a full path, or something that > > would be expanded by the shell into a full path such as > > ~/html/index.html. Modified to use realpath() to fix this issue. It > > would also fail to detect file parameters without a "/" in the path > > (e.g. "index.html"), so changed to use stat() instead of looking for > > "/" or "./" when determining if an argument is a file. This takes care > > of any issues I have run into with using vimprobable to view local > > files. > Hmm... well, this seems to work as advertised, but I'd like to hear > some opinions. As far as I can see, your problem boils down to > a) relative paths not being recognised (e.g. ../dir/file.htm). > b) you assuming that . should be in the search path (e.g. index.htm). > The second one, I don't really consider a problem, to be honest. You > could easily just write > vimprobable ./index.htm > Agreed, the second case wasn't really a big issue, but the way I changed the code fixed it for both cases. > on your command line. Your solution would make it impossible to call > URLs from a directory which has a file or subdirectory with the same > name as the URL. E.g. if your file system looks like this: > . > .. > http://www.example.org > and you call > vimprobable http://www.example.org > it will call the local directory instead of the URL. No workaround > possible. Before someone argues that this is a rather academic example, > I would like to point out that such a directory structure is not so > uncommon on machines used for web development. > Yeah, I considered this, though I was thinking that would be a rare situation. Not being a web developer personally, that may have been a bit presumptuous. Perhaps it may be better to check if the parameter is already a URI first, before checking if it is a file? At least that way, there would always be a workaround in case of name conflicts. Regards, Morgan |
|
From: Hannes S. <ha...@yl...> - 2013-02-25 08:30:47
|
Hi! Morgan Howe <mt...@gm...> wrote: > Apologies for the odd means of responding - I'm not on the list, > please CC me in the future. :) Has it occured to you that it might be much more convenient for everyone involved to simply... subscribe? It's not like this list will send tons of traffic to your inbox. As you can see, there have been a couple of other responses to this thread and it's virtually impossible that everybody will remember to keep the CC in all of them. > > on your command line. Your solution would make it impossible to call > > URLs from a directory which has a file or subdirectory with the same > > name as the URL. E.g. if your file system looks like this: > > . > > .. > > http://www.example.org > > and you call > > vimprobable http://www.example.org > > it will call the local directory instead of the URL. No workaround > > possible. Before someone argues that this is a rather academic > > example, I would like to point out that such a directory structure > > is not so uncommon on machines used for web development. > > > > Yeah, I considered this, though I was thinking that would be a rare > situation. Not being a web developer personally, that may have been a > bit presumptuous. Perhaps it may be better to check if the parameter > is already a URI first, before checking if it is a file? At least > that way, there would always be a workaround in case of name > conflicts. And how would you detect if something is a URL? The only reliable way I can think of would be sending a skeleton HTTP request out to see if there is a response. Which would involve potential failure sources like DNS which are completely outside the scope of the browser itself. What would be the behaviour if the user intends to call a URL, but name resolution temporarily fails? Will the URL string then be passed to local file handling? So that means that if it cannot be found locally either, the error thrown at the user will be 'file not found' instead of 'host name not found' which would be quite confusing. Hannes |
|
From: Morgan H. <mt...@gm...> - 2013-02-25 09:09:32
|
On Mon, Feb 25, 2013 at 4:30 PM, Hannes Schüller <ha...@yl...> wrote: > Has it occured to you that it might be much more convenient for > everyone involved to simply... subscribe? It's not like this list will > send tons of traffic to your inbox. As you can see, there have been a > couple of other responses to this thread and it's virtually impossible > that everybody will remember to keep the CC in all of them. > Alright, you've sold me. Subscribed. > > > > on your command line. Your solution would make it impossible to call > > > URLs from a directory which has a file or subdirectory with the same > > > name as the URL. E.g. if your file system looks like this: > > > . > > > .. > > > http://www.example.org > > > and you call > > > vimprobable http://www.example.org > > > it will call the local directory instead of the URL. No workaround > > > possible. Before someone argues that this is a rather academic > > > example, I would like to point out that such a directory structure > > > is not so uncommon on machines used for web development. > > > > > > > Yeah, I considered this, though I was thinking that would be a rare > > situation. Not being a web developer personally, that may have been a > > bit presumptuous. Perhaps it may be better to check if the parameter > > is already a URI first, before checking if it is a file? At least > > that way, there would always be a workaround in case of name > > conflicts. > > And how would you detect if something is a URL? The only reliable way I > can think of would be sending a skeleton HTTP request out to see if > there is a response. Which would involve potential failure sources like > DNS which are completely outside the scope of the browser itself. > > No, I would rather not do that and I agree that overly complicate things and potentially slow down the initial opening of the browser which is obviously not something we'd want. I was thinking something more along the lines of just verifying that the parameter is a properly formed URI, and if it is, we trust the user and explicitly do what they ask. I'm not entirely versed in the details of RFC 3986 [1], but to refer back to your example, I was thinking something along these lines: vp2 www.example.com Check for file, if it exists, build the URI as in my patch, otherwise fall back to URL. vp2 http://www.example.com Properly formed URI, use it. Now the only other case would be a file named "http://www.example.com" which on any of the systems I have available is not a legal filename anyway. That would be the one case where the user would need to then properly specify the file:// prefix, though like I said, I'm not sure this scenario is even possible. Either way, at least with this behavior, there is always a reasonable workaround. Better suggestions are welcome. :) Regards, Morgan [1] http://www.ietf.org/rfc/rfc3986.txt |
|
From: Morgan H. <mt...@gm...> - 2013-02-25 10:42:27
|
On Mon, Feb 25, 2013 at 5:08 PM, Morgan Howe <mt...@gm...> wrote: > vp2 www.example.com > Check for file, if it exists, build the URI as in my patch, otherwise fall > back to URL. > > vp2 http://www.example.com > Properly formed URI, use it. > > Now the only other case would be a file named "http://www.example.com" > which on any of the systems I have available is not a legal filename > anyway. That would be the one case where the user would need to then > properly specify the file:// prefix, though like I said, I'm not sure this > scenario is even possible. Either way, at least with this behavior, there > is always a reasonable workaround. Better suggestions are welcome. :) > > Which, actually, should be the current behavior now that I review the code (my patch did not have enough context lines to show the full logic). The current steps are: 1) Check if it's a search engine 2) If not a search engine, look for "://", if found, trust the user. 3) Else, check if it's a file and if so, build the file:// URI 4) Else, check (again) if it's a search engine 5) Else, prefix with "http://" and attempt to open. Due to the order of the evaluation, the issue you mentioned originally should not be a problem. Regards, Morgan |
|
From: Hannes S. <ha...@yl...> - 2013-02-25 18:49:20
|
Hi Morgan! Morgan Howe <mt...@gm...> wrote: > 1) Check if it's a search engine > 2) If not a search engine, look for "://", if found, trust the user. > 3) Else, check if it's a file and if so, build the file:// URI > 4) Else, check (again) if it's a search engine > 5) Else, prefix with "http://" and attempt to open. > > Due to the order of the evaluation, the issue you mentioned originally > should not be a problem. Actually, this is exactly the main issue I tried explaining initially: the policy change to give precedence to local files over URLs. > Now the only other case would be a file named "http://www.example.com" > which on any of the systems I have available is not a legal filename > anyway. That would be the one case where the user would need to then > properly specify the file:// prefix, though like I said, I'm not sure > this scenario is even possible. I think we can safely disregard this freak case :) Hannes |
|
From: Morgan H. <mt...@gm...> - 2013-02-28 18:29:53
|
Hey Hannes, Just wanted to follow up on this... On Tue, Feb 26, 2013 at 2:49 AM, Hannes Schüller <ha...@yl...> wrote: > Morgan Howe <mt...@gm...> wrote: > > 1) Check if it's a search engine > > 2) If not a search engine, look for "://", if found, trust the user. > > 3) Else, check if it's a file and if so, build the file:// URI > > 4) Else, check (again) if it's a search engine > > 5) Else, prefix with "http://" and attempt to open. > > > > Due to the order of the evaluation, the issue you mentioned originally > > should not be a problem. > > Actually, this is exactly the main issue I tried explaining initially: > the policy change to give precedence to local files over URLs. So is this acceptable to be merged then? The only conflict case remaining is a local file, in the current directory, with the exact same name as the domain you'd potentially like to visit. In such case, 'vp2 http://www.example.com' rather than 'vp2 www.example.com' is an easy and obvious workaround. This seems like reasonable behavior, and I don't see any other way of handling it short of what you said with actually probing for a connection or checking DNS. Regards, Morgan |
|
From: Hannes S. <ha...@yl...> - 2013-03-01 21:02:50
|
Hi! Morgan Howe <mt...@gm...> wrote: > On Tue, Feb 26, 2013 at 2:49 AM, Hannes Schüller <ha...@yl...> > wrote: > > Morgan Howe <mt...@gm...> wrote: > > > 1) Check if it's a search engine > > > 2) If not a search engine, look for "://", if found, trust the > > > user. 3) Else, check if it's a file and if so, build the file:// > > > URI 4) Else, check (again) if it's a search engine > > > 5) Else, prefix with "http://" and attempt to open. > > > > > > Due to the order of the evaluation, the issue you mentioned > > > originally should not be a problem. > > > > Actually, this is exactly the main issue I tried explaining > > initially: the policy change to give precedence to local files over > > URLs. > > So is this acceptable to be merged then? The only conflict case > remaining is a local file, in the current directory, with the exact > same name as the domain you'd potentially like to visit. In such > case, 'vp2 http://www.example.com' rather than 'vp2 www.example.com' > is an easy and obvious workaround. For me, the question which is still open is whether this patch also fixes the issue of vimprobable2 ./index.htm which some people seem to experience in the current stable version. I cannot test it since I cannot reproduce the original issue. If it is fixed, is it because of the use of realpath or due to the stat call? Hannes |
|
From: Morgan H. <mt...@gm...> - 2013-03-04 06:28:24
|
Hey Hannes, On Sat, Mar 2, 2013 at 2:16 AM, Hannes Schüller <ha...@yl...> wrote: > > For me, the question which is still open is whether this patch also > fixes the issue of > > vimprobable2 ./index.htm > > which some people seem to experience in the current stable version. I > cannot test it since I cannot reproduce the original issue. If it is > fixed, is it because of the use of realpath or due to the stat call? Yes, it fixes that issue. I believe this is due to URIs involving relative paths not always being supported, depending on the interpreter (which may explain why some people observe this behavior and others do not). You can take a look at this[1] Stack Overflow response for further explanation. The realpath() call fixes this, since it will generate an absolute pathname, expanding all symlinks or relative portions of the path. The stat call is used to determine if something is a file in the case that no URI scheme is provided. Note that as I mentioned previously, if no scheme is provided, it checks for the existence of a file with the given name prior to treating it as a URL, but this can always be overridden by specifying a proper scheme. Regards, Morgan [1] http://stackoverflow.com/questions/7857416/file-uri-scheme-and-relative-files |
|
From: Hannes S. <ha...@yl...> - 2013-03-04 18:36:32
|
Hi! Morgan Howe <mt...@gm...> wrote: > On Sat, Mar 2, 2013 at 2:16 AM, Hannes Schüller <ha...@yl...> > wrote: > > > > For me, the question which is still open is whether this patch also > > fixes the issue of > > > > vimprobable2 ./index.htm > > > > which some people seem to experience in the current stable version. > > I cannot test it since I cannot reproduce the original issue. If it > > is fixed, is it because of the use of realpath or due to the stat > > call? > > Yes, it fixes that issue. Then it's ok for me to merge it. Personally, I would give preference to always treat arguments as an URL when in doubt, but I also do see the case of testing for local files first. Hannes |
|
From: Morgan H. <mt...@gm...> - 2013-04-03 09:54:31
|
Hey Hannes, On Tue, Mar 5, 2013 at 2:36 AM, Hannes Schüller <ha...@yl...> wrote: > Then it's ok for me to merge it. Personally, I would give preference to > always treat arguments as an URL when in doubt, but I also do see the > case of testing for local files first. I still don't see this having been merged. Is there something still holding it up or did it just get lost in the mix? :) Thanks, Morgan |
|
From: Hannes S. <ha...@yl...> - 2013-04-03 13:31:03
|
Morgan Howe <mt...@gm...> wrote: > > Then it's ok for me to merge it. Personally, I would give > > preference to always treat arguments as an URL when in doubt, but I > > also do see the case of testing for local files first. > > I still don't see this having been merged. Is there something still > holding it up or did it just get lost in the mix? :) Yes, there is something, but it's not related to you. I simply cannot access the code repository right now due to unforeseen personal circumstances. Don't worry, though, the patch has been marked in my queue so that I won't forget. Hannes |
|
From: Hannes S. <ha...@yl...> - 2013-05-17 12:11:08
|
This is now merged as well. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X