Namespace prefix starting mit xml are marked as illegal #126

Closed
michael-o opened this Issue Mar 12, 2014 · 16 comments

Comments

Projects
None yet
3 participants
@michael-o

I am using JDOM with JMeter and the XML Assertion. My sample unfortunately includes following element:

 <XMLFault:XMLFault>...</XMLFault:XMLFault>

So, unfortunately, the producing service uses a custom namespace prefix beginning with "xml". According to this one SHOULD NOT use such a prefix and the processor MUST NOT fail.

JDOM fails. This is erractic behavior.

@rolfl

This comment has been minimized.

Show comment
Hide comment
@rolfl

rolfl Mar 13, 2014

Collaborator

Ouch. OK, I understand your predicament. This is not something trivial to fix because JDOM cannot simply blanket-accept xml-prefixed namespace values. There will need to be some sort of configuration to 'disable' the error-handling.... in a few places.

Do you have a suggestion as to how you would like to see it fixed? (not the code changes, but a desription of the behaviour - although code-changes would be acceptable too ;-) It will still need to disallow users from creating xml-starting namespaces.

Collaborator

rolfl commented Mar 13, 2014

Ouch. OK, I understand your predicament. This is not something trivial to fix because JDOM cannot simply blanket-accept xml-prefixed namespace values. There will need to be some sort of configuration to 'disable' the error-handling.... in a few places.

Do you have a suggestion as to how you would like to see it fixed? (not the code changes, but a desription of the behaviour - although code-changes would be acceptable too ;-) It will still need to disallow users from creating xml-starting namespaces.

@rolfl

This comment has been minimized.

Show comment
Hide comment
@rolfl

rolfl Mar 13, 2014

Collaborator

Is it possible for you to provide a full example XML document I can test against? I guess I coud manufacture one myself, but would prefer your use-case.

Collaborator

rolfl commented Mar 13, 2014

Is it possible for you to provide a full example XML document I can test against? I guess I coud manufacture one myself, but would prefer your use-case.

@hunterhacker

This comment has been minimized.

Show comment
Hide comment
@hunterhacker

hunterhacker Mar 13, 2014

Owner

Why can't we blanket-accept xml-prefixed namespace prefixes? Isn't that what the spec is telling us we must do?

So just remove the Verifier check:

    // Cannot start with "xml" in any character case
    if (prefix.toLowerCase().startsWith("xml")) {
        return "Namespace prefixes cannot begin with " +
                "\"xml\" in any combination of case";
    }

And perhaps add in its place a check that user code isn't defining "xml" or "xmlns".

Owner

hunterhacker commented Mar 13, 2014

Why can't we blanket-accept xml-prefixed namespace prefixes? Isn't that what the spec is telling us we must do?

So just remove the Verifier check:

    // Cannot start with "xml" in any character case
    if (prefix.toLowerCase().startsWith("xml")) {
        return "Namespace prefixes cannot begin with " +
                "\"xml\" in any combination of case";
    }

And perhaps add in its place a check that user code isn't defining "xml" or "xmlns".

@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o Mar 13, 2014

I would definitively hinder a client creating such namespace prefixes but would not fail if a file with such prefixes is read.

I would definitively hinder a client creating such namespace prefixes but would not fail if a file with such prefixes is read.

@hunterhacker

This comment has been minimized.

Show comment
Hide comment
@hunterhacker

hunterhacker Mar 14, 2014

Owner

Seems to me like the spec is written this way ("MUST NOT fail") so that when a new xmlfoo prefix comes out via the standards process, they want tools like JDOM to not reject it. So we should probably accept it, right? A warning or something would be nice, but there's no real vehicle for that that comes to mind.

Owner

hunterhacker commented Mar 14, 2014

Seems to me like the spec is written this way ("MUST NOT fail") so that when a new xmlfoo prefix comes out via the standards process, they want tools like JDOM to not reject it. So we should probably accept it, right? A warning or something would be nice, but there's no real vehicle for that that comes to mind.

@rolfl

This comment has been minimized.

Show comment
Hide comment
@rolfl

rolfl Mar 14, 2014

Collaborator

