-
Notifications
You must be signed in to change notification settings - Fork 1.6k
feat: improved XMLArgs processing #3363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: v3/master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see this being the same patch as v2. Here you implemented the extra My bad, this is indeed implemented.ctl:parseXMLintoArgs
: it is not in v2.
bool ParseXmlIntoArgs::init(std::string *error) { | ||
std::string what(m_parser_payload, 17, m_parser_payload.size() - 17); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
17? 🤦 It looks like the lenght of the SecParseXMLIntoArgs
, but alone is so arbitrary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're definitely right, but I just wanted to follow the conventions (see other files) (even if it's not the prettiest solution). If we want to clean up the code, then we should do that as a sub project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the project want this? It is worth tracking then (e.g. creating a new issue with the subproject?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the project want this?
Not necessarily. But we can live together with this.
Just a few example:
It is worth tracking then (e.g. creating a new issue with the subproject?)
Sure, it's been like this for almost ten years. Nobody reported, you are the first, so I can't say this has a priority.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds perfect. But (simple) tickets like this might get additional people into the dev side ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But (simple) tickets like this might get additional people into the dev side ;)
Amen! :)
void MSC_startElement(void *userData, | ||
const xmlChar *name, | ||
const xmlChar *prefix, | ||
const xmlChar *URI, | ||
int nb_namespaces, | ||
const xmlChar **namespaces, | ||
int nb_attributes, | ||
int nb_defaulted, | ||
const xmlChar **attributes) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here on this declaration. Is this the new standard?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, could you show a "reference"? What is the "standard"? What is the "old" standard?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The signature of the function is just in the same line, normally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I had pointed out in the other PR, there are already several different ways of formatting long function signatures in the code base. This is one of them.
void *userData, | ||
const xmlChar *name, | ||
const xmlChar* prefix, | ||
const xmlChar* URI) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above.
It's there. |
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
Co-authored-by: Max Leske <[email protected]>
|
I added a few new commits here as at #3358:
|
Just out of curiosity, have you tried enabling this and sending a big xml file? |
What do you mean "a big xml file"? Btw the size of the file is just one thing... There are couple of limits in the engine when you're sending an XML payload and want to process it as ARGS, like:
I sent an XML with size > 400kB (I increased the
Actually, the behavior of this function is exactly the same as that used for JSON. There is no difference. You could ask "have you tried enabling this and sending a big JSON file?". But the JSON works as is, and this feature is optional. If you tell me what you're curious about, I'll try it - with an XML and a JSON too. |
The sentence starts with |
@@ -225,8 +225,7 @@ class RulesSetProperties { | |||
|
|||
/** | |||
* | |||
* The ConfigBoolean enumerator consists in mapping the different | |||
* states of the configuration boolean values. | |||
* The ConfigBoolean enumerator the states for configuration boolean values. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* The ConfigBoolean enumerator the states for configuration boolean values. | |
* The ConfigBoolean enumerator defines the states for configuration boolean values. |
m_secXMLExternalEntity(PropertyNotSetConfigBoolean), | ||
m_secXMLParseXmlIntoArgs(PropertyNotSetConfigXMLParseXmlIntoArgs), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
m_secXMLExternalEntity(PropertyNotSetConfigBoolean), | |
m_secXMLParseXmlIntoArgs(PropertyNotSetConfigXMLParseXmlIntoArgs), | |
m_secXmlExternalEntity(PropertyNotSetConfigBoolean), | |
m_secXmlParseXmlIntoArgs(PropertyNotSetConfigXMLParseXmlIntoArgs), |
* The ConfigXMLParseXmlIntoArgs enumerator defines the states for the configuration | ||
* XMLParseXmlIntoArgs values. | ||
* The default value is PropertyNotSetConfigXMLParseXmlIntoArgs. | ||
*/ | ||
enum ConfigXMLParseXmlIntoArgs { | ||
TrueConfigXMLParseXmlIntoArgs, | ||
FalseConfigXMLParseXmlIntoArgs, | ||
OnlyArgsConfigXMLParseXmlIntoArgs, | ||
PropertyNotSetConfigXMLParseXmlIntoArgs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* The ConfigXMLParseXmlIntoArgs enumerator defines the states for the configuration | |
* XMLParseXmlIntoArgs values. | |
* The default value is PropertyNotSetConfigXMLParseXmlIntoArgs. | |
*/ | |
enum ConfigXMLParseXmlIntoArgs { | |
TrueConfigXMLParseXmlIntoArgs, | |
FalseConfigXMLParseXmlIntoArgs, | |
OnlyArgsConfigXMLParseXmlIntoArgs, | |
PropertyNotSetConfigXMLParseXmlIntoArgs | |
* The ConfigXmlParseXmlIntoArgs enumerator defines the states for the configuration | |
* XmlParseXmlIntoArgs values. | |
* The default value is PropertyNotSetConfigXmlParseXmlIntoArgs. | |
*/ | |
enum ConfigXmlParseXmlIntoArgs { | |
TrueConfigXmlParseXmlIntoArgs, | |
FalseConfigXmlParseXmlIntoArgs, | |
OnlyArgsConfigXmlParseXmlIntoArgs, | |
PropertyNotSetConfigXmlParseXmlIntoArgs |
/* | ||
* XMLNodes for parsing XML into args | ||
*/ | ||
XMLNodes::XMLNodes(Transaction *transaction) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
XMLNodes::XMLNodes(Transaction *transaction) | |
XmlNodes::XmlNodes(Transaction *transaction) |
handler->onCharacters(userData, ch, len); | ||
} | ||
} | ||
|
||
XML::XML(Transaction *transaction) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
XML::XML(Transaction *transaction) | |
Xml::Xml(Transaction *transaction) |
what
This PR adds a new feature within XML processing. It's same as the #3358 but for v3.
why
See v2 patch.
references
See #3178 and #3358.