Bug 1423017
| Summary: | configchannel.createOrUpdatePath() strips the return line '\n' character from the end of the file | ||
|---|---|---|---|
| Product: | Red Hat Satellite 5 | Reporter: | Marcelo Moreira de Mello <mmello> |
| Component: | API | Assignee: | Grant Gainey <ggainey> |
| Status: | CLOSED NOTABUG | QA Contact: | Red Hat Satellite QA List <satqe-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 570 | CC: | ggainey, lhellebr, mmello |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-05-09 14:34:32 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1358815 | ||
|
Description
Marcelo Moreira de Mello
2017-02-16 21:14:52 UTC
Attaching a debugger to ConfigChannelHandler.createOrUpdatePath(), and re-running the reproducer, shows me that data['contents'] has already had its trailing newlines stripped. Backing up the stack a ways, XmlRpcServlet.service() request.request.coyoteRequest.inputBuffer.bodyBuff, shows the newlines are *still there*. So - the newlines get to the backend correctly, and whatever is removing them happens well before the specific handler gets called. Investigation continues. See the XMLRPC spec : https://www.w3.org/2008/xmlsec/Drafts/xml-norm/Overview.html Search on "TrimTextNodes" : === TrimTextNodes of type boolean, defaulting to true Whether to trim (i.e. remove leading and trailing whitespace) all text nodes while normalizing. Adjacent text nodes must be coalesced prior to trimming. If an element has an xml:space="preserve" attribute, then text node descendants of that element are not trimmed regardless the value of this parameter. === I expect we're seeing the default behavior of XMLRPC here. *** Bug 1441590 has been marked as a duplicate of this bug. *** As noted in #c5 this is redstone-xmlrpc doing its job. If whitespace is *really important*, you need to deal with the file as binary instead of text, to keep redstone's grubby paws off of it. |