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