RE: File protocol host need not be limited to "localhost"

Jeff Kowalski (jeff.kowalski@autodesk.com)
Tue, 14 Jul 1998 23:01:27 -0700 

Was a decision reached on this proposal?

Thanks,
jeff

>   -----Original Message-----
>   From: Jeff Kowalski [mailto:jeff.kowalski@ktx.com]
>   Sent: Saturday, June 13, 1998 2:26 PM
>   To: 'Gisle Aas'; Jeff Kowalski (E-mail)
>   Cc: 'libwww-perl@ics.uci.edu'
>   Subject: RE: File protocol host need not be limited to "localhost"
>   
>   
>   Gisle,
>   
>   Thanks for your response.  My comments are below.
>   
>   >>   -----Original Message-----
>   >>   From: Gisle Aas [mailto:gisle@aas.no]
>   >>   Sent: Tuesday, June 09, 1998 4:09 AM
>   >>   To: Jeff Kowalski
>   >>   Cc: 'libwww-perl@ics.uci.edu'
>   >>   Subject: Re: File protocol host need not be limited to 
>   "localhost"
>   >>   
>   >>   
>   >>   Jeff Kowalski <jeff.kowalski@autodesk.com> writes:
>   >>   
>   >>   > I noticed today that there's some code in 
>   >>   LWP\Protocol\File.pm like this:
>   >>   > 
>   >>   > 
>   >>   >     my $host = $url->host;
>   >>   >     if ($host and $host !~ /^localhost$/i) {
>   >>   >     	return new HTTP::Response 
>   >>   &HTTP::Status::RC_BAD_REQUEST_CLIENT,
>   >>   > 				  'Only 
>   file://localhost/ allowed';    
>   >>   >     }
>   >>   >     
>   >>   >     # URL OK, look at file
>   >>   >     my $path  = $url->local_path;
>   >>   > 
>   >>   > 
>   >>   > Of particular note is the section that returns an 
>   error if the
>   >>   > host is not "localhost".  Interestingly, Win32 
>   systems support the
>   >>   > non-localhost specifiers just fine - they're simply 
>   UNC naming 
>   >>   > conventions.  For example, it's perfectly legal while on
>   >>   > host "foo" to request file://server/folder/item.  On 
>   Win32, and
>   >>   > on other systems, this requests the "item" stored in 
>   "folder" on
>   >>   > the "server" machine.  On Win32, it magically works.
>   >>   > 
>   >>   > I'd like to propose enabling this feature, which amounts to
>   >>   > the following changes to the lines shown above:
>   >>   > 
>   >>   > 
>   >>   >     my $path = $url->local_path;
>   >>   >     my $host = $url->host;
>   >>   >     if ($host and $host !~ /^localhost$/i) {
>   >>   >         if ($^O ne 'MSWin32') {
>   >>   >         	return new HTTP::Response 
>   >>   &HTTP::Status::RC_BAD_REQUEST_CLIENT,
>   >>   >     				  'Only 
file://localhost/ allowed';
>>         }
>>         $path = '//' . $host . '/' . $path;
>>     }
>> 
>>     # URL OK, look at file
>> 
>> 
>> In fact, on Win32 systems, this amounts to the
>> removal of 'localhost', which is precisely what
>> you want, since 'localhost' isn't meaningful in Win32 systems.
>> Other hosts, however, are conveniently preserved.

>In LWPng I already made access file://host/ URLs produce a 302
>redirect to ftp://host/.  This seems to be somehow compatible with how
>Netscape behaves on my Linux machine.

JK: Unfortunately, this is not true on Win32 systems.  The ftp: "virtual"
roots are generally not the same as the URLs, so file://host does *not*
usually map to ftp://host.  Moreover, most Win32 machines run the server
component that handles the UNC-named files, but don't run an FTP server.
So, on Win32, your scheme will not work.

>The problem with this is that we don't have any specification on how
>things like this should be handeled.  Do Netscape or MSIE behave as
>you propose on Windows?

JK: Yes both MSIE and NS behave as I've proposed.

>BTW, what is the "standard" way of handling the A: or C: prefixes that
>dosish systems give us?

	file://c:/temp/test.txt => open (FH, "c:/temp/test.txt");
	file://c:\temp\test.txt => open (FH, "c:\\temp\\test.txt");
	file://localhost/c:/temp/test.txt => open (FH, "c:/temp/test.txt");
	file://remotehost/c:/temp/test.txt is not legal

I'm afraid I don't know enough about the parsing in the URL package
to make the necessary modifications to support these three legal URLs,
but I'm also not sure how often the drive specifiers are even used in URLs.
Do you hear that they're used?

Implementing the change I originally recommended would go a long
way toward supporting Win32 systems.  Beyond that, supporting the
first two URLs listed above would help, and if you're really 
ambitious, you could go after the third one.  But, like I said
before, supporting the realtively common "file://server/folder/item" 
would be great!

Let me know what you think.
Please remember to include me in your response, since I'm not
on the mailing list.

Thanks,
jeff