misunderstood URLs

[skurfer]

Certain URLs aren’t handled correctly by QSObject(URLHandling).

For example: https://developer.apple.com/library/mac/#featuredarticles/BuildingWithBlocks/_index.html#//apple_ref/doc/uid/TP40010249 will end up with “http://” prepended to it.

NSURL URLWithString: is to blame. It doesn’t parse the URL, so the scheme appears to be missing.

A possible fix is to split the URL on # and then check for a scheme in the first item.

I’ll fix this after 64bit-support is merged.

[pjrobertson]

I think this is more a problem with the URLWithString: method than Quicksilver itself.

Clearly that URL is not a valid URL as defined by the RFC 2396

From the Apple NSURL docs:

The NSURL class fails to create a new NSURL object if the path being passed is not well-formed; the path must comply with RFC 2396. Examples of cases that will not succeed are strings containing space characters and high-bit characters. Should creating an NSURL object fail, the creation methods return nil, which you must be prepared to handle.

It appears the 2nd # is the problem. I think it is a valid URL, but don't know. Perhaps it's worth asking somewhere else on the URL. It could be a bug with URLWithString:

Note: fixing it in that one place won't fix the problem. E.g. in QSObject_StringHandling in the sniffString method, URLWithString will fail there as well.

Should #896 now be closed?

[skurfer]

I think this is more a problem with the URLWithString: method than Quicksilver itself.

Well, obviously. :-)

From the Apple NSURL docs:

The NSURL class fails to create a new NSURL object if the path being passed is not well-formed; the path must comply with RFC 2396. Examples of cases that will not succeed are strings containing space characters and high-bit characters. Should creating an NSURL object fail, the creation methods return nil, which you must be prepared to handle.
It appears the 2nd # is the problem. I think it is a valid URL, but don't know. Perhaps it's worth asking somewhere else on the URL. It could be a bug with URLWithString:

As they say, “be prepared to handle” this case, so I propose that if a scheme can't be found, we split on # (and perhaps ?) and test again. If that works, we accept the string as a URL. It might not be valid, but we don't really need to pass judgement. We just need to store/pass along the string.

Note: fixing it in that one place won't fix the problem. E.g. in QSObject_StringHandling in the sniffString method, URLWithString will fail there as well.

Good point. So maybe we should add a method in NSURL_BLTRExtensions. Something like - (BOOL)hasURLScheme that takes care of this checking.

Should #896 now be closed?

It doesn't paste, but it it doesn't crash any more, so I've closed it.