You're absolutely right, sorry, I didn't notice that this had been back ported to 9.2. Definitely worth a try.

AyeJayUU said I take that back.  The content is fine when got with curl.  It does seem to be UHTTP that is adding extra bytes (as well as losing spaces at the end of the contents buffers).  I am begining to think it is not fit for this purpose.  I'm looking for alternatives.  URLMON maybe Hi, yes unfortunately we are on U9.2.  The problem chars are in the content returned and yes they seem to be OK when viewed in a browser.  I'm still playing with using filedump/load to make it readable by xmlload Cheers No problem, I assume no news is good news What version of Uniface are you using? The spaces being trimmed sounds like bug 28470: "UHTTP.SEND truncates trailing spaces at the end of its 10239-byte data buffer". This was fixed in 9.4.01 with the R101 patch. I realise your issue relates to read_content, but I'm sure I've seen a similar issue around this. Could the apostrophe issue be to do with what the server is returning? What happens if you download the same thing using a browser and then look at it in XML Spy? Generally speaking apostrophes should be escaped to ' in an XML document.  Thie corruption of content is a known issue Bug: 29848 - UHTTP: Data is not correctly encoded when setting $SYS_CHARSET=UTF8So I can fix that at least.  I just need to figure out the lost space chars at the end of the content buffer - looks like that is also available as a patch for U9203

AyeJayUU said I take that back.  The content is fine when got with curl.  It does seem to be UHTTP that is adding extra bytes (as well as losing spaces at the end of the contents buffers).  I am begining to think it is not fit for this purpose.  I'm looking for alternatives.  URLMON maybe Hi, yes unfortunately we are on U9.2.  The problem chars are in the content returned and yes they seem to be OK when viewed in a browser.  I'm still playing with using filedump/load to make it readable by xmlload Cheers No problem, I assume no news is good news What version of Uniface are you using? The spaces being trimmed sounds like bug 28470: "UHTTP.SEND truncates trailing spaces at the end of its 10239-byte data buffer". This was fixed in 9.4.01 with the R101 patch. I realise your issue relates to read_content, but I'm sure I've seen a similar issue around this. Could the apostrophe issue be to do with what the server is returning? What happens if you download the same thing using a browser and then look at it in XML Spy? Generally speaking apostrophes should be escaped to ' in an XML document.

  Thie corruption of content is a known issue

Bug: 29848 - UHTTP: Data is not correctly encoded when setting $SYS_CHARSET=UTF8

So I can fix that at least.  I just need to figure out the lost space chars at the end of the content buffer

I take that back.  The content is fine when got with curl.  It does seem to be UHTTP that is adding extra bytes (as well as losing spaces at the end of the contents buffers).  I am begining to think it is not fit for this purpose.  I'm looking for alternatives.  URLMON maybe Hi, yes unfortunately we are on U9.2.  The problem chars are in the content returned and yes they seem to be OK when viewed in a browser.  I'm still playing with using filedump/load to make it readable by xmlload Cheers No problem, I assume no news is good news What version of Uniface are you using? The spaces being trimmed sounds like bug 28470: "UHTTP.SEND truncates trailing spaces at the end of its 10239-byte data buffer". This was fixed in 9.4.01 with the R101 patch. I realise your issue relates to read_content, but I'm sure I've seen a similar issue around this. Could the apostrophe issue be to do with what the server is returning? What happens if you download the same thing using a browser and then look at it in XML Spy? Generally speaking apostrophes should be escaped to ' in an XML document.

Hi, yes unfortunately we are on U9.2.  The problem chars are in the content returned and yes they seem to be OK when viewed in a browser.  I'm still playing with using filedump/load to make it readable by xmlload Cheers No problem, I assume no news is good news What version of Uniface are you using? The spaces being trimmed sounds like bug 28470: "UHTTP.SEND truncates trailing spaces at the end of its 10239-byte data buffer". This was fixed in 9.4.01 with the R101 patch. I realise your issue relates to read_content, but I'm sure I've seen a similar issue around this. Could the apostrophe issue be to do with what the server is returning? What happens if you download the same thing using a browser and then look at it in XML Spy? Generally speaking apostrophes should be escaped to ' in an XML document.

No problem, I assume no news is good news What version of Uniface are you using? The spaces being trimmed sounds like bug 28470: "UHTTP.SEND truncates trailing spaces at the end of its 10239-byte data buffer". This was fixed in 9.4.01 with the R101 patch. I realise your issue relates to read_content, but I'm sure I've seen a similar issue around this. Could the apostrophe issue be to do with what the server is returning? What happens if you download the same thing using a browser and then look at it in XML Spy? Generally speaking apostrophes should be escaped to ' in an XML document.

Hi, Uli, James.

I got the send to work but didn't post a solution as I think it was a local issue rather than universally enlightning

I thought everything was plain sailing but now I am finding issues with how UHTTP is handling the buffer from the READ_CONTENT. I am losing <space> characters when they occur at the end of one buffer or the begining of another.

I am also finding that the XML I am getting back sometimes contains unprintable characters.  XML Spy tells me that "Character #xDBC0 is grammatically unexpected" and this seems to be where an apostrophe ought to be e.g. "Master's"

I haven't been able to figure out yet what to search for to replace it - luckily doing a filedump/load specifying UTF-8 gets rid of it. !

Thanks,

Andrew

James Rodger said Hi AyeJay, Have you had any luck with this? I wouldn't expect write_content to show any activity in Wireshark, all it's doing is appending the data to UHTTP's internal buffer. Everything written to the buffer is then sent when you call the send operation. Could you post the code you're using? That might help track down any issues. Regards, James

in the 9.6.04 ulibrary I found on the "what's new in 9.5" page a hint: The UHTTP component operations READ_CONTENT, SEND, and WRITE_CONTENT now support a maximum of 10 MB for their Content parameter. Sure, this limitation should be present on any of the help pages for READ_CONTENT, SEND, and WRITE_CONTENT .

Hi AyeJay, Have you had any luck with this? I wouldn't expect write_content to show any activity in Wireshark, all it's doing is appending the data to UHTTP's internal buffer. Everything written to the buffer is then sent when you call the send operation. Could you post the code you're using? That might help track down any issues. Regards, James

in the 9.6.04 ulibrary I found on the "what's new in 9.5" page a hint: The UHTTP component operations READ_CONTENT, SEND, and WRITE_CONTENT now support a maximum of 10 MB for their Content parameter. Sure, this limitation should be present on any of the help pages for READ_CONTENT, SEND, and WRITE_CONTENT .

AyeJayUU said Hi, I am really struggling to get UHTTP.SEND to work once my content starts exceeding the 10239 byte limit. I know that I should use the WRITE_CONTENT method prior to the SEND but it doesn't seem to make any difference. The WRITE_CONTENT is not generating any $status or messages and doesn't seem to do anything at all according to Wireshark Does anyone have any advice or examples as to how I can make this work or at least analyse the issue in more detail. Many thanks

I think there must be a limit to the size of data that I can pass to WRTE_CONTENT (though it would be nice if there was an explicit mention of this in the documentation)