Re: [xml] spaces in uri, again

PaweÅ PaÅucha wrote:

> The problem is that this string taken in isolation doesn't mean much
> even if you think it's is an URI.

The only one who knows what is a good representation of particular URI is the application. So, perhaps, the reasonable thing to do is:

- if URI looks ok, try to load it without modifing
- if URI looks bad (for example, contains spaces), try to do something reasonable with it (something like xmlURIEscapeStr(uri, ":;/?,&"))

Perhaps even a global flag to force 'do not touch URI' can be used, so there is a way for application to pass URI as application wants, and not as libxml2 thinks. The one good thing is that now it doesn't work at all, so it's easy not to make it worse ;-)

Perhaps other users of library can tell us - are you passing URI's escaped or unescaped?

I see incoming URIs in both forms depending upon the scheme used. Though this particular issue applies indirectly in my case as the xml I/O callbacks are not used and the URI is handled within the app with custom callbacks. In the callbacks themselves the escaping done within libxml2 needs to be handled and my take on it is that if xmlParseURIReference on the passed URI comes back with a scheme then its already escaped correctly otherwise it needs to be unescaped.

Note: In my case filesystem URIs need to be unescaped within the callback so those are handled different and a scheme of "file" gets unescaped as well.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]