Determine line ending style/proper Content-Length

[Greek2me]

When downloading plaintext using a TCPObject, the lines are received one at a time, causing any line endings that were there to be removed by Blockland. However, the Content-Length given by the server includes the line endings. This makes it difficult to determine where the end of the file is. For example, if the line endings are LF (\n), and I concatenate the lines with CRLF (\r\n), then the file is cut off early because \r\n is two bytes rather than one for \n.

Does anyone have ideas on how to work around this?

[Ad Bot]

[Subpixel]

Try adding a Content-Type: text/plain header to the request.

[Greek2me]

No effect.

edit: Solved my problem by using the ::onDisconnect callback to determine when the transfer completed. I'd previously been trying to use ::onDisconnected, which doesn't exist.

[Ipquarx]

Try downloading it as a binary file, replacing all \r with \r\n, then replacing all \n\n with blank.
Either that or somehow force the server to give a special end-of-file line of some sort.

Just realized you fixed it lol, nevermind

[Port]

Try downloading it as a binary file, replacing all \r with \r\n, then replacing all \n\n with blank.

How are you going to read the \r or \n values in the binary file into a single string where you can replace them?

[Ipquarx]

How are you going to read the \r or \n values in the binary file into a single string where you can replace them?

If it can be read into individual lines with TCPobjects then it can be read into a regular string just fine.

[Port]

If it can be read into individual lines with TCPobjects then it can be read into a regular string just fine.

How do you determine what character(s) to join each line with?

[Ipquarx]

How do you determine what character(s) to join each line with?

What're you even talking about? My solution is to normalize the line endings to \r\n no matter what they were before. The data won't have null bytes in it; it's just plain text.

[Port]

What're you even talking about? My solution is to normalize the line endings to \r\n no matter what they were before. The data won't have null bytes in it; it's just plain text.

You told OP to replace \r with \r\n and \n\n with nothing. How do you expect to read those escapes into a string? FileObjects will split them into nothingness.

[Ipquarx]

You told OP to replace \r with \r\n and \n\n with nothing. How do you expect to read those escapes into a string? FileObjects will split them into nothingness.

Good point. Nevermind then.