https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=44037

            Bug ID: 44037
           Summary: Koha::Util::XML::to_xml picks an arbitrary root
                    element for hashes with several keys
   Initiative type: ---
        Sponsorship ---
            status:
           Product: Koha
           Version: Main
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5 - low
         Component: Architecture, internals, and plumbing
          Assignee: [email protected]
          Reporter: [email protected]
        QA Contact: [email protected]
  Target Milestone: ---

Koha::Util::XML::to_xml (until bug 44034 Koha::REST::V1::to_xml) converts a
hashref to an XML document. It takes the first key of the hash as the root
element:

    my $root_key = ( keys %$json )[0];

An XML document has exactly one root, so a hash with more than one key cannot
be represented. Instead of failing, to_xml picks whichever key Perl happens to
return first, and silently drops the others. Because hash order is not stable,
the result can differ between runs.

This has been harmless so far because the callers (ISO18626 messages) always
pass a single-key hash. It becomes more relevant with bug 44035, which makes
the REST API encode structures with the codec for the negotiated response type.
A response rendered with render( openapi => $hash ) on a route that produces
application/xml goes through to_xml, and that includes error bodies such as {
error => '...', conflict => ... } or { errors => [...], status => 400 }.

Options:

1. Die if the hash does not have exactly one key. Simple and explicit, but an
error body on an XML route would turn into a 500.
2. Take an optional root element name, and wrap the whole hash in it. The REST
codec could pass a fixed root for responses (for example "response") when the
structure has several keys.
3. Keep the single-key behaviour and make a multi-key hash wrap itself under a
default root, so nothing is dropped.

I would like opinions, in particular on what shape an XML error response should
have.

-- 
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Reply via email to