Last modified: 2014-01-28 19:21:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T62526, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 60526 - Apostrophes in URL titles causing problems
Apostrophes in URL titles causing problems
Status: RESOLVED FIXED
Product: QRpedia
Classification: Unclassified
General (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: ---
Assigned To: Kelson [Emmanuel Engelhart]
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-28 12:24 UTC by Thomas Morton
Modified: 2014-01-28 19:21 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Thomas Morton 2014-01-28 12:24:15 UTC
Some codes have been created using a pasted URL with urlencoding (e.g. ' was pasted as %27). This has caused problems because the QR Code encodes the url further rendering it as %2527.

I temporarily fixed the problem by removing one urlencoding step in the qrwp.org forwarder code.

However, this needs fixing long term.

I suggest that QRpedia.org interface needs to silently convert any encoded urls into their un-encoded variant. And we need some sanity checking in the forwarder code to handle edge cases.
Comment 1 Kelson [Emmanuel Engelhart] 2014-01-28 12:39:32 UTC
Thank you for opening that bug Tom.

IMO, the best approach is, as far as possible, to not modify (urldecode/urlencode) anything and take the "title" as it is.

The problem is with the already existing QR codes, a few of them have double encoded urls. Is that what you mean with edge cases? If yes, I don't see any rigorous way to detect them.
Comment 2 Thomas Morton 2014-01-28 12:44:19 UTC
We do have to urlencode some things, because that is a requirements of the QR code. So we have no route around that.

Yes some of the current codes have double encoded urls; the hack I implemented fixes them. What was happening was the nginx server was decoding the first encoding (as it was supposed to). What the code then does is urlencode the request before forwarding it. So we were re-inserting the double encoding! Ooops :)

However, removing that last encoding step shouldn't be a long term solution. We do need to encode the url to make sure it is definitely compatible in the widest possible uses!

Also we need to be able to handle other server setups, in the case that QRpedia gets deployed somewhere else.

We may need to create a number of test cases to see how this works and how to handle them.

And we definitely need to consider sanity checking on the front end code generation interface.
Comment 3 Kelson [Emmanuel Engelhart] 2014-01-28 19:21:42 UTC
I have fixed the problem on GIT master branch by:
* Detecting on qrpedia if the given url is URLencoded and avoiding double encoding.
* Avoiding to urlencode HTTP "Location" header value on qrwp. Doing like this allows to be backward compatible with double urlencoded values.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links