Description: When a submission's "method" attribute is set to POST, the PUT method is actually performed instead. When a submissions "replace" attribute is set to "Instance", no change in instance data is occurred after receiving updated XML document from a Web server. The same XForms document is being processed correctly with OO/LO 3.3.0 and the same Web application. Steps to Reproduce: 1. Create or use attached XForms document. bug 1 2. Run a network packet sniffer (WireShark, etc) 3. Press the "Update" button in the document 4. See the intercepted HTTP request packet bug 2 2. Create web application having a method like this (RESTEasy example) @PUT @POST @Path("anydoctmp/{location}") @Consumes({MediaType.APPLICATION_XML}) @Produces(MediaType.TEXT_XML) public Response uploadDoc(@PathParam("location") String location, String doc) throws NamingException { System.out.println(doc); String result = doc.replaceAll("true", "false").replaceAll("41", "42"); System.out.println("_______________"+result); return Response.ok(result,MediaType.TEXT_XML).build(); } 3. Type "414141" in the edit box and press the "Update" button in the document 4. see the server console for debug Actual Results: Bug1: PUT Method is performed instead of POST. bug2: No changes in instance data has been made. Expected Results: bug1: The designed HTTP method should be performed bug2: edit box should change it's value to 424242. Please note this file is processed as designed in OpenOffice/LibreOffice 3.3.0. Reproducible: Always User Profile Reset: No Additional Info: XML Form submission via HTTP is broken since the version 3.3.0. my build is 85569322deea74ec9134968a29af2df5663baa21, version 7.4.4.2, 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux
Created attachment 184678 [details] test file to reproduce the bug
Created attachment 184680 [details] assertion + console logs On pc Debian x86-64 with master sources updated today, I got an assertion just when trying to open the file
Noel: assertion has been added just some days ago with 5fd2f0b93bd7d " use concrete class in Submission the code already relies on the underlying type of mxModel being Model rather than XModel " As I put in the file after bt, I also noticed in console: warn:xmloff:23364:23364:sax/source/fastparser/fastparser.cxx:1248: unknown attribute idtest=414141
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/27d76f145a9668999cc31c02b6f2712903e427db tdf#153039 submitting XML from XForms document It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel: thank you for having fixed the assertion. Now I can open the file. However, I still see: warn:xmloff:42257:42257:sax/source/fastparser/fastparser.cxx:1248: unknown attribute idtest=414141 When I click update, LO indicates: "The form contains invalid data. Do you still want to continue". In console logs, I see: warn:uui:42257:42257:uui/source/iahndl.cxx:227: replaceMessageWithArguments: No arguments passed! If I click "Yes" button, I got: "Could not establish Internet connection to 192.168.14.2:8080" and console logs: warn:ucb.ucp.webdav.curl:42257:42257:ucb/source/ucp/webdav-curl/CurlSession.cxx:958: curl_easy_perform failed: (7) Failed to connect to 192.168.14.2 port 8080 after 3 ms: Couldn't connect to server => reopen
Ah, sorry! I've left my document with the local address of my web server 192.168.14.2 in the submission property. This address is reachable inside my local network only. I will expose my web server to Internet in 3-5 hours and attach the new version of the XForms document such that everybody will be able to test it. I apologize for such an awkward situation! Please wait for my update! Thanks for you time!
Created attachment 184701 [details] updated XForms document with globally available address for submission Done. Please fill free to test the document just attached. My Web application is now publicly available. It changes (literally) "true" to "false" and "41" to "42" everywhere in an XML document it receives via POST/PUT methods. Hope it helps.
On pc Debian x86-64 with master sources updated today, I got this on console: warn:uui:1087062:1087062:uui/source/iahndl.cxx:227: replaceMessageWithArguments: No arguments passed! warn:forms.xforms:1087062:1087062:forms/source/xforms/submission/replace.cxx:103: Exception during replace com.sun.star.xml.dom.DOMException message: "at /home/julien/lo/libreoffice/unoxml/source/dom/node.cxx:821" Code: (com.sun.star.xml.dom.DOMExceptionType) HIERARCHY_REQUEST_ERR Code: (com.sun.star.xml.dom.DOMExceptionType) HIERARCHY_REQUEST_ERR bt part corresponding to the moment when there's a pb with gdb trace: Thread 1 "soffice.bin" hit Breakpoint 1, DOM::CDocument::IsChildTypeAllowed (this=0x561dff046560, nodeType=com::sun::star::xml::dom::NodeType::NodeType_ELEMENT_NODE) at unoxml/source/dom/document.cxx:302 302 return nullptr == lcl_getDocumentRootPtr(m_aDocPtr); (gdb) p lcl_getDocumentRootPtr(m_aDocPtr) $1 = (xmlNode *) 0x0 (gdb) c Continuing. [New Thread 0x7fe1f27fe6c0 (LWP 1088681)] [Thread 0x7fe1f27fe6c0 (LWP 1088681) exited] Thread 1 "soffice.bin" hit Breakpoint 1, DOM::CDocument::IsChildTypeAllowed (this=0x561dfc31d260, nodeType=com::sun::star::xml::dom::NodeType::NodeType_ELEMENT_NODE) at unoxml/source/dom/document.cxx:302 302 return nullptr == lcl_getDocumentRootPtr(m_aDocPtr); (gdb) p lcl_getDocumentRootPtr(m_aDocPtr) $2 = (xmlNode *) 0x561dfc3b4700 (gdb) bt #0 DOM::CDocument::IsChildTypeAllowed(com::sun::star::xml::dom::NodeType) (this=0x561dfc31d260, nodeType=com::sun::star::xml::dom::NodeType::NodeType_ELEMENT_NODE) at unoxml/source/dom/document.cxx:302 #1 0x00007fe1f1f5adfa in DOM::CNode::replaceChild(com::sun::star::uno::Reference<com::sun::star::xml::dom::XNode> const&, com::sun::star::uno::Reference<com::sun::star::xml::dom::XNode> const&) (this=0x561dfc31d260, xNewChild=uno::Reference to (DOM::CElement *) 0x561dfdd847b8, xOldChild=uno::Reference to (DOM::CElement *) 0x561dfc3dcbc8) at unoxml/source/dom/node.cxx:820 #2 0x00007fe1f1f73e63 in DOM::CDocument::replaceChild(com::sun::star::uno::Reference<com::sun::star::xml::dom::XNode> const&, com::sun::star::uno::Reference<com::sun::star::xml::dom::XNode> const&) (this=0x561dfc31d260, newChild=uno::Reference to (DOM::CElement *) 0x561dfdd847b8, oldChild=uno::Reference to (DOM::CElement *) 0x561dfc3dcbc8) at unoxml/source/dom/document.hxx:313 #3 0x00007fe1f1f74a97 in non-virtual thunk to DOM::CDocument::replaceChild(com::sun::star::uno::Reference<com::sun::star::xml::dom::XNode> const&, com::sun::star::uno::Reference<com::sun::star::xml::dom::XNode> const&) () at /home/julien/lo/libreoffice/instdir/program/../program/libunoxmllo.so #4 0x00007fe1d72559b8 in CSubmission::replace(std::basic_string_view<char16_t, std::char_traits<char16_t> >, com::sun::star::uno::Reference<com::sun::star::xml::dom::XDocument> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) (this=0x561dfee62440, aReplace=u"instance", aDocument=uno::Reference to (DOM::CDocument *) 0x561dfc31d2b8, aFrame=empty uno::Reference) at forms/source/xforms/submission/replace.cxx:89 #5 0x00007fe1d724c65a in xforms::Submission::doSubmit(com::sun::star::uno::Reference<com::sun::star::task::XInteractionHandler> const&) (this=0x561dfc3ab710, xHandler=uno::Reference to (svxform::FormController *) 0x561dfc5d1568) at forms/source/xforms/submission.cxx:251 #6 0x00007fe1d724de3a in xforms::Submission::submitWithInteraction(com::sun::star::uno::Reference<com::sun::star::task::XInteractionHandler> const&) (this=0x561dfc3ab710, _rxHandler=uno::Reference to (svxform::FormController *) 0x561dfc5d1568) at forms/source/xforms/submission.cxx:456 #7 0x00007fe1d6f2d81f in frm::OClickableImageBaseControl::implSubmit(com::sun::star::awt::MouseEvent const&, com::sun::star::uno::Reference<com::sun::star::task::XInteractionHandler> const&) (this=0x561dfda94c10, _rEvent=..., _rxHandler=uno::Reference to (svxform::FormController *) 0x561dfc5d1568) at forms/source/component/clickableimage.cxx:392 #8 0x00007fe1d6f2c25b in frm::OClickableImageBaseControl::actionPerformed_Impl(bool, com::sun::star::awt::MouseEvent const&) (this=0x561dfda94c10, bNotifyListener=false, rEvt=...) at forms/source/component/clickableimage.cxx:240 #9 0x00007fe1d6f09184 in frm::OButtonControl::actionPerformed_Impl(bool, com::sun::star::awt::MouseEvent const&) (this=0x561dfda94bf0, _bNotifyListener=false, _rEvt=...) at forms/source/component/Button.cxx:514 #10 0x00007fe1d6f08fb5 in frm::OButtonControl::OnClick(void*) (this=0x561dfda94bf0) at forms/source/component/Button.cxx:489 #11 0x00007fe1d6f087bd in frm::OButtonControl::LinkStubOnClick(void*, void*) (instance=0x561dfda94bf0, data=0x0) at forms/source/component/Button.cxx:440 #12 0x00007fe20d9d8b88 in Link<void*, void>::Call(void*) const (this=0x561dfd97cbc8, data=0x0) at include/tools/link.hxx:111 #13 0x00007fe20d9d4c39 in ImplHandleUserEvent(ImplSVEvent*) (pSVEvent=0x561dfd97cbc0) at vcl/source/window/winproc.cxx:2287 #14 0x00007fe20d9d1791 in ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) (_pWindow=0x561df903fd00, nEvent=SalEvent::UserEvent, pEvent=0x561dfd97cbc0) at vcl/source/window/winproc.cxx:2857 #15 0x00007fe20e638b20 in SalFrame::CallCallback(SalEvent, void const*) const (this=0x561df8f35660, nEvent=SalEvent::UserEvent, pEvent=0x561dfd97cbc0) at vcl/inc/salframe.hxx:306 #16 0x00007fe20e665b9f in SalGenericDisplay::ProcessEvent(SalUserEventList::SalUserEvent) (this=0x561df8ebcfa0, aEvent=...) at vcl/unx/generic/app/gendisp.cxx:66 #17 0x00007fe20e1545dd in SalUserEventList::DispatchUserEvents(bool)::$_0::operator()() const (this=0x7ffe239b60c0) at vcl/source/app/salusereventlist.cxx:119 #18 0x00007fe20e1544a4 in SalUserEventList::DispatchUserEvents(bool) (this=0x561df8ebcfa0, bHandleAllCurrentEvents=false) at vcl/source/app/salusereventlist.cxx:120 #19 0x00007fe20e665af5 in SalGenericDisplay::DispatchInternalEvent(bool) (this=0x561df8ebcfa0, bHandleAllCurrentEvent=false) at vcl/unx/generic/app/gendisp.cxx:51 #20 0x00007fe204d7a8c6 in call_userEventFn(void*) (data=0x561df7261360) at vcl/unx/gtk3/gtkdata.cxx:824 #21 0x00007fe20971c67f in g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #22 0x00007fe20971ca38 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x00007fe20971cacc in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x00007fe204d793df in GtkSalData::Yield(bool, bool) (this=0x561df7261360, bWait=true, bHandleAllCurrentEvents=false) at vcl/unx/gtk3/gtkdata.cxx:405 #25 0x00007fe204d7ecd3 in GtkInstance::DoYield(bool, bool) (this=0x561df7261210, bWait=true, bHandleAllCurrentEvents=false) at vcl/unx/gtk3/gtkinst.cxx:431 #26 0x00007fe20e233b3f in ImplYield(bool, bool) (i_bWait=true, i_bAllEvents=false) at vcl/source/app/svapp.cxx:475 #27 0x00007fe20e2334ab in Application::Yield() () at vcl/source/app/svapp.cxx:559 #28 0x00007fe20e23327f in Application::Execute() () at vcl/source/app/svapp.cxx:453 #29 0x00007fe21692b00b in desktop::Desktop::Main() (this=0x7ffe239b7e18) at desktop/source/app/app.cxx:1604 #30 0x00007fe20e256534 in ImplSVMain() () at vcl/source/app/svmain.cxx:203 #31 0x00007fe20e2581a9 in SVMain() () at vcl/source/app/svmain.cxx:235 #32 0x00007fe2169aaa63 in soffice_main() () at desktop/source/app/sofficemain.cxx:94 #33 0x0000561df716fa6d in sal_main () at desktop/source/app/main.c:51 #34 0x0000561df716fa47 in main (argc=3, argv=0x7ffe239b8028) at desktop/source/app/main.c:49 (gdb) Pavel: IMHO this bugtracker needs to be split since it quotes 2 different bugs. This one should concern "PUT Method is performed instead of POST". You can submit a brand new bugtracker concerning the bug 2. Now I must recognize I'm quite stuck and wonder whom to ping for this kind of bug.
No idea how to debug xml with LO=>uncc myself
commit c5db3b93ee1058bd20ebcde2e757b52b9a67b74a Author: Michael Stahl <mst@openoffice.org> Date: Thu Feb 10 16:45:02 2011 +0100 xmlfix3: unoxml: prevent invalid child-parent relationships: new method CNode::IsChildTypeAllowed(NodeType). use it in appendChild(), insertBefore(), replaceChild(). Seems to be blocking the replace action. Not sure exactly why.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9b9bc7461e0513e2bb493e7f00f800b2463751e1 tdf#153039 unoxml: replace root element of CDocument throws It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/261b1237532f431963358a7b4ac5fd1ad6e5d223 tdf#153039 ucb: webdav-curl: fix POST, which was actually doing PUT It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
wow, somebody is using XForms! both problems fixed on master
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/eb40bf437756d7f27fe08d039353b89251b5447f tdf#153039 unoxml: replace root element of CDocument throws It will be available in 7.5.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/f91be4463ee303b11ec4b60186e9fbec390f7f11 tdf#153039 unoxml: replace root element of CDocument throws It will be available in 7.4.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/1c8f766cb3251aafbc288e588c5a6273d000af11 tdf#153039 ucb: webdav-curl: fix POST, which was actually doing PUT It will be available in 7.5.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/6ce53d79c45ca97d5cd9ee0d841366701cb1082e tdf#153039 ucb: webdav-curl: fix POST, which was actually doing PUT It will be available in 7.4.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I confirm that both bugs have been fixed in master (win32). Still waiting for Linux builds. Thanks to all who participated!
Please check, did this patch cause the following bug. Now any attempt to alter instance (add an attribute, element etc) in data navigator causes crash with any XForms document, existing or new. It did not not occur in 7.4.4 release, before the current bug was reported. Normally it should open a dialog window with alteration details. Please tell me if I should open a new bug report for this. I tested the following builds: Version: 7.5.1.0.0+ (X86_64) / LibreOffice Community Build ID: 0a6e128ef6c5f3951873e28931f331591759ae5f CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded Version: 7.6.0.0.alpha0+ (x86) / LibreOffice Community Build ID: 7c15ffd4e3bf002c3d4edd758bb3af27b1f6a34e CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded Thank you!
as both described bugs are patched, I close this bugreport. I have opened another, https://bugs.documentfoundation.org/show_bug.cgi?id=153154 probably a side effect of patches made here.
7.4.5 was a hotfix release, updating target in status-whiteboard