encoding/xml: disallow attributes named xmlns:*
gopherbot opened this issue · 8 comments
gopherbot commented
by opennota:
The Encoder will add namespaced to the elements, even if there are the same namespaces in the parent element: http://play.golang.org/p/LDRJCxUJHX // Output: // <p xmlns="http://www.gribuser.ru/xml/fictionbook/2.0"; xmlns:l="http://www.w3.org/1999/xlink";><a xmlns="http://www.gribuser.ru/xml/fictionbook/2.0"; xmlns:xlink="http://www.w3.org/1999/xlink"; xlink:href="http://google.com";>google.com</a></p> I expect it to not repeat the namespaces: // <p xmlns="http://www.gribuser.ru/xml/fictionbook/2.0"; xmlns:l="http://www.w3.org/1999/xlink";><a l:href="http://google.com";>google.com</a></p>
ianlancetaylor commented
gopherbot commented
Output XML is correct and equivalent to input XML (thus idempotent transformation). And - unfortunately - larger. That said, as this issue does not result in incorrect and/or non-equivalent XML, I would suggest first fixing higher priority bugs that either produce incorrect and/or non-equivalent XML (or just break), such as #7535, #6800, #8068, #8535, #7113
rsc commented
It's not intended that you can even emit xmlns: attributes that way. The encoder does not know about them and may step on you (or vice versa). If you want to put the name space definition in an outer element, the easiest thing to do is to use it in an attribute on that element: http://play.golang.org/p/2-Y-CrhaP7, which will let the Encoder define it instead. The test program in the initial report may be just invalid for trying to define an attribute named xmlns:l. Perhaps we should disallow all attributes named xmlns:* in a future version of Go. Not for 1.4 though.
Labels changed: added release-go1.5, removed release-go1.4.
Status changed to Accepted.
bradfitz commented
CL is here 4 days ago: https://go-review.googlesource.com/#/c/12351/ but lacked the magic syntax, so this bug wasn't updated.
gopherbot commented
CL https://golang.org/cl/12351 mentions this issue.
gopherbot commented
CL https://golang.org/cl/12570 mentions this issue.