9 ms·

fun 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 relea

fun 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 from this day on, nobody knows about limits on the standard and everything was up in the air, just so sites could work on IE4 and be broken on netscape. Thanks microsoft! I did some experiments to test the actual URL limit of IE. at the time it was around 4MB, but IE would still go over if you got creative with hostnames levels and odd schemas. -- quick edit: keep in mind, in 1993, the money from giving out free browsers where on the servers: netscape server vs microsoft IIS (just like today giving free browsers the money is on makig it easier to access YOUR content --e.g. default search, etc). Making your browser crash the competitor server mean that server was seen as lower quality. (Same thing with google deliberately crashing performance of firefox on their services today[0]) The point of microsoft making this change was to force netscape to update their server as they increase the URL limit arbitrarily to all IE users. [0] https://www.zdnet.com/article/former-mozilla-exec-google-has-sabotaged-firefox-for-years/ https://www.zdnet.com/article/former-mozilla-exec-google-has...

tgb 5y ago
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)
- bulletsvshumans 5y ago
  "At least" means more than or equal to. In other words, the 'least' it can be is 100 characters, with no upper bound.
  - tgb 5y ago
    Yes but "you must support up to 100 characters" also has no upper bound - supporting 200 characters also fits that requirement.
    - mypalmike 5y ago
      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?
      - devmor 5y ago
        "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.
        mypalmike 5y ago
        So you would pick an arbitrary upper limit based on your own notion of what is sane. Picking such a limit, you would still need to write the same error handling code for limits, but it would happen at maybe 200. And the next programmer who inherits your code looks at the spec and your code and has to guess "why 200"? And it becomes lore. Which is specifically worse than writing to the spec.
        devmor 5y ago
        The spec doesn't exist. It's undefined. "Must support up to 100" is not a limit, it's a lower bound.
    - bluefirebrand 5y ago
      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.
- lacksconfidence 5y ago
  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.
- lurkerasdfh8 5y ago
  You are welcome to try to find it. I just failed :(
- tomwojcik 5y ago
  Didn't you confuse 'at least' with 'at most'?
vlovich123 5y ago
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 think about what the world would look like today if you had browser vendors putting caps for desktop browsers based on what mobile could support. EDIT: For some limits. For other limits "up to" wording may be more appropriate & is still in use (e.g. storage).
- wccrawford 5y ago
  The URL can be up to 1024 characters. The browser must support at least 1024 character URLs. They're 2 sides of the same coin, but MS didn't actually rephrase the sentence properly. Their version would have every URL have at least 1024 characters in it. Any less than that, and the browser should reject the URL as invalid.
  - jfrunyon 5y ago
    It's a lot more likely that the commenter remembering something he read 28(!) years later didn't rephrase it properly.
  - lurkerasdfh8 5y ago
    > Any less than that, and the browser should reject the URL as invalid. lol. that would have been awesome. domain squatters would be running for the 1000 character names while crying about all the money they paid for three letters one :)
  - deleted 5y ago
    [deleted]
- simias 5y ago
  "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 transmitting it.
laurent92 5y ago
I was on a 12-person failed project, the kind of which you owe millions to the govt. We had a problem with the search, we couldn’t get performance. I told my boss: “See, they wrote ‘The old search responded in 2 seconds. The new search must take at least the same time.’ We could almost add a sleep(2000) before starting the search.” He went with it. They dealt to drop the requirement on the performance of the search on a “mutual agreement.”
- lostcolony 5y ago
  Ah yes. Checkbox Driven Development. AKA Monkey Paw Development, where you give exactly what was asked for; it remains surprisingly popular in the government and enterprise spaces.
  - toomuchtodo 5y ago
    Requirements are hard in dysfunctional organizations, or those with more stakeholders than capability and agility.
    - lostcolony 5y ago
      Requirements are hard upfront, period, to the point I'd say that any organization trying to set them upfront is dysfunctional, tautologically. Making all the decisions when you have the least amount of information is a Bad Idea.
      - sharken 5y ago
        Also, how long will it take to build and how much will it cost? :) This is where Agile ought to improve things, but then SAFE came along and we were back to square one.
      - kenniskrag 5y ago
        but there are some architectual significant requirements, which have to be known upfront.
ksec 5y ago
I remember there was a site / tools that fit the whole web page content within its URL. And it was precisely limited by this "standard" where every browser behaves differently.
jstrieb 5y ago
I spent some time looking at similar specs for more recent browsers, but wasn't able to find anything useful. This was for a proof-of-concept I made that stores entire web pages in URLs (creatively named "URL Pages") by base64-encoding them and putting them in the URL fragment (the part after the "#"). https://github.com/jstrieb/urlpages https://github.com/jstrieb/urlpages The URLs this thing generates get pretty damn big sometimes, since I never got around to implementing compression. I can confirm that massive URLs from pages with inline images do work, but probably take some not-so-optimized code paths because they make my computer's fans spin up. Click at your own peril: https://git.io/Jss7V https://git.io/Jss7V
- jfrunyon 5y ago
  Okay, but you can already store web pages in URLs. `data:text/html,<h1>Hi%20there!</h1>` You can even base64 encode them, if you want to.
  - jstrieb 5y ago
    This is true, but linking to data URIs no longer works. Many browsers block them for "security reasons." In Firefox, a link to that page is not clickable for me: https://git.io/JssFK https://git.io/JssFK From a convenience standpoint, it's also far less likely that a URL with an http: scheme will be blocked by a random web application than one with a data: scheme. For example it makes sharing on social media sites and chat applications more feasible.
- willcipriano 5y ago
  I made a service to store arbitrary files as URLs that is similar. The hard part is files that are too large, I can handle files up to 5mb if you click on them all via local storage. Compression helps a lot as making them base64 increases the size quite a bit. https://podje.li https://podje.li
  - prox 5y ago
    Could you make whole webpages just through urls? Such as they will completely portable? Portable being taken with a grain of sand ofc.
samstave 5y ago
https://i.imgur.com/tAAuIv7.jpg https://i.imgur.com/tAAuIv7.jpg
peder 5y ago
I've written a number of front-end projects that used URLs for state, and yes, lol, IE was a hard no for such efforts.
hinkley 5y ago
Didn't IE have buffer overflow attacks due both to long headers and long URLs? Talk about being hoisted on your own petard...

tgb 5y ago

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)

bulletsvshumans 5y ago
"At least" means more than or equal to. In other words, the 'least' it can be is 100 characters, with no upper bound.
- tgb 5y ago
  Yes but "you must support up to 100 characters" also has no upper bound - supporting 200 characters also fits that requirement.
  - mypalmike 5y ago
    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?
    - devmor 5y ago
      "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.
      - mypalmike 5y ago
        So you would pick an arbitrary upper limit based on your own notion of what is sane. Picking such a limit, you would still need to write the same error handling code for limits, but it would happen at maybe 200. And the next programmer who inherits your code looks at the spec and your code and has to guess "why 200"? And it becomes lore. Which is specifically worse than writing to the spec.
        devmor 5y ago
        The spec doesn't exist. It's undefined. "Must support up to 100" is not a limit, it's a lower bound.
  - bluefirebrand 5y ago
    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.
lacksconfidence 5y ago
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.
lurkerasdfh8 5y ago
You are welcome to try to find it. I just failed :(
tomwojcik 5y ago
Didn't you confuse 'at least' with 'at most'?

vlovich123 5y ago

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 think about what the world would look like today if you had browser vendors putting caps for desktop browsers based on what mobile could support. EDIT: For some limits. For other limits "up to" wording may be more appropriate & is still in use (e.g. storage).

wccrawford 5y ago
The URL can be up to 1024 characters. The browser must support at least 1024 character URLs. They're 2 sides of the same coin, but MS didn't actually rephrase the sentence properly. Their version would have every URL have at least 1024 characters in it. Any less than that, and the browser should reject the URL as invalid.
- jfrunyon 5y ago
  It's a lot more likely that the commenter remembering something he read 28(!) years later didn't rephrase it properly.
- lurkerasdfh8 5y ago
  > Any less than that, and the browser should reject the URL as invalid. lol. that would have been awesome. domain squatters would be running for the 1000 character names while crying about all the money they paid for three letters one :)
