SoylentNews is people
SoylentNews
The "testing" is over. Twitter has officially raised the character limit to 280:
Avid tweeters such as President Trump were often forced to send multiple tweets to express their thoughts on a single subject given the constrictions of the previous limit.
Twitter explained after testing the 280-character limit that "people needed to use more than 140 characters, they Tweeted more easily and more often."
The company also preemptively addressed concerns that the structure of Twitter would change from the new character limit. "We – and many of you – were concerned that timelines may fill up with 280 character Tweets, and people with the new limit would always use up the whole space. But that didn't happen," Twitter said. "As a result, your timeline reading experience should not substantially change, you'll still see about the same amount of Tweets in your timeline."
Twitter said that the new character limit won't be accessible to Japanese, Korean or Chinese-language tweets.
Two German Twitter users managed to boldly break the limit by adding a massive URL:
Over the weekend, two German Twitter users successfully broke the existing character limit by sending a 35,000-character tweet. By formatting a message as a URL with extensive gibberish, they were able to absurdly pollute followers' timelines. Twitter soon removed it, but for a moment, all the complaints about the length of 280-character tweets seemed insignificant in the face of such a monster.
(Score: 3, Interesting) by tibman on Wednesday November 08 2017, @03:20AM (2 children)
You can make an a href with a million character long URL. But when the browser tries to navigate there it'll truncate everything after some arbitrary amount. I've seen the issue pop up in random places. Like people putting dynamic filtering options for a report on the end of the URL (standard url parameters) for an HTTP GET. It'll truncate and the site will die just trying to parse the malformed options. Converting it into an HTTP POST and moving the data payload off the URL is an easy solution. Buffer overflows aren't really a concern unless your back-end is C++ or something *shudders*. "Web languages" are usually memory managed and exception handling is A+ because the web is a freaky hostile place where anyone can feed anything they want into your program's inputs.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by coolgopher on Wednesday November 08 2017, @03:52AM
Yes, rather than a SIGSEGV your backend dies from a SIGKILL the oom killer... ;)
(Score: 2) by c0lo on Wednesday November 08 2017, @03:57AM
Please don't forget that it is not only the browsers that make requests and receive responses over HTTP and the payloads returned by an HTTP response is not bound to be only an HTML page (if not earlier, this started to happen since 1998 [wikipedia.org]).
Which means: the browser is not something that is mandatory to exist.
Therefore, you HTTP Server or (server-side) Web application must be able to handle longer URL-es than a Web browser would ever would; and the RFC is clear: extremely long URL must be handled gracefully (honor those that it supposed to be valid, return HTTP Status code 415 in case it won;t).
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford