Fix file://c:\some\path\curl.out

[Jan-E]

Sequel to #1187 (comment)

The issue is essentially the same as in the opening post of #1187 (comment)
file://c:\some\path\curl.out
is rejected wih error message:

curl: (3) Invalid file://hostname/, expected localhost or 127.0.0.1 or none

file://c:/some/path/curl.out
is accepted. This is apparently intentional, according to the comment in https://github.com/curl/curl/blob/master/lib/url.c#L2121

   * Additionally, there is an exception for URLs with a Windows drive
   * letter in the authority (which was accidentally omitted from RFC 8089
   * Appendix E, but believe me, it was meant to be there. --MK)

PHP uses the backslash format for file:// URL's. This PR aims to include URL's like file://c:\some\path\curl.out as well.

[Jan-E]

I have read the remark in #1187 (comment) that backslashes in URL's are forbidden by both [RFC1738] and [RFC3986]. Hence, it would be better to fix the issue in PHP. @weltling intends to do that for the actively maintained PHP versions (PHP 7.1 and PHP 7.2), but the fix will not be backported to versions like PHP 5.6 (which will receive security fixes only). If this PR is merged users of PHP 5.6 can also enjoy the enhancements of the latest curl version.

[bagder]

/cc @phluid61

[phluid61]

tl,dr: LGTM

I will be honest, I wasn't sure how to approach the issue of backslashes when I submitted #2110.

Some observations:

1. the STARTS_WITH_DRIVE_PREFIX macro only scans as far as ^[A-Z]:, which means it would match any slash, or indeed any character at all, after the colon -- I'm hesitant to touch that, because of the specific use-case for that macro
2. I included the final anchor (slash or NULL) in the STARTS_WITH_URL_DRIVE_PREFIX macro to ensure it didn't match falsely against random guff like file://x:445/share/file, which could be a legitimate SMB share
3. It recognises the pipe character (e.g. c|) because that is explicitly handled in lib/file.c
4. looking at the routine that converts forward slashes to backslashes, it also implicitly accepts backslash path separators in DOS/Windows
5. in not-Windows, this patch only changes the error message from "bad hostname" to "only MSDOS/Windows" (both CURLE_URL_MALFORMAT), which is either an innocuous change or an improvement

I think 3 and 4 above are enough justification for accepting the patch.

[Jan-E]

Thanks for the review.

I think 3 and 4 above are enough justification for accepting the patch.

@bagder Could you merge it?

[bagder]

Merged, thanks!