On 11/4/2016 11:43 AM, Mike Crowe wrote:
On Friday 04 November 2016 at 08:26:28 -0700, bch wrote:
>On Nov 4, 2016 8:18 AM, "Mike Crowe"<m...@mcrowe.com> wrote:
> >
> >On Friday 04 November 2016 at 08:04:34 -0700, bch wrote:
> > >On Nov 4, 2016 8:01 AM, "Mike Crowe"<m...@mcrowe.com> wrote:
> > > >The fix for this in 3bb273db7e40ebc284cff45f3ce3f0475c8339c2 appears
>to
> > > >have changed the existing behaviour offile:// URLs for me:
> > > >
> > > >On current master (9ea3a6e150dfc822ba1565f649b634848597d2d9):
> > > > $ src/curlfile://config.log
> > > > curl: (37) Couldn't open file /config.log
> > > >
> > > >On master with 3bb273db7e40ebc284cff45f3ce3f0475c8339c2 reverted:
> > > > $ src/curlfile://config.log
> > > > [contents of config.log]
> > > >
> > > >Rightly or wrongly, we've used URLs like"file://test.txt" in many of
>our
> > > >unit tests which are now failing.:(
> > >
> > >What doesfile:///test.txt (3 slashes) yield?
> >
> >On both:
> > $ src/curlfile:///config.log
> > curl: (37) Couldn't open file /config.log
>
>Is that the correct path, or is the fully qualified path something like
>/var/log/config.log (file:///var/log/config.log) ?
/config.log is not the correct path.
./config.log is the correct path.
The change in behaviour is thatfile://config.log used to refer to
./config.log whereas after 3bb273db7e40ebc284cff45f3ce3f0475c8339c2 that
URL now refers to /config.log.
Yes now if the path doesn't start with a slash one is added [1] so it's
going to be rebuilt like
* Rebuilt URL to: file:///
I'm not sure that this is a bug, it seems more correct than it was
before. However if for backwards compatibility we wanted to skip that
for file it should be simple
- if(path[0] != '/') {
+ if(path[0] != '/' && !strcasecompare(protop, "file")) {
[1]: https://github.com/curl/curl/commit/3bb273db7e#diff-8fb104cR4292
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
