Bugs item #1466617, was opened at 2006-04-08 00:10
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1466617&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: new feature request
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Daniel Stenberg (bagder)
Summary: file:// and RFC1738

Initial Comment:
cURL supports file:// but doesn't conform to RFC 1738.

According to RFC 1738 file://remotehost/path/to/file
is a (informal) specification where a file can be
found in the filesystem on "remotehost".

Please see the following log of some curl commands run
on Windows (katmai IS localhost here):

R:\>dir \\katmai\c$\boot.ini
 Datenträger in Laufwerk \\katmai\c$: hat keine
Bezeichnung.
 Datenträgernummer: FCBA-B684

 Verzeichnis von \\katmai\c$

07.03.2006 05:11 1.099
BOOT.INI
               1 Datei(en) 1.099 Bytes
               0 Verzeichnis(se), 3.170.615.296
Bytes frei

R:\>curl -# -v -I file://katmai/c$/boot.ini
* Couldn't open file /c$/boot.ini
curl: (37) Couldn't open file /c$/boot.ini

R:\>curl -# -v -I file://localhost/c$/boot.ini
* Couldn't open file /c$/boot.ini
curl: (37) Couldn't open file /c$/boot.ini

R:\>curl -# -v -I file://127.0.0.1/c$/boot.ini
* Couldn't open file /c$/boot.ini
curl: (37) Couldn't open file /c$/boot.ini

R:\>curl -# -v -I file:///c$/boot.ini
* Couldn't open file /c$/boot.ini
curl: (37) Couldn't open file /c$/boot.ini

R:\>curl -# -v -O file://\\katmai\c$\boot.ini
curl: Remote file name has no length!
curl: try 'curl --help' or 'curl --manual' for more
information

R:\>curl -# -v -I -O file://\\katmai\c$\boot.ini
curl: Remote file name has no length!
curl: try 'curl --help' or 'curl --manual' for more
information

R:\>curl -# -v -I file://\\katmai\c$\boot.ini
Content-Length: 1099
Accept-ranges: bytes
Last-Modified: Tue, 07 Mar 2006 04:11:13 GMT

R:\>curl -# -v -I -O file://C:\boot.ini
curl: Remote file name has no length!
curl: try 'curl --help' or 'curl --manual' for more
information

R:\>curl -# -v -I file://C:\boot.ini
Content-Length: 1099
Accept-ranges: bytes
Last-Modified: Tue, 07 Mar 2006 04:11:13 GMT

R:\>curl -# -v -I file://katmai/c$/boot.ini
* Couldn't open file /c$/boot.ini
curl: (37) Couldn't open file /c$/boot.ini

Now against a remote host (which is ignored with the
valid URL):

R:\>dir \\marsupilami\e$\boot.ini
 Datenträger in Laufwerk \\marsupilami\e$: ist
FESTPLATTE
 Datenträgernummer: 6CA2-A31C

 Verzeichnis von \\marsupilami\e$

17.07.2004 11:27 1.159
BOOT.INI
               1 Datei(en) 1.159 Bytes
               0 Verzeichnis(se), 607.916.032
Bytes frei

R:\>curl -# -v -I file://\\marsupilami\e$\boot.ini
Content-Length: 1159
Accept-ranges: bytes
Last-Modified: Sat, 17 Jul 2004 09:27:59 GMT

R:\>curl -# -v -I file://marsupilami/e$/boot.ini
* Couldn't open file /e$/boot.ini
curl: (37) Couldn't open file /e$/boot.ini

\ ain't a valid char for URLs.
file:/// means file://localhost/, so
file://C:\something is invalid.

Please check RFC 1739 and 2151 too!

Stefan Kanthak

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2006-04-09 10:14

Message:
Logged In: YES
user_id=1110

The file:// URL syntax is not violated by (lib)curl. I agree
that the parser is rather liberal and accepts illegal URLs
but *you* as user are the one who provide an illegal
"violated" URL.

Regarding the scemantic I don't follow your reasonsing. What
exactly are you saying we do wrong that we should fix?

And regarding the docs: yes please, help us improve the docs!

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-04-09 00:38

Message:
Logged In: NO

Hi Daniel,

in fact there are several problems here:
- the file:// URL syntax (which is clearly violated)
- the file:// URL semantics (which will never be
implemented completely on all systems cURL supports)
- the results with different combinations of -I -O (can you
take a deeper look there).

Re syntax: cURL apparently doesn't check anything^Wmuch
after the file:// (well, it seems to strip the hostname
when the correct syntax file://hostname/... is used) and
passed the remainder (as local filename) to the OS.

Re semantic: as I wrote (and you replied) file:// is an
informal description for the location of a file. There
ain't no system I know that supports file://host/"local
path to file".
Windows comes near, but even file://host/c:/... needs to be
mapped for example to file://host/c$/... (and that to
\\host\c$\...) which is but only accessible with
administrative rights on "host".

Please see
http://blogs.msdn.com/freeassociations/archive/2005/05/19/42
0059.aspx for a possible but Windows-only solution.

Please consider to document the current behaviour of
file:// a little bit more as already done:-)

Stefan

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2006-04-08 00:17

Message:
Logged In: YES
user_id=1110

This is by design and you will also note that the RFCs do
not specify _how_ that getting of a file from another system
is supposed to be done.

If you feel like extending curl to do this, I'm sure lots of
users will enjoy it as I certainly will. I personally have
no plans to implement anything like this for the forseeable
future.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1466617&group_id=976
Received on 2006-04-09