- deleted 5y ago
  [deleted]
simias 5y ago
"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 transmitting it.

laurent92 5y ago

I was on a 12-person failed project, the kind of which you owe millions to the govt. We had a problem with the search, we couldn’t get performance. I told my boss: “See, they wrote ‘The old search responded in 2 seconds. The new search must take at least the same time.’ We could almost add a sleep(2000) before starting the search.” He went with it. They dealt to drop the requirement on the performance of the search on a “mutual agreement.”

lostcolony 5y ago
Ah yes. Checkbox Driven Development. AKA Monkey Paw Development, where you give exactly what was asked for; it remains surprisingly popular in the government and enterprise spaces.
- toomuchtodo 5y ago
  Requirements are hard in dysfunctional organizations, or those with more stakeholders than capability and agility.
  - lostcolony 5y ago
    Requirements are hard upfront, period, to the point I'd say that any organization trying to set them upfront is dysfunctional, tautologically. Making all the decisions when you have the least amount of information is a Bad Idea.
    - sharken 5y ago
      Also, how long will it take to build and how much will it cost? :) This is where Agile ought to improve things, but then SAFE came along and we were back to square one.
    - kenniskrag 5y ago
      but there are some architectual significant requirements, which have to be known upfront.

ksec 5y ago

I remember there was a site / tools that fit the whole web page content within its URL. And it was precisely limited by this "standard" where every browser behaves differently.

jstrieb 5y ago

I spent some time looking at similar specs for more recent browsers, but wasn't able to find anything useful. This was for a proof-of-concept I made that stores entire web pages in URLs (creatively named "URL Pages") by base64-encoding them and putting them in the URL fragment (the part after the "#"). https://github.com/jstrieb/urlpages https://github.com/jstrieb/urlpages The URLs this thing generates get pretty damn big sometimes, since I never got around to implementing compression. I can confirm that massive URLs from pages with inline images do work, but probably take some not-so-optimized code paths because they make my computer's fans spin up. Click at your own peril: https://git.io/Jss7V https://git.io/Jss7V

jfrunyon 5y ago
Okay, but you can already store web pages in URLs. `data:text/html,<h1>Hi%20there!</h1>` You can even base64 encode them, if you want to.
- jstrieb 5y ago
  This is true, but linking to data URIs no longer works. Many browsers block them for "security reasons." In Firefox, a link to that page is not clickable for me: https://git.io/JssFK https://git.io/JssFK From a convenience standpoint, it's also far less likely that a URL with an http: scheme will be blocked by a random web application than one with a data: scheme. For example it makes sharing on social media sites and chat applications more feasible.
willcipriano 5y ago
I made a service to store arbitrary files as URLs that is similar. The hard part is files that are too large, I can handle files up to 5mb if you click on them all via local storage. Compression helps a lot as making them base64 increases the size quite a bit. https://podje.li https://podje.li
- prox 5y ago
  Could you make whole webpages just through urls? Such as they will completely portable? Portable being taken with a grain of sand ofc.

samstave 5y ago

https://i.imgur.com/tAAuIv7.jpg https://i.imgur.com/tAAuIv7.jpg

peder 5y ago

I've written a number of front-end projects that used URLs for state, and yes, lol, IE was a hard no for such efforts.

hinkley 5y ago

Didn't IE have buffer overflow attacks due both to long headers and long URLs? Talk about being hoisted on your own petard...