WebUploadedFile Trouble - trailing line added - XML trouble

Hi there,
as a XOJO newbie i am learning every day a lot.
Actually i am trying to convert a WebUploadedFile to an XMLDocument.
It is a quite hard way.
After hours of testing i found out, that the WebuploadedFile adds an unwanted line to the file:

-----------------------------140999325229629658992955415–
are the two last rows when saving.
the closing tag is the wanted last row - and the last row in the original file.
that led me to an xml.error 9.
Also it seams that the XMLDocument dislikes <!DOCTYPE … definitions.
having these in the file leads to a xml.error 4

Any ideas on getting rid of these two problems?
Is there a way to manipulate the File? Or do i have to write it back to disk, reread it as textfile, amend, write and reread?

Any hints are welcome!

Sven

i would expect that data and size is the original selected file.
before 2021r1 WebuploadedFile was unusable under certain circumstances.

I’m seeing this too - here’s a hex dump of the original file (top) and uploaded file (bottom):

Submitted as <https://xojo.com/issue/64352>

I didn’t notice this before, because with some file types, extra junk at the end is simply ignored. But in other file types, these extra bytes corrupt the file.

1 Like

Here’s a hack you can use to clean up the extra garbage at the end of the file. It may not work in every case, but it seems to work in my limited testing with Safari, Chrome, and FireFox:

Private Function CleanUploadData(data as string) As string

  // see https://forum.xojo.com/t/webuploadedfile-trouble-trailing-line-added-xml-trouble/62564/3
  // remove garbage at end of file from WebFileUploader in Xojo 2021R1
  
  // it's a leftover mime-multipart separator
  //  format is always
  // 0D0A2D2D[...]2D2D[WebKitFormBoundaryXXXX or just random integer]2D2D0D0A
  
  // examples:
  // -----------------------------416884627533806944232202863060--
  // ------WebKitFormBoundaryIecXIus2umVD7p2U--
  
  dim mb as MemoryBlock = data  // convert string to memoryblock
  
  dim u as integer = mb.Size -1
  dim x as integer = u
  
  dim minX as integer = max(0, u - 256) // don't scan before first byte of file, and only check the last 256 bytes
  
  if _
    mb.StringValue(x-3,1) = "-" and _
    mb.StringValue(x-2,1) = "-" and _
    mb.StringValue(x-1,1) = chr(&h0D) and _
    mb.StringValue(x-0,1) = chr(&h0A) then
    
    
    // ending matches, backtrack now to find start of boundary string
    x = u - 4
    
    while mb.StringValue(x,1) <> "-" and x > minX
      x = x -1
    wend
    
    // backtrack to find start of "-"
    while mb.StringValue(x,1) = "-" and x > minX
      x = x -1
    wend
    
    if x <= minX then
      app.Log "*** UploadHack: found end bytes but did not find start tag within 256 bytes of end of file"
      return data
    end if
    
    dim junk as string = mb.StringValue(x, u-x+1)
    
    app.Log "* UploadHack: extra bytes removed: '" + junk + "'" 
    
    data = mb.StringValue(0,x-1)
    
    
    
  end if
  
  return data
End Function

Hi Mike,
thanks for the qucik response and the feedback to XOJO for the bug.
Also, your solving approach. VEry good to know, that binarystreams could be manipulated as a long string.
With an amended hack i was also able to remove the DOCTYPE definitions. So onwards to the net hurdle.
Once again, your valuable response is much appreciated and educative!

@Greg_O_Lone tagging this to make sure you see it, hoping it can get fixed in the next build?

1 Like