Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.

Radix IoT Website Mango 3 Documentation Website Mango 4 Documentation Website

Issue with "200 OK" http receiver epilogue


  • I have a new sensor I'm trying to test which utilizes a server based datalogger with forwarding via HTTP GET or POST. In order to properly acknowledge the GET, a specific epilogue must be received by the server in order to complete the transaction. I have set the epilogue up for an HTTP receiver using the directions in the help files, and confirmed that it is properly entered in the database using a PHPadmin tool. The issue is that whenever I actually send a GET operation to the HTTP receiver in Mango, it responds with the "200 OK" and 2 copies of the epilogue. Unfortunately, the sending server rejects this response although the first half of the double epilogue matches its requirement exactly (it says "check URL" expected "X" received "XX" where X is the epilogue and XX is the epilogue twice with no space between them). So far I have tested this in 1.12.0, 1.12.4, and 1.13.0 with the same result. It also appears if you use the httpds example in the "help" text (the resulting page shows an unconsumed key wrapped in two copies of the epilogue text although there is no prologue... I even tried putting in an empty field in the prologue to see if that killed the double epilogue with no luck).

    Any idea what might be causing this, and how to stop it? This will be a dealbreaker for this data source if I can't get it figured out.

    Thanks,
    Craig


  • This is a bug in the servlet (com.serotonin.mango.web.servlet.HttpDataSourceServlet).

            // Write the prologue
            response.getWriter().write(SystemSettingsDao.getValue(SystemSettingsDao.HTTPDS_EPILOGUE));
    
            for (String message : messages) {
                response.getWriter().write(message);
                response.getWriter().write("\r\n");
            }
    
            // Write the epilogue
            response.getWriter().write(SystemSettingsDao.getValue(SystemSettingsDao.HTTPDS_EPILOGUE));
    
    

    The first one, of course, should be HTTPDS_PROLOGUE. The fix for this has been submitted. Thanks for reporting this.


  • Thanks for the quick response Matthew... Looks like time to download the 64 bit Eclipse and JDK for my new laptop!

    Craig


  • OK, recompiled with the changes noted, and it worked with no issues (single EPILOGUE by just changing the variable name). I did run into a problem however with the way the remote database works. It seems that it needs two EPILOGUE messages available. One in response to a data transmission with consumed keys (for example "DATA RECEIVED OK"), and one response to an empty GET or POST (for example "READY FOR DATA") indicating I'm ready for the next message and the old data can be dropped. The problem is it incessantly sends old data thinking I didn't get it. Is there a straightforward way to do this second epilogue? (one for 200 OK and consumed keys, and one for 200 OK, and no keys sent). I'm not sure what else needs editing outside the servlet mentioned, but I'm working on figuring this out. Any clues would be greatly appreciated.

    This one is going to require its own data source eventually due to how the GET/POST is sent to avoid a ridiculous amount of parsing in a metadata source, but for now I'm just looking for a workaround.


  • Unfortunately, there is nothing conditional about the prologue/epilogue besides being there or not. It is a solution that covered requirements known at the time. I suggest looking into M2M2, in particular making a custom module that will behave exactly as you need, based upon the existing HTTP module.