There is a vehicle for checking, or not checking the XML content as it is being loaded through a 'trusted' parser, but, even the unchecked version still will fail because the namespace will fail to be created.

I think the right solution here may be to just remove the checking, and document, document, and document it.

As soon as you say that JDOM should be able to load such files, it is only logical that it should be able to edit, and create them too. JDOM is about amking the possible things 'easy'.... but, this feels like a long enough piece of rope that it could backfire .... JDOM is not the only code that will fail with such things, surely? Then it will become JDOM's fault for letting the user create broken documents.... hmmm.... rock, and hard place.

Putting system-wide configuration options (like System properties, etc.) is not a viable solution, and Namespace class is a static one.

At this point in time we either change nothing (keep the fail), or change everything (not restrict anything). Those are the only two alternatives. I can't see a compromise. Am I missing something?

Collaborator

rolfl commented Mar 14, 2014

There is a vehicle for checking, or not checking the XML content as it is being loaded through a 'trusted' parser, but, even the unchecked version still will fail because the namespace will fail to be created.

I think the right solution here may be to just remove the checking, and document, document, and document it.

As soon as you say that JDOM should be able to load such files, it is only logical that it should be able to edit, and create them too. JDOM is about amking the possible things 'easy'.... but, this feels like a long enough piece of rope that it could backfire .... JDOM is not the only code that will fail with such things, surely? Then it will become JDOM's fault for letting the user create broken documents.... hmmm.... rock, and hard place.

Putting system-wide configuration options (like System properties, etc.) is not a viable solution, and Namespace class is a static one.

At this point in time we either change nothing (keep the fail), or change everything (not restrict anything). Those are the only two alternatives. I can't see a compromise. Am I missing something?

@hunterhacker

This comment has been minimized.

Show comment
Hide comment
@hunterhacker

hunterhacker Mar 14, 2014

Owner

The spec clearly says we have to let it pass, so we should do that, no restriction.

Owner

hunterhacker commented Mar 14, 2014

The spec clearly says we have to let it pass, so we should do that, no restriction.

@rolfl

This comment has been minimized.

Show comment
Hide comment
@rolfl

rolfl Mar 14, 2014

Collaborator

Right, I agree here... I think it is the consensus. I have some other items backlogged and will push them through 'real soon'.

Collaborator

rolfl commented Mar 14, 2014

Right, I agree here... I think it is the consensus. I have some other items backlogged and will push them through 'real soon'.

@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o Mar 14, 2014

I am not really familiar with JDOM but isn't is possible to control the creation of such namespace prefixes with a properties Map?

I am not really familiar with JDOM but isn't is possible to control the creation of such namespace prefixes with a properties Map?

@rolfl

This comment has been minimized.

Show comment
Hide comment
@rolfl

rolfl Mar 29, 2014

Collaborator

So, I am working on this right now. Question, from the specification: http://www.w3.org/TR/REC-xml-names/#xmlReserved

The prefix xml is by definition bound to the namespace name 
http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and 
MUST NOT be bound to any other namespace name. Other prefixes MUST NOT 
be bound to this namespace name, and it MUST NOT be declared as the default
 namespace.

The prefix xmlns is used only to declare namespace bindings and is by definition 
bound to the namespace name http://www.w3.org/2000/xmlns/. It MUST NOT be 
declared . Other prefixes MUST NOT be bound to this namespace name, and it 
MUST NOT be declared as the default namespace. Element names MUST NOT 
have the prefix xmlns.

All other prefixes beginning with the three-letter sequence x, m, l, in any case 
combination, are reserved. This means that:

 -   users SHOULD NOT use them except as defined by later specifications

 -   processors MUST NOT treat them as fatal errors.

Question, is the prefix 'XML' (uppercase), or 'XmL', or 'XmLnS' valid? (i.e. mixed case versions of the reserved prefixes)

I am working on the literal interpretation that Xml and XMLns, etc. are 'OK'

Collaborator

rolfl commented Mar 29, 2014

So, I am working on this right now. Question, from the specification: http://www.w3.org/TR/REC-xml-names/#xmlReserved

The prefix xml is by definition bound to the namespace name 
http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and 
MUST NOT be bound to any other namespace name. Other prefixes MUST NOT 
be bound to this namespace name, and it MUST NOT be declared as the default
 namespace.

The prefix xmlns is used only to declare namespace bindings and is by definition 
bound to the namespace name http://www.w3.org/2000/xmlns/. It MUST NOT be 
declared . Other prefixes MUST NOT be bound to this namespace name, and it 
MUST NOT be declared as the default namespace. Element names MUST NOT 
have the prefix xmlns.

All other prefixes beginning with the three-letter sequence x, m, l, in any case 
combination, are reserved. This means that:

 -   users SHOULD NOT use them except as defined by later specifications

 -   processors MUST NOT treat them as fatal errors.

Question, is the prefix 'XML' (uppercase), or 'XmL', or 'XmLnS' valid? (i.e. mixed case versions of the reserved prefixes)

I am working on the literal interpretation that Xml and XMLns, etc. are 'OK'

@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o Mar 30, 2014

The first two paragraphs do not strictly require case-insensitivity but see this (http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-name), defintion for Name.

The first two paragraphs do not strictly require case-insensitivity but see this (http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-name), defintion for Name.

@rolfl

This comment has been minimized.

Show comment
Hide comment
@rolfl

rolfl Mar 30, 2014

Collaborator

That name is somewhat different to the prefix, but it still holds some value. That name is for Element tag-names (what comes after the colon). Also, it seems to be OK to actually use 'xml' as the Element name, so I am not sure how it all applies.

The following document validates 'good' using xmllint on my linux box:

<xMl:xml xmlns:xMl="MyURI" xml="1"/>
Collaborator

rolfl commented Mar 30, 2014

That name is somewhat different to the prefix, but it still holds some value. That name is for Element tag-names (what comes after the colon). Also, it seems to be OK to actually use 'xml' as the Element name, so I am not sure how it all applies.

The following document validates 'good' using xmllint on my linux box:

<xMl:xml xmlns:xMl="MyURI" xml="1"/>
@michael-o

This comment has been minimized.

Show comment
Hide comment
@michael-o

michael-o Mar 30, 2014

Rolf, Name refers to xs:Name and a namespace prefix to xs:NCName. I think, you misunderstood me.

Element names are not discussed in this ticket, namespace prefixes only.

Rolf, Name refers to xs:Name and a namespace prefix to xs:NCName. I think, you misunderstood me.

Element names are not discussed in this ticket, namespace prefixes only.

@hunterhacker

This comment has been minimized.

Show comment
Hide comment
@hunterhacker

hunterhacker Mar 30, 2014

Owner

My reading is that we need to allow other character cases. They're reserved and people should not use them, but the spec says we're not allowed to treat them as fatal errors.

Owner

hunterhacker commented Mar 30, 2014

My reading is that we need to allow other character cases. They're reserved and people should not use them, but the spec says we're not allowed to treat them as fatal errors.

@rolfl

This comment has been minimized.

Show comment
Hide comment
@rolfl

rolfl Mar 30, 2014

Collaborator

OK, that's where I have things in the currently committed code here. It accepts:

<xMl:xml xmlns:xMl="MyURI" xml="1"/>

and I think that's OK, and it will stay that way. ;-) Just sorting out some merges, etc. Release 2.0.6 real soon now.

Collaborator

rolfl commented Mar 30, 2014

OK, that's where I have things in the currently committed code here. It accepts:

<xMl:xml xmlns:xMl="MyURI" xml="1"/>

and I think that's OK, and it will stay that way. ;-) Just sorting out some merges, etc. Release 2.0.6 real soon now.

rolfl added a commit that referenced this issue Apr 5, 2014

rolfl added a commit that referenced this issue Apr 5, 2014

@rolfl

This comment has been minimized.

Show comment
Hide comment
@rolfl

rolfl Apr 5, 2014

Collaborator

Code will now validate xml-prefixed values in any combinations of text/case, except the two prefixes 'xml' and 'xmlns' (both in lower case) which have special handling.

Collaborator

rolfl commented Apr 5, 2014

Code will now validate xml-prefixed values in any combinations of text/case, except the two prefixes 'xml' and 'xmlns' (both in lower case) which have special handling.

@rolfl rolfl closed this Apr 5, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment