Unlimited strings are a problem. People will use it as storage.
replyNo, I'm not joking. We used to allow arbitrary paths in a cloud API I owned. Within about a month someone had figured out that the cost to store a single byte file was effectively zero, and they could encode arbitrary files into the paths of those things. It wasn't too long before there was a library to do it on Github. We had to put limits on it because otherwise people would store their data in the path, not the file.
I remember someone telling me that S3 used to be similarly abused - people were creating empty files and using S3 like a key-value store somehow, so AWS just jacked up the price of S3 head-object API call to push people back to DynamoDB or whatever.
replyJust include filename size in file size for billing purposes?
replyIn the fine print, only to be used against bad actors (w/guarantee that filenames under x chars would never be charged), or that too problematic? building good faith into policy + "hiding" info...
replyReason - to not overcomplicate or give appearance of nickel-and-diming
No, just charge for the amount of storage they use on your server. Not the amount of data you think you’re storing. In non-special cases these will be the same number.
replyWhat do you expect to happen when your cloud storage file path is 5000 characters long and your local filesystem only supports a maximum of 4096?
replyEverything needs limits otherwise someone will figure out how to or accidentally break it.
reply