This should now be handled better. For details see my comments in SVN
rev 746292.
-David
On Feb 17, 2009, at 8:47 AM, Jacques Le Roux wrote:
As I can't find a good solution, I thought that maybe we could use a
javascript function to change the value (Windows path with
backslashs) before it's encoded. But this means to have it
everywhere it's needed (for instance in contents..., etc.)
What do you think ?
Jacques
From: "Jacques Le Roux" <[email protected]>
As this does not make sens (we are not dealing only with URL, I was
stupid - actually hardly awake). I'm looking for a real
solution...
Jacques
From: "Jacques Le Roux" <[email protected]>
There is something I completly forgot to report about this
problem : canonicalize() is acceptinp escaped \ using traditionnal
\\
(I
also tried \\\\) Of course I tried before implementing my hack,
but this did not work either.
BTW I don't see in which case the string ":\" located at position
1 (ie a string corresponding to the regexp ^.:\.*$) will be
harmfull if backslashs are transformed to forward slashs since I
don't know so far a protocol represented with only 1 character.
So
a not encoded colon can't be found (so far) in a correct URL at
position 1 followed by a not encoded backslash.
Am I overseeing something ? Else we could say that it's
deterministic as long as a protocol is not represendted by a sole
character (an even in that case why shall we find backslash just
after ?)
References:
http://www.rfc-editor.org/rfc/rfc1738.txt
https://kanis.fr/svn/trunk/wk/lisp/muse/muse-protocols.el
HTH
Jacques
From: "Jacques Le Roux" <[email protected]>
I just tried on demo server
input
c:\quelque_chose\nimportequoi
error
ERROR: reading file name (c:quelque_chosenimportequoi): null
In debugger locally
input
D:\workspace\ofbizRun\applications\ecommerce\data\DemoProduct.xml
canonicalized
D:workspaceofbizRun
plicationsìmmerceÚaÞoProduct.xml
Error
ERROR: reading file name (D:workspaceofbizRun<br/
>plicationsìmmerceÚaÞoProduct.xml): null
I meaned ugly :o)
Jacques
From: "David E Jones" <[email protected]>
On Feb 15, 2009, at 11:18 AM, Jacques Le Roux wrote:
In other words, the information I have from both emails is
that "it doesn't work". But, WHY doesn't it work? HOW is it
failing? Any error messages or other information about what
is actually happening
(perhaps even the stuff I mentioned in my previous email
about what the canonicalized String that is causing the
problem
looks
like)?
The canonicalized String (without my change) is ugly and I
guess you will not get much information from it.
That's the point! It's great to know that it is ugly, but what
does that MEAN?
Actually my guess is that 100% of the information I need I'll
get from that text. If I understand right the WHOLE problem with
this is that the string input by the user is being mangled so
the system can't use it. Therefore the only really relevant
details are:
1. an example of an original string that this is breaking
2. what that string looks like after it has been "mangled" by
the canonicalization
Chances are with just that information we can find a better
solution to this.
-David
