551219 - [API 1.2] : Tools->Add-ons, searching for add-on name which contains non-ascii characters gives message "No matching add-ons"

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: API, defect)

Description

[Pratibha]

Tested Browser: FF3.6: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 
Tools->Add-ons : API 1.2

Steps:
---------
1.Open Tools->Addons
2.Type into the search field some non-ascii characters and press Enter key
ex: copy/paste chinese add-on name from the details page of the add-on with id: https://preview.addons.mozilla.org/en-US/firefox/addon/6113

[API 1.2] - Tools->Add-ons:FAIL: gives message "No matching add-ons"

Using LiveHTTP Headers : URL noticed in Add-ons manager is: https://preview.addons.mozilla.org/en-US/firefox/api/1.2/search/%25E6%2596%25B0%25E5%2590%258C%25E6%2596%2587%25E5%25A0%2582/all/10/WINNT/3.6


While API 1.2, 1.3 URLs: PASS: shows the add-ons with non-ascii,multibyte chars:
https://preview.addons.mozilla.org/en-US/firefox/api/1.2/search/<multibyte-chars>
https://preview.addons.mozilla.org/en-US/firefox/api/1.3/search/<multibyte-chars>

Comment 1

[Wil Clouser [:clouserw]]

I don't think this is our bug.  It looks like the add-on manager is double escaping data.  If you search for "新同文堂" it's sent to the API as %25E6%2596%25B0%25E5%2590%258C%25E6%2596%2587%25E5%25A0%2582 whereas if you just type it in the URL it's %E6%96%B0%E5%90%8C%E6%96%87%E5%A0%82 and works properly.  CCing mossop for confirmation.

Comment 2

[Dave Townsend [:mossop]]

We are double escaping data because of some apache bug that this was apparently the only way to work around, see bug 551219 comment 6

Comment 3

[Wil Clouser [:clouserw]]

-> davedash

We talked about this on IRC a bit.  I think we're not running into the mod_rewrite bug anymore because python is doing the dirty work now.  Can you add a switch for API < 1.5 to double-unescape the queries, and just let 1.5 and above pass through?  mossop will make the switch on the client side for the 1.5 version.

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

This bug has been marked fixed; was comment 3 addressed?

Comment 6

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

Yes search strings for api < 1.5 are double unencoded.

Comment 7

[Pratibha]

Able to see the results while searching for 新同文堂 in Tools->Add-ons: API 1.2
but noticed the 
Bug 553250 -  search fails with non-ascii characters in API 1.2 and 1.3 URLs

Comment 8

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Post-fix screenshot

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED.