On Fri, 20 Jan 2017, Kees Dekker wrote:

> I discovered that cURL 7.50.1 did accepts, but cURL 7.52.1 did not accept a
> colon in an URL. Example: the following URL did not work:
> file://c://temp/test.xml

Okay, your subject says semicolon and your mail body says colon. But the
problem is actually neither. It is about the number of slashes.

Back in commit 346340808c we made the URL parser for file:// stricter. The
file:// URLs are constructed like this (according to RFC 1738 as well as in
the pending updated spec, draft-ietf-appsawg-file-scheme[1]):

   file://hostname/path

... where we used to ignore the host name since it doesn't serve any purpose.
We learned that it confused and miselad users when used like
file://etc/passwd, as it would appear to be another path than we'd actually
use. So we made the hostname required to be localhost, 127.0.0.1 or blank.

This shipped in 7.52.0 and 7.52.1.

Subsequently, Anatol Belski filed issue #1187 [2] in which he revealed that
PHP and a lot of other infrastructure is using the malformatted version of the
file:// URL to a vast extent and that this change is causing them a lot of
problems. Apparently they are doing something like "file://$path" for all
platforms, which on non-windows thus adds a third slash and everything is
fine, but for windows it'll add a drive letter there instead (ie one slash too
few).

Based on that discussion, Jay Satiro landed commit 1d4202ade602d which brings
back the support for that particular malformed version of the file:// URL.
Since that version, and thus in the coming 7.53.0 release, we will again
accept file://[letter]:/path on Windows.

> I also discovered that back slashes are not allowed anymore (may be related
> to https://github.com/curl/curl/issues/1007). That is also an
> incompatibility breach (but if standards define to do so, it is acceptable).

Backslashes in the URL you mean, instead of regular forward slashes? I'm not
aware of us changing treatment of that recently. Can you elaborate? But yes,
backslashes are not legal characters in URLs and should rather be percent
escaped.

> If the standard does not forbid colons, cURL should also not forbid them,
> isn't it?

I'm pretty sure curl doesn't forbid colons at all.

> If a simple C reproduction is needed, please let me know, I will then make
> one.

If you still believe there's a problem after this mail, then sure please
provide one!

[1] = https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-16
[2] = https://github.com/curl/curl/issues/1187

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html