FS#1213 Encoded URLs are not found (doku.php%3Fid%3Dname%3Aname)

other

• 

  2007-08-05 furun

  Encoded URLs are not found
  
  doku.php%3Fid%3Dname%3Aname
  
  (doku.php?id=name:name)
  
  
• 

  2007-08-05 andi

  Do you consider this a bug report? Try to explain the bug and give some infos or it will be closed.
• 

  2007-08-05 furun

  Dokuwiki down't convert url-codes like "%EF %3D %26" to "? = &"
  
  result is "doku.php_id_name:name"
  not "doku.php?id=name:name"
  
  some Browser seems to use url-encoding for the whole string.
  /doku.php%3Fid%3D... 128.241.20.83 Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) en, *;q=0.7
  
  maybe MSIE 7.0 problem (?!)
  
  Tray it out...!!
  http://wiki.splitbrain.org/doku.php%3Fid%3Dgames
  
  
  
• 

  2007-08-05 andi

  The URL you gave is not correct. Only a real question mark is treated as separator between filename and parameters. The correct encoded URL would be http://wiki.splitbrain.org/doku.php?id=games or http://wiki.splitbrain.org/doku.php?id=wiki%3Adokuwiki which will be handled fine by DokuWiki. Are you saying that DokuWiki somewhere produces the given URL?
  
  If so where and under which conditions?
• 

  2007-08-05 ChrisS

  Surely that is an incorrectly encoded URL.  '?' is a reserved character and should never be encoded, at least that is my understanding per http://www.w3.org/Addressing/URL/uri-spec.html
  
  "<snip>... However, the reserved characters mentioned above have a quite different significance when encoded, and so may NEVER be encoded and unencoded in this way."
  
  Doesn't the webserver process the URI (incl. query string) before handing it to the PHP script (e.g. dokuwiki)?  I don't think its appropriate for DW to attempt to grab the raw data and second guess that process.
• 

  2007-08-05 furun

  No, DW is not producing links like this.
  i fond in my log some not-found pages wit this request string error.
  So DW should replace this special characters ?&= before it cuts the request string to $ID $IDX $ACT..., i thing it should happen in getID() function.
  also files with special characters like äöü are in this case not found.
  Im not sure it is better to replace only ?=& or urldecode the complete request string before using it.
  
  But i am not sure, if this is a new m$ bug in IE7 or something else, which encode all special characters (non letters) in the request in %-code. Or perhaps it colt be too a broken bot/harvester. I fund not so many requests like this, but is seems not to by a bot/harvester. Or this Browsers maybe found an follow somewhere a link with this wrong encoding. (no referer percent, can not check it..)
  
  The bugfix (if so, it fix a bug outside of DW) fix the problem with some Browsers/Requests, witch url-encode the complete request string, before access on the page. So makes DW again a bit more stabile, and user are not see a 404 in this case.
  
  If you Check your logs, you have no not-found pages on your site with this problem?
  No problems now with unicode languages? (i check this with äöü, DW encodes the filenames in ulrencode, and decode it again correctly at reading. But access form outside cold by a problem, maybe if they not obey http://www.w3.org/Addressing/URL/uri-spec.html.)
  
  ... if you find no such problems, with your many accesses, its maybe a rare bug and can by ignored, (i only report if i find something suspicious to help bugfixing ;)
  
• 

  2007-08-09 andi

  DokuWiki can not decode those characters, because it would *break* URL handling. When the browser sends those characters encoded instead as plain ASCII it is meant to be taken as part of the filename and not as parameter delimiter. If a browser sends them encoded this way, it either is a broken browser (very, very unlikely even for Microsoft) or a broken script/website which accidentally double encoded an URL somewhere.
  
  You should check your error logs for the referrer given for those faulty requests. This might point you to an erroneous page originating these requests.
  
  About Umlauts: they have to be encoded as UTF-8 multibyte chars, umlauts encoded as singlebyte ISO-8859-1 chars will not work with DokuWiki. Eg. an ü needs to be encoded as %C3%BC instead of %FC. Handling latin1 encoded URLs in DokuWiki could be implemented, but I'm not sure it is necessary. If you think this should be done, please open a new feature request.
  
  Because you said, DokuWiki does not produce these links itself anywhere I'll close this task... feel free to open a feature request for the umlaut thing.