<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font size="-1"><font face="Lucida Console"><font face="Lucida
Console">Yes, that could be possible.<br>
<br>
A<font face="Lucida Console"> web server </font>should tr<font
face="Lucida Console">y to </font>URL decode anything that
<font face="Lucida Console">has been <font face="Lucida
Console">en<font face="Lucida Console">coded<font
face="Lucida Console">, that is, any </font>%<font
face="Lucida Console">xx <font face="Lucida Console">token</font></font>.<br>
<br>
<font face="Lucida Console">But I have hit one server
that doesn't do this<font face="Lucida Console">, and
that's why I'm <font face="Lucida Console">here. <font
face="Lucida Console">It doesn't seem to be <font
face="Lucida Console">doing any decod<font
face="Lucida Console">ing.</font></font></font>
:(<br>
<br>
<br>
<font face="Lucida Console">Ti<font face="Lucida
Console">m</font></font><br>
</font></font></font><font face="Lucida Console"><font
face="Lucida Console"></font></font><br>
<br>
</font></font></font></font></font></font>
<div class="moz-cite-prefix">On 18/06/2014 10:18 AM, Even Rouault
wrote:<br>
</div>
<blockquote
cite="mid:201406181518.55614.even.rouault@mines-paris.org"
type="cite">
<pre wrap="">Le mercredi 18 juin 2014 14:47:47, Timothy Astle a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">I was thinking something like the following:
if( (pszInput[iIn] >= 'a' && pszInput[iIn] <= 'z')
|| (pszInput[iIn] >= 'A' && pszInput[iIn] <= 'Z')
|| (pszInput[iIn] >= '0' && pszInput[iIn] <= '9')
- || pszInput[iIn] == '_' || pszInput[iIn] == '.' )
+ || pszInput[iIn] == '$' && pszInput[iIn] == '-'
+ || pszInput[iIn] == '_' || pszInput[iIn] == '.'
+ || pszInput[iIn] == '+' && pszInput[iIn] == '!'
+ || pszInput[iIn] == '*' && pszInput[iIn] == '\''
+ || pszInput[iIn] == '(' && pszInput[iIn] == ')'
+ || pszInput[iIn] == '"' && pszInput[iIn] == ',' )
which follows the list of special characters that may be used unencoded
within a URL.
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL.
That list is mutually exclusive from the list you cited as being a
concern, which I agree with.
</pre>
</blockquote>
<pre wrap="">
Looks reasonable, although I anticipate we might hit server bugs if changing
that...
</pre>
<blockquote type="cite">
<pre wrap="">
Tim
On 17/06/2014 6:24 PM, Even Rouault wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Le lundi 16 juin 2014 14:20:59, Timothy Astle a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
Does anyone know why CPLEscapeString
(<a class="moz-txt-link-freetext" href="https://svn.osgeo.org/gdal/trunk/gdal/port/cpl_string.cpp">https://svn.osgeo.org/gdal/trunk/gdal/port/cpl_string.cpp</a>) character
encodes characters that are valid as-is according to
<a class="moz-txt-link-freetext" href="http://www.ietf.org/rfc/rfc1738.txt">http://www.ietf.org/rfc/rfc1738.txt</a>?
I just hit a situation where I noticed the WMS driver is converting
hyphens to %2D for layer names. The 3rd party server doesn't handle it
(but it should) and this caught my attention.
Any thoughts? Is it just a case where a patch would be welcome?
</pre>
</blockquote>
<pre wrap="">
Tim,
What would your patch do ? Implement the following from RFC1738 ? :
"Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL."
Well, actually I think it should still encode the reserved characters
(";",
"/", "?", ":", "@", "=" and "&"), since valid use cases of
CPLEscapeString(,
CPLES_URL) might be do make sure that they are encoded.
Even
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<div style="width:600px;"> Tim Astle<br>
Development Manager<br>
Web Technologies<br>
<br>
<a href="http://www.caris.com" style="color:#004680;"><strong>CARIS</strong></a><br>
115 Waggoners Lane<br>
Fredericton, New Brunswick<br>
Canada E3B 2L4<br>
Tel: +1.506.458.8533 Fax: +1.506.459.3849<br>
<a href="http://www.caris.com" style="color:#004680;">www.caris.com</a>
<p style="margin-top:20px;"> <strong style="color:#373737;">Connect
with CARIS</strong><br>
<a href="http://www.twitter.com/CARIS_GIS"
style="color:#004680;">Twitter</a> | <a
href="http://www.linkedin.com/groups?mostPopular=&gid=3217878"
style="color:#004680;">LinkedIn</a> | <a
href="https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878"
style="color:#004680;">Facebook</a> | <a
href="https://plus.google.com/b/114389770462919844434/114389770462919844434/posts">Google+</a>
| <a href="http://www.youtube.com/user/CARISGIS"
style="color:#004680;">YouTube</a> </p>
<p style="margin-top:16px; line-height:1.2em;">Download your
free copy of CARIS Easy View today!<br>
<a href="http://www.caris.com/easyview" style="color:#004680;">www.caris.com/easyview</a></p>
<p style="font-size:0.8em;">_________________________________________________________________________<br>
This email and any files transmitted with it are confidential
and intended only for the addressee(s). If you are not the
intended recipient(s) please notify us by email reply. You
should not use, disclose, distribute or copy this
communication if received in error.</p>
<p style="font-size:0.8em;"> Any views or opinions expressed in
this email are solely those of the author and do not
necessarily represent those of the company. No binding
contract will result from this email until such time as a
written document is signed on behalf of the company.</p>
</div>
</div>
</body>
</html>