Daniel Veillard wrote:
The current uri->query field is always unescaped during parsing. I have changed so it always stored in its raw form. This because otherwise it's impossible to parse query strings such as: file:///tmp/test.html?test=%26&second=%26 which can be generated by web browsers. If anyone was relying on the current semantics, then it seems to me that they cannot parse such query strings correctly.Aside from the number of new APIs, available there, that's my main issue with the patch. You are changing the default behaviour of a functionality exposed like forever.I guess I would really prefer an approach which hooked into the URI parsing itself and filled in an extra list of values (or ratheran array of xmlChar *, alternatively name and values) in the xmlURI structure at the end. That would allow to keep the uri->query data as it was, and still provide the functionalities you suggest, based on a preparsed xmlURIPtr. This would also avoid adding an extra list type.
OK, so I'll rework to integrate this into the normal parsing and saving of URIs and put the results in the URI structure. (Is that right?)
uri->query really must be deprecated though!
I'm not sure about the ignore flag in that list, what it is used for ?
So this is really useful in the situation that I'm actually using this for: I want to parse the URI, remove some of the parameters (basically the ones which my code understands) and leave the rest of the parameters in place for another piece of code down the line to use.
Now, removing a parameter from a linked list is annoyingly complicated, but setting a flag to say "ignore this parameter - I've seen it" is a lot easier. On the other hand, if the complexity is hidden inside a uri.c function then that doesn't matter (so long as it works :-)
- those simplified API would work immediately with the Python generator
which would not find char ** which can't be handled automatically.
So the use of char ** to return values is there because I couldn't see a good way to return an error indication.
As an example, if xmlURIQueryGetSingle were defined as: char *xmlURIQueryGetSingle (xmlURIPtr uri, const char *name);then returning NULL might mean either (1) there is no field with that name, or (2) there was an error, eg. in memory allocation.
About the use of char vs xmlChar: I could really see which one was correct. I understand that xmlChar is unsigned because of some bogosity in the XML spec, so xmlChar is used for characters in XML documents. URIs are different though, so which should I be using?
Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature