• Noticed a difference, is it between CentOS and Ubuntu or between GT.M a

    From ed de moel@21:1/5 to All on Sun May 8 15:43:06 2022
    I noticed an interesting difference...

    I have two systems up and running.
    The old one has CentOS, and is running GT.M V5.4-002B Linux x86_64
    The new one has Ubuntu and is running GT.M V6.3-011 Linux x86_64 (YottaDB r1.34)

    When I'm processing a multi-part payload from a POST request, on the "old" system, the line-ends come through as $Char(13,10), and on the new system they come through as $Char(13,0).
    Does anyone know if that difference is caused by Ubuntu or by YottaDB?
    Would this difference also impact image files that might be part of the multi-part POST?

    Thanks,
    Ed

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ed de moel@21:1/5 to All on Sun May 8 16:06:33 2022
    Oh yes, if it matters:
    The version of CentOS is: CentOS release 6.10 (Final)
    The version of Ubuntu is: Ubuntu 22.04 LTS

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From K.S. Bhaskar@21:1/5 to ed de moel on Mon May 9 08:00:25 2022
    On Sunday, May 8, 2022 at 7:06:34 PM UTC-4, ed de moel wrote:
    Oh yes, if it matters:
    The version of CentOS is: CentOS release 6.10 (Final)
    The version of Ubuntu is: Ubuntu 22.04 LTS

    Ed, is this a SOCKET device? Also, do you have a small example of the M code? There have been changes in both GT.M and YottaDB between those releases to accept CR+LF as line terminators in various contexts, not just LF. However, I am not aware of
    anything that converts CR+LF into CR+null.

    Regards
    – Bhaskar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ed de moel@21:1/5 to All on Mon May 9 08:10:45 2022
    This is a web application, in other words YottaDB is invoked with the socket invoked by a webpage as its standard in/output.
    The code just reads standard input with Read *byte as it is parsing the multi-part POST payload.

    If you need more detail, please let me know.
    Thanks.
    Ed

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam Habiel@21:1/5 to ed de moel on Mon May 9 12:55:37 2022
    On Monday, May 9, 2022 at 11:10:46 AM UTC-4, ed de moel wrote:
    This is a web application, in other words YottaDB is invoked with the socket invoked by a webpage as its standard in/output.
    The code just reads standard input with Read *byte as it is parsing the multi-part POST payload.

    If you need more detail, please let me know.
    Thanks.
    Ed
    Hey Ed,

    It's completely possible that YottaDB/GT.M "fixed" something with delimiters somewhere along the years, but a $C(0) showing up is really strange. Is your client sending the data still the same?

    I just noticed that you are reading standard input and output.

    For reference, here's what I did in the M-Web-Server to deal with delimiters: https://github.com/shabiel/M-Web-Server/blob/master/src/_webreq.m. I delimit by $C(13,10) while reading the HTTP headers, and then switch to no delimiters while reading the
    data.

    You said that you are using stdin/out. If so, you may find the code that is used here more useful, as it is invoked from xinetd: https://vivian.worldvista.org/dox/Routine_XWBTCPM_source.html

    Let us know how you fare.

    --Sam

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ed de moel@21:1/5 to All on Wed May 11 07:13:25 2022
    Thanks, Sam. The "nodelimiter" setting did the trick!

    Ed

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)