Meh... These links could be longer... can we get a URL Lengthener Lengthener?
A URL Lengthener
aaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.com
111–120 of 313 posts
Re: A URL Lengthener
#112I don’t know why but just seeing this title made spontaneously start laughing.
Same here. Amazing artistic stuff.
Re: A URL Lengthener
#113Earlier quoted context omitted.
"At least" means more than or equal to. In other words, the 'least' it can be is 100 characters, with no upper bound.
Yes but "you must support up to 100 characters" also has no upper bound - supporting 200 characters also fits that requirement.
I can see where you're coming from, it does read like "MUST support up to 100 characters (and MAY support more of you choose).
But honestly I think it's a bad practice to build the "may" part, because it's not explicit. The person who wrote the spec just as easily could have intended it to be "MUST support up to 100 (and may not go over 100)". So by not setting a bound you're gambling with your implementation being rejected, but setting a bound at 100 satisfies both possible "implied clauses" of the requirement and should not be rejected.
Re: A URL Lengthener
#114haha nice! I built the exact opposite the shortest possible URL shortener :) https://t.ly/
For many years (but no longer) Vince Cate's Offshore Information Services had a DNS A record for the ccTLD "ai", so that http://ai/ was a valid URL that worked in browsers. (A few people also had e-mail addresses @ai.) Today, there are no longer any TLDs of any kind with their own A records. https://www.internic.net/domain/root.zone
There's also https://www.dj/
Re: A URL Lengthener
#115Earlier quoted context omitted.
Yes but "you must support up to 100 characters" also has no upper bound - supporting 200 characters also fits that requirement.
So if you were a programmer on a project and you were given a spec that says "up to 100", you would just make it unbounded, and for all intents and purposes completely ignore the spec?
"Must" and "Must Not" are keywords in formal spec. If it says "Must support up to 100" and doesn't say "Must Not support over 100" then I would consider the upper limit to be whatever limit is sane for the data type.
Re: A URL Lengthener
#116fun fact. in the browser wars of 1993(?) i looked at the specs from netscape (mozilla dady for the young folks) and microsoft (what w3c? ha!) and netscape release a browser spec that said "X must support up to Y", as in "url must be up to 1024 chars", "cookies must be up to 1mb", etc... then microsoft release IE4 (or 6?) web spec. It was literally a copy of netscape's but with "up to" replaced with "at least". and fr…
Do you happen to have the exact wording? As far as I can tell these mean the same thing. 1. "You must support URL length up to 100 characters" -> your browser must support URLs that are 100 characters or less (and may or may not support longer ones) 2. "Your supported URL length must be at least 100 character" -> You must support URLs that are 100 characters or less (and may or may not support longer ones)
I don't know the exact wording, a gracious reading might be (as directed at people writing html)
1. Never use a URL longer than 100 characters
2. Go ahead and use a URL longer than 100 characters
As for the true intent? I've no clue.
Re: A URL Lengthener
#117A handy link to this discussion: https://aaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...
I clicked on your link, half expecting to get rick-rolled, and was pleasantly surprised to find myself back on this same page.... but also kinda disappointed. :)
+1 for avoiding the temptation.
Re: A URL Lengthener
#118Earlier quoted context omitted.
I don't know. There's a lot of problems but to me "at least" sounds like a more helpful phrasing. Browsers run in such heterogeneous compute environments (even back then) that "up to" basically cripples you to the lowest common denominator of all platforms you target. "At least" makes it mostly the HW vendors problem. Sure, MS was encountering this problem more because Windows ran on such a large range of HW but thin…
"At least" seems like a very good way of introducing a DoS vector. I think that 1024 was probably too short as a limit, but I think that it does make sense to impose an arbitrary upper bound to reject malformed requests early. I don't see what you mean by "the HW vendor's problem", I can assure you that any browser in existence is going to have an issue if you send a 1TB URL, while the NIC will have no issue transmit…
You are correct, but microsoft must https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...