Jump to content

Double encoding of URL encoded characters in custom web search URL [Fixed EA11 b2053]


Recommended Posts

I have a custom web search for JIRA with the following URL:

https://jiradomain/issues/?jql=key1%20%3D%20value1%20AND%20key2%20~%20%22{query}*%22%20ORDER%20BY%20created%20DESC

 

This URL works fine in Alfred 4.6.7, but in 5.0.0 EA10 the already encoded characters are encoded again, breaking the URL.

Edited by Tsunami
Link to comment
Share on other sites

I can’t reproduce. If I understand your description correctly, key1%20%3D%20value1%20AND should be showing up as key1%2520%253D%2520value1%2520AND when expanded, but I’m seeing the original URL. Can you do Copy URL for sharing in the search’s configurations and paste it here?

Link to comment
Share on other sites

Posted (edited)

Had to anonymize a few things, but here you go:

alfred://customsearch/Search%20JIRA%20for%20'%7Bquery%7D'/jira/utf8/nospace/https://jiradomain/issues/?jql=project%2520%253D%2520BLA%2520AND%2520%2528summary%2520~%2520%2522%7Bquery%7D*%2522%2520OR%2520description%2520~%2520%2522%7Bquery%7D*%2522%2529%2520ORDER%2520BY%2520created%2520DESC

 

I tried recreating the custom web search, but it still behaved the same.

 

Here's the output of Copy URL for sharing in 4.6.7:

alfred://customsearch/Search%20JIRA%20for%20%27%7Bquery%7D%27/jira/ascii/nospace/https%3A%2F%2Fjiradomain%2Fissues%2F%3Fjql%3Dproject%2520%253D%2520BLA%2520AND%2520%2528summary%2520~%2520%2522%7Bquery%7D%2A%2522%2520OR%2520description%2520~%2520%2522%7Bquery%7D%2A%2522%2529%2520ORDER%2520BY%2520created%2520DESC

 

Edited by Tsunami
Link to comment
Share on other sites

I may be seeing something similar — as some of my searches are failing in my Twitter Toolkit, as was reported by a user.

 

For example, I can search for my tweets which have specific hashtags: 

 

image.thumb.png.21cbcfce3dd1092ef64fb89e15904ed6.png

 

This search results in this URL, which works correctly:

https://twitter.com/search?q=(%23newtwitter) (from%3Achrismessina)&src=typed_query&f=live

 

If I double up my pound signs (e.g. search for "#newtwitter), this breaks on Twitter:

https://twitter.com/search?q=(%23#newtwitter) (from%3Achrismessina)&src=typed_query&f=live

image.thumb.png.c0295c716bbac36efb40b45caa755865.png

 

 

I'm wondering if there's a new escaping that's happening with the Loosened URL validation?

 

337368882_2022-07-11(13_26.51)GoogleChrome@2x.thumb.png.cbefb737ff6bc2f11670f96b21092ba8.png

Link to comment
Share on other sites

I'll look into this tomorrow morning, and this is to do with the additional flexibility you have with the Open URL object now.

 

Essentially, Alfred now has to make a decision on what {query} represents, i.e. does it represent part of the URL as a whole, or a query parameter. This is a complex task, and it seems that there are a couple of things which Alfred's new URL parser have been overlooked.

 

In the example Chris gave, Alfred isn't encoding the # which forms part of the query, therefore the browser is treating that as a # anchor link and not passing it to Twitter. Alfred, in this case, should be encoding the # to %23 as the {query} is part of a URL query.

Link to comment
Share on other sites

I'm in the process of testing and updated Open URL object. The issue is a mismatch between the encoding state of the URL being opened, and the encoding state of the {query} or {var:} replacements. I am looking to address this with two new options in the Open URL object.

image.png

By default, you'd leave both these options checked and the URL would be a valid URL. Essentially, the behaviour would match what you'd have in Alfred 4.

 

If you want to do something special with the {query} and {var:} replacements from an upstream object, or using them arbitrarily within a URL, these two options will give you the flexibility of passing them to Alfred's URL processor as-is.

 

I'll have a new build out later today for you to test.

 

Cheers,

Andrew

Link to comment
Share on other sites

Build 2053 is now available which makes some fundamental changes to the way URLs work.

 

Would you mind updating and giving it a test? @Chris Messina I tested the twitter URL you provided and it looks like it should now work again as expected.

 

Thanks,

Andrew

Link to comment
Share on other sites

  • Andrew changed the title to Double encoding of URL encoded characters in custom web search URL [Fixed EA11 b2053]

In the 5.0.1 pre-release, I've actually removed the / from the encoding character list. While the discussion above results in the "correct" use of the new options in the Open URL object, this tweak should make the encoding options more forgiving either way.
 

Link to comment
Share on other sites

  • 2 weeks later...

Hello,

 

This issue still happens on my Alfred 5.0.1 Build 2067.

 

Below is the simple repro case (actually, this issue was also found in JIRA JQL search):

https://www.google.co.jp/search?q="{query}"

 

In my case, if I invoke the web search via the "Test" button in the "Validation" section, it correctly works:

https://www.google.co.jp/search?q=%22aaa%20bbb%22

 

... but if I invoke it via Alfred interface, it encodes spaces twice:

https://www.google.co.jp/search?q=%22aaa%2520bbb%22

 

-----

 

Also, I confirmed it doesn't happen if there's no double quotations in the Search URL:

https://www.google.co.jp/search?q={query}

Result:

https://www.google.co.jp/search?q=aaa%20bbb

 

So, seems like the issue still happens if {query} is enclosed with double quotations. The double quotations are required to build a JQL query to search JIRA issues, so this cannot be omitted in my use case.

 

Could you please investigate the space encoding issue happening with double quotations?

Link to comment
Share on other sites

@indigo13love Either untick the Encode {query} placeholder box or (better) fix the URL itself: it should be https://www.google.co.jp/search?q=%22{query}%22, i.e. have the quotes themselves encoded, otherwise you’re mixing modes.

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...