Re: [xml] patch: Functions to parse and create URI query strings

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 rather
an 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

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?


Emerging Technologies, Red Hat
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

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