Jump to content

Unescaping alfred:// URIs, especially as a query [Fixed 2.8.2 b429]


deanishe
 Share

Recommended Posts

v2.8.1 (425) / El Cap

I was just tinkering with a web search URL on the forum, trying to get it to be clickable and/or visible.

The problem is that the forum software mangles alfred:// URLs if pasted and strips them from BBCode links. The only way to show them on the forum is in code blocks.

And what do you do after copying the URL from the webpage?

If you paste the URL in a web browser, it works correctly:

EF7OKzo.png

However, if you pass the URL to open or paste it into Alfred's query box, the URL isn't unescaped:

Scrw075.png

Link to comment
Share on other sites

  • 2 weeks later...

Sorry about the slow reply on this one, I can see what's happening here...

 

Alfred is pre-encoding the name in the exported URL and when the URL string is then pasted into Alfred, the whole string is encoded again, so..

 

Search%20Just%20Watch%20%27%7Bquery%7D%27

 

is treating this string as absolute and correctly encoding the %s to %25 ready for passing to OS X to launch the URL...

 

Search%2520Just%2520Watch%2520%2527%257Bquery%257D%2527

 

When importing, the %25 is correctly being decoded back to %... so it's essentially double encoding taking place.

 

I've fixed this for the next release :)

 

Cheers,

Andrew

Link to comment
Share on other sites

 

So, Alfred is "double" URL-encoding the URL and then passing it to the system?
 

 

Does that use a different mechanism than open? Because open also doesn't work correctly with URL-encoded alfred:// URLs.

 

 

 

I assume that when you use the open command, it is also encoding the %20 as literal, so %25 for the percent followed by 20, as this is the only way to make it a valid URL.

 

Essentially, the only double encoding happening is when the URL is given back to Alfred (or the open command), and it's treating the entire URL as needing to be encoded as it has no better idea of what you want to do with it.

 

The fix involves making Alfred aware of this on import, so will fix for the open command too.

Link to comment
Share on other sites

I've been poking a stick at it.

 

The URL-handling subsystem doesn't touch URLs that are fully URL-encoded, but does encode URLs that aren't URL-encoded or are only partially URL-encoded.

 

The latter is what's happening here.

 

The unencoded URL for my Linguee Custom Websearch is: 

alfred://customsearch/Search linguee.com for '{query}'/l/ascii/noplus/http://www.linguee.com/deutsch-englisch/search?sourceoverride=none&source=auto&query={query}
 

The fully-encoded URL is:

alfred://customsearch/Search%20linguee.com%20for%20%27%7Bquery%7D%27/l/ascii/noplus/http%3A//www.linguee.com/deutsch-englisch/search%3Fsourceoverride%3Dnone%26source%3Dauto%26query%3D%7Bquery%7D
Alfred handles both these URLs correctly, whether pasted in Alfred or passed to open (Safari treats the unescaped URL as a search query, presumably due to the spaces).

However, the URL Alfred exports is only partially encoded:

alfred://customsearch/Search%20linguee.com%20for%20%27%7Bquery%7D%27/l/ascii/noplus/http://www.linguee.com/deutsch-englisch/search?sourceoverride=none&source=auto&query={query}
 

As a result, the OS X URL-handling subsystem encodes the URL, producing something that's half properly encoded and half double encoded (in terms of the desired result): 

alfred://customsearch/Search%2520linguee.com%2520for%2520%2527%257Bquery%257D%2527/l/ascii/noplus/http%3A//www.linguee.com/deutsch-englisch/search%3Fsourceoverride%3Dnone%26source%3Dauto%26query%3D%7Bquery%7D
Thus, there isn't a problem with Alfred's handling of URLs, but rather the bug is that the exported URLs (for Custom Searches) aren't fully URL-encoded in the first place.

 

I guess it works properly with Safari because that has more robust handling of not-quite-right URLs.

Edited by deanishe
Link to comment
Share on other sites

 

I guess it works properly with Safari because that has more robust handling of not-quite-right URLs.

 

 

 

It's not quite this... it's just Safari is decoding the URL on entering it as this is the destination... so when you paste the URL into Safari, it's not re-encoding anything, it's just decoding the %20 back to spaces before re-encoding on passing to OS X to open in Alfred.

 

There is definitely something a bit funky about Alfred's URL export, and I think it stems back to when Alfred required a pre-url encoded URL as the query part... which means the entire URL would be pre-url encoded and wouldn't need additional encoding.

 

I guess another fix could be to just not URL encode the name when copying as this seems to work anyway (as long as you wrap the URL in quotes with the open command in shell). This may be the more correct fix, what do you think?

 

Cheers,

Andrew

Link to comment
Share on other sites

Hmm playing with this further, if the name of the search doesn't have %20 instead of space, Safari searches in google for it rather than opening with the URL handler as this isn't in the "?" query part of the custom search URL.

 

Edit: I missed that you mentioned this too!

Link to comment
Share on other sites

Yep, you are right on this one... If I also encode the URL part of the custom search, it's looking good. Alfred actually checks if a URL is valid before trying to add encoding, which is why when pasting into Alfred, things aren't re-encoded.

 

I'm gonna change my fix on this to fully encode the custom search export instead!

 

Cheers for you help on this :)

 

Andrew

Link to comment
Share on other sites

Sweet.

I think fully-encoded URLs is the only proper thing to do because unencoded URLs are technically invalid and will likely not work in many contexts, e.g. you can't put a URL containing single quotes into href='...'.

Seeing as there are already loads of partially-encoded URLs in the wild, I imagine Alfred will still need to do some processing of the URLs to avoid any double encoding.

Edited by deanishe
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...