Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

misunderstood URLs #921

Closed
skurfer opened this issue Jun 7, 2012 · 2 comments
Closed

misunderstood URLs #921

skurfer opened this issue Jun 7, 2012 · 2 comments
Milestone

Comments

@skurfer
Copy link
Member

@skurfer skurfer commented Jun 7, 2012

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.

@ghost ghost assigned skurfer Jun 7, 2012
@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Jun 7, 2012

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
Copy link
Member Author

@skurfer skurfer commented Jun 8, 2012

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 as completed in d69a57b Oct 3, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants