6 ms·

In other words, start using the `//url.to/something-here/` shortcut and the world will be a better place. EDIT: Use `//` instead of `http://` http://` or `http

In other words, start using the `//url.to/something-here/` shortcut and the world will be a better place. EDIT: Use `//` instead of `http://` http://` or `https://` https://` and it will use whatever the protocol of the page being fetched is using. EDIT 2: Double check when you use the `//` shortcut that the website you are linking to supports HTTPS, some still don't and they don't redirect properly...

thezilch 14y ago
some still don't... Most still don't!
dudus 14y ago
IE7 and IE8 will download stylesheets that use protocol relative urls twice. http://stackoverflow.com/questions/4831741/can-i-change-all-my-http-links-to-just http://stackoverflow.com/questions/4831741/can-i-change-all-...
- deleted 14y ago
  [deleted]
- GauntletWizard 14y ago
  If this is a concern, you've made some very poor decisions.
  - Achshar 14y ago
    Like what? Supporting ie 7 & 8? Using relative urls?
    - BadCRC 14y ago
      like worrying about twice as many hits to stylesheets (which are typically static content)
      - btipling 14y ago
        It's cached by URL, so I would assume (but haven't tested) that a different protocol would be cached separately.
        ErrantX 14y ago
        From a security perspective it certainly should be.
  - gcr 14y ago
    What about large assets, like big splash images? Those can be quite a bandwidth hog. EDIT: from the post, IE8 only downloads stylesheets twice. Nevermind.
- Achshar 14y ago
  IE certainly has strangest of bugs.
- somesay 14y ago
  You really care about that? Well, relative URLs (and maybe using a basename meta tag) might be a workaround. But seriously, I wouldn't care about these Microsoft's bugs.
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
- acdha 14y ago
  But only for uncached resources - see Eric Lawrence's comment: “Internal to Trident, the download queue has “de-duplication” logic to help ensure that we don’t download a single resource multiple times in parallel. Until recently, that logic had a bug for certain resources (like CSS) wherein the schema-less URI would not be matched to the schema-specified URI and hence you’d end up with two parallel requests.” http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/#comment-2319 http://www.stevesouders.com/blog/2010/02/10/5a-missing-schem... You could use a resource loader if you really cared but with IE8 under 10% and dropping I'd recommend keeping your site clean and maintainable – anyone using IE8 at this point is used to the web being slow and ugly so something like this will be the least of their worries.
kmfrk 14y ago
A shame many linkification scripts won't support this in editors, though: //news.ycombinator.com/item?id=5514784. Does anyone have any experience writing regex for this?
- somesay 14y ago
  Just always use the https version then. There is nothing wrong in embedding https resources in http. `//` is just shorter and more flexible (e.g. you could switch of ssl if you want).
- tubbo 14y ago
  Agreed. I really wish iTerm would do this.
jgreen10 14y ago
Good thing Tim-Berners Lee put two slashes in there.
- stcredzero 14y ago
  Not only are even smart people sometimes wrong about stuff, they're wrong about when they're wrong about stuff.
- dnr 14y ago
  If there were zero or one slashes there, we could use urls starting with a colon for the same purpose.
somesay 14y ago
Hint: Local testing/loading of html files might require a local server then, since file:// is then used for resources, too, and this is rather problematic.
- stcredzero 14y ago
  You'll have to explain why local servers are problematic. More like file:// is.
  - somesay 14y ago
    Well, if you double-click on a html file on your computer, it will open that in your browser using file://. If you use the short `//example.com/foo.bar`, it is quite problematic. `//fonts.googleapis.com/css` becomes `file://fonts.googleapis.com/css` → doesn't work Additionally, JavaScript files might not load or work due to browsers' (security) limitations. Not sure about the exact details here.
    - stcredzero 14y ago
      Definitely sounds like file:// is problematic, then.
      - jtheory 14y ago
        Using a local server (instead of file:// access) would be a solution to that problem, not another problem. That's not great... A lot of folks get started editing HTML by downloading an existing page, editing it in some small way, and viewing the resulting page to see if it worked. This would break that approach.
        Hello71 14y ago
        Firefox saves all assets to a _files directory then fixes the URLs to point in there. If you really, really want to use //: busybox httpd -p 8080
jonny_eh 14y ago
Why not just use https:// https:// ? That way, if you load the file using file:// it will still work. Any downsides?
- jonknee 14y ago
  You will often need to dynamically generate all URLs depending on the current state of the page. A common example is an econmerce site where normal pages are HTTP, but things like the shopping cart and checkout are HTTPS. Your template will need to know to load resources as HTTPS when on a secure page. It's not the end of the world, but certainly annoying.
  - Cthulhu_ 14y ago
    And are there any considerations nowadays to not just run the whole site under HTTPS?
    - timmow 14y ago
      Many CDNs charge a lot (10x for all bandwidth, including non secure) for https. If you are fronting one of your sites with these, it is not economically viable to switch over.
rachelbythebay 14y ago
No, don't, unless you want bad things to happen when a whole bunch of corner cases start sprouting up. I did this for a while and ultimately gave up after seeing the error rate spike on my server. There are lots of people out there using stuff which just does not get the protocol-independent // scheme. I went back to doing either the whole thing (http[s]://host/path) or a relative thing (/path) but nothing in-between. http://rachelbythebay.com/w/2012/09/15/rel/ http://rachelbythebay.com/w/2012/09/15/rel/
- StavrosK 14y ago
  I disagree with your conclusion. The fewer sites this works with, the quicker developers will fix it. Supporting the wrong way is not the right thing to do.
  - carbocation 14y ago
    Your two viewpoints are reconcilable, I think. From the standpoint of the individual developer, you handle edge cases like this so you don't break your clients' experience. From the standpoint of the ecosystem, broken tools are bad, and they cause individual developers to have to handle more edge cases. If one individual developer doesn't handle these edge cases, their clients will just think they are bad. If all of the individual developers decided not to handle these edge cases in a coordinated fashion, sure, they could trigger a change. But I don't think that's how it happens in the real world. To look back on the days of IE6/IE7, most developers didn't just stop supporting these browsers and hope that their clients would stop using them; they supported the browsers until larger forces caused their clients to shift to newer browsers. Getting back to my original point, I think it's possible for each of you to have the viewpoints that you have, but also for rachelbythebay to say, "Sure, if I could coordinate with all other devs to stop handling broken edge cases at the same time, I would do that," and for you to say, "Sure, I can see how you would want to keep your job and handle edge cases until they are fixed upstream."
    - StavrosK 14y ago
      I half-agree with rachelbythebay's position, but, in my experience, users will definitely say "hey, this site doesn't work with your service", the developer investigates and fixes it. It'd also probably be worth it to just email the devs of the service, it'd probably get fixed a significant proportion of the time.
benjiweber 14y ago
Annoyingly there's an obnoxious popup on IE6 when doing this http://paulirish.com/2010/the-protocol-relative-url/ http://paulirish.com/2010/the-protocol-relative-url/ Not using protocol relative urls causes a great amount of pain. Unfortunately when you're building content for third party pages you need more graceful degradation than focus stealing dialogues.
- ck2 14y ago
  Unless you are supporting China, IE6 usage is below 1% in virtually all countries: https://news.ycombinator.com/item?id=5511627 https://news.ycombinator.com/item?id=5511627
- dorward 14y ago
  That article says the problem is with the way SSL is set up on the host in the example, not with scheme relative URIs.
- speleding 14y ago
  No, protocol relative URLS work fine in IE6. (The article you linked to doesn't say they don't)
buttscicles 14y ago
>and they don't redirect properly You can't redirect SSL > non-SSL without a browser warning though, right? Unless you get a cert, at which point you may as well put it to use.
speleding 14y ago
I agree that using protocol relative URLs is the way to go, but there is one particular situation to watch out for: if the user saves the page to disk and opens it again then // will become file:// and all relative links will be broken. So on something like an "invoice" page that the user is likely to want to save you may not want to do that (or use a piece of javascript to rewrite the links dynamically)
- lenkite 14y ago
  Egad! Yet another edge case to remember.

thezilch 14y ago

some still don't... Most still don't!

dudus 14y ago

IE7 and IE8 will download stylesheets that use protocol relative urls twice. http://stackoverflow.com/questions/4831741/can-i-change-all-my-http-links-to-just http://stackoverflow.com/questions/4831741/can-i-change-all-...

deleted 14y ago
[deleted]
GauntletWizard 14y ago
If this is a concern, you've made some very poor decisions.
- Achshar 14y ago
  Like what? Supporting ie 7 & 8? Using relative urls?
  - BadCRC 14y ago
    like worrying about twice as many hits to stylesheets (which are typically static content)
    - btipling 14y ago
      It's cached by URL, so I would assume (but haven't tested) that a different protocol would be cached separately.
      - ErrantX 14y ago
        From a security perspective it certainly should be.
- gcr 14y ago
  What about large assets, like big splash images? Those can be quite a bandwidth hog. EDIT: from the post, IE8 only downloads stylesheets twice. Nevermind.
Achshar 14y ago
IE certainly has strangest of bugs.
somesay 14y ago
You really care about that? Well, relative URLs (and maybe using a basename meta tag) might be a workaround. But seriously, I wouldn't care about these Microsoft's bugs.
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]
acdha 14y ago
But only for uncached resources - see Eric Lawrence's comment: “Internal to Trident, the download queue has “de-duplication” logic to help ensure that we don’t download a single resource multiple times in parallel. Until recently, that logic had a bug for certain resources (like CSS) wherein the schema-less URI would not be matched to the schema-specified URI and hence you’d end up with two parallel requests.” http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/#comment-2319 http://www.stevesouders.com/blog/2010/02/10/5a-missing-schem... You could use a resource loader if you really cared but with IE8 under 10% and dropping I'd recommend keeping your site clean and maintainable – anyone using IE8 at this point is used to the web being slow and ugly so something like this will be the least of their worries.

kmfrk 14y ago

A shame many linkification scripts won't support this in editors, though: //news.ycombinator.com/item?id=5514784. Does anyone have any experience writing regex for this?

somesay 14y ago
Just always use the https version then. There is nothing wrong in embedding https resources in http. `//` is just shorter and more flexible (e.g. you could switch of ssl if you want).
tubbo 14y ago
Agreed. I really wish iTerm would do this.

jgreen10 14y ago

Good thing Tim-Berners Lee put two slashes in there.

stcredzero 14y ago
Not only are even smart people sometimes wrong about stuff, they're wrong about when they're wrong about stuff.
dnr 14y ago
If there were zero or one slashes there, we could use urls starting with a colon for the same purpose.

somesay 14y ago

Hint: Local testing/loading of html files might require a local server then, since file:// is then used for resources, too, and this is rather problematic.

stcredzero 14y ago
You'll have to explain why local servers are problematic. More like file:// is.
- somesay 14y ago
  Well, if you double-click on a html file on your computer, it will open that in your browser using file://. If you use the short `//example.com/foo.bar`, it is quite problematic. `//fonts.googleapis.com/css` becomes `file://fonts.googleapis.com/css` → doesn't work Additionally, JavaScript files might not load or work due to browsers' (security) limitations. Not sure about the exact details here.
  - stcredzero 14y ago
    Definitely sounds like file:// is problematic, then.
    - jtheory 14y ago
      Using a local server (instead of file:// access) would be a solution to that problem, not another problem. That's not great... A lot of folks get started editing HTML by downloading an existing page, editing it in some small way, and viewing the resulting page to see if it worked. This would break that approach.
      - Hello71 14y ago
        Firefox saves all assets to a _files directory then fixes the URLs to point in there. If you really, really want to use //: busybox httpd -p 8080

jonny_eh 14y ago

Why not just use https:// https:// ? That way, if you load the file using file:// it will still work. Any downsides?

jonknee 14y ago
You will often need to dynamically generate all URLs depending on the current state of the page. A common example is an econmerce site where normal pages are HTTP, but things like the shopping cart and checkout are HTTPS. Your template will need to know to load resources as HTTPS when on a secure page. It's not the end of the world, but certainly annoying.
- Cthulhu_ 14y ago
  And are there any considerations nowadays to not just run the whole site under HTTPS?
  - timmow 14y ago
    Many CDNs charge a lot (10x for all bandwidth, including non secure) for https. If you are fronting one of your sites with these, it is not economically viable to switch over.

rachelbythebay 14y ago

No, don't, unless you want bad things to happen when a whole bunch of corner cases start sprouting up. I did this for a while and ultimately gave up after seeing the error rate spike on my server. There are lots of people out there using stuff which just does not get the protocol-independent // scheme. I went back to doing either the whole thing (http[s]://host/path) or a relative thing (/path) but nothing in-between. http://rachelbythebay.com/w/2012/09/15/rel/ http://rachelbythebay.com/w/2012/09/15/rel/

StavrosK 14y ago
I disagree with your conclusion. The fewer sites this works with, the quicker developers will fix it. Supporting the wrong way is not the right thing to do.
- carbocation 14y ago
  Your two viewpoints are reconcilable, I think. From the standpoint of the individual developer, you handle edge cases like this so you don't break your clients' experience. From the standpoint of the ecosystem, broken tools are bad, and they cause individual developers to have to handle more edge cases. If one individual developer doesn't handle these edge cases, their clients will just think they are bad. If all of the individual developers decided not to handle these edge cases in a coordinated fashion, sure, they could trigger a change. But I don't think that's how it happens in the real world. To look back on the days of IE6/IE7, most developers didn't just stop supporting these browsers and hope that their clients would stop using them; they supported the browsers until larger forces caused their clients to shift to newer browsers. Getting back to my original point, I think it's possible for each of you to have the viewpoints that you have, but also for rachelbythebay to say, "Sure, if I could coordinate with all other devs to stop handling broken edge cases at the same time, I would do that," and for you to say, "Sure, I can see how you would want to keep your job and handle edge cases until they are fixed upstream."
  - StavrosK 14y ago
    I half-agree with rachelbythebay's position, but, in my experience, users will definitely say "hey, this site doesn't work with your service", the developer investigates and fixes it. It'd also probably be worth it to just email the devs of the service, it'd probably get fixed a significant proportion of the time.

benjiweber 14y ago

Annoyingly there's an obnoxious popup on IE6 when doing this http://paulirish.com/2010/the-protocol-relative-url/ http://paulirish.com/2010/the-protocol-relative-url/ Not using protocol relative urls causes a great amount of pain. Unfortunately when you're building content for third party pages you need more graceful degradation than focus stealing dialogues.

ck2 14y ago
Unless you are supporting China, IE6 usage is below 1% in virtually all countries: https://news.ycombinator.com/item?id=5511627 https://news.ycombinator.com/item?id=5511627
dorward 14y ago
That article says the problem is with the way SSL is set up on the host in the example, not with scheme relative URIs.
speleding 14y ago
No, protocol relative URLS work fine in IE6. (The article you linked to doesn't say they don't)

buttscicles 14y ago

>and they don't redirect properly You can't redirect SSL > non-SSL without a browser warning though, right? Unless you get a cert, at which point you may as well put it to use.

speleding 14y ago

I agree that using protocol relative URLs is the way to go, but there is one particular situation to watch out for: if the user saves the page to disk and opens it again then // will become file:// and all relative links will be broken. So on something like an "invoice" page that the user is likely to want to save you may not want to do that (or use a piece of javascript to rewrite the links dynamically)

lenkite 14y ago
Egad! Yet another edge case to remember.