W3C home > Mailing lists > Public > uri@w3.org > September 2004

Off/On topic - Brick VS Head. URI(URL/File) eg of previous posts...

From: Kitchen Pages <jrobinson@kitchenpages.com>
Date: Thu, 02 Sep 2004 10:00:58 GMT
Message-ID: <20040902.10005898@home.kitchenpages.net>
To: uri@w3.org
In relation to the URL of File and its difference to that of Win9x 32 – 
aka URI of file.
I have noticed several things for a while which seem to work opposite of 
clearly defined standards and I was wondering why this practice is 
continued without any note – Ie: a reference to what does where, how it 
does it?!?, or even the result of a URI on various systems, etc.. (as 
part of relative-URI as I understood it; which may of been 'incorrect')
To explain just one very small example, and as perhaps my other posts can 
not be understood :( from my lack of understanding these ideals fully.
Step A, created a folder on C:\ named FOLDER.IE5
Step B, created a file named 'FILE' in the folder above without an 
extension
Test 1, file://C/FOLDER.IE5/DATA results in a File Not Found which I t
hink is wrong.
Test 2, C:\FOLDER.IE5\DATA results in FILE being found, *.
*You may like to try DATA.TXT, in the case of 1 above; I got the same 
result of a File Not Found.
(the test above works for IE5.5sp2 and Mozilla 1.7.1)
I would presume that this related to the 8.3 system but considering the 
trail '/' after FOLDER.IE and before DATA the standard (or draft?) now 
states that DATA should be returned; in this case as a file.  The 
File:// 
URL seems to have no reference to 8.3 (which does work and returns DATA 
as a file) but instead points to current URI drafts. (just incase you 
were wondering why I am posting in URI).  
Even when DATA is an actual folder and not a file, no appending is 
performed – as the addition of a '/' either manually or automatically 
still results in a file not found.  And considering the lack of reply to 
previous posts – this is like taking the brick from the wall and using 
that to bang my head against; And without moving my head.  As I read the 
current URI draft a '.' in the path seems somewhat acceptable (like a 
trail '.' for FQDN which is partly supported by some TLD's for 
redirection, etc) – and is used by others in many cases for HTTP 
(http://host.router.tld/folder.ie5/data) with no drama (as in my first 
eg) correctly as a file is returned by the server to a browser/client 
like Inifiles (as to standard).  However, If I then change the DATA to a 
folder; The HTTP then fails or seems to hang (I have to add a '/' as the 
file standard describes for a file index tree to be rendered).
The reason for this question is for a pet back-end client of my own.  I 
have already resolved a fix using http or an ip as with a Inifiles.hpp 
solution but I still have wonder if my bodge fix is correct or even 
needed.  There is no reference which I can see which related to this – if 
possible can some kind person post info in relation to such; I am unsure 
if this is on-topic in which case feel free to post directly.
Many thanks in advance for reading this, other posts, and in regards to 
your time and efforts in any reply.
Jason Robinson
jrobinson@kitchenpages.com
Received on Wednesday, 1 September 2004 16:58:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:34 GMT