Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

misunderstood URLs #921

Closed
skurfer opened this Issue · 2 comments

3 participants

@skurfer
Owner

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.

@skurfer skurfer was assigned
@pjrobertson
Owner

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
Owner

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.

@tiennou tiennou closed this in d69a57b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.