Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Protocol-Relative URLs to Fix Mixed-Content Warnings

autoref.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Protocol-Relative URLs to Fix Mixed-Content Warnings

#21

Post by justincormack »

rachelbythebay wrote: post #8

This isn't as simple as it sounds, particularly if you have something like an Atom feed. Putting an IMG SRC pointing at //example.com/foo.jpg in the HTML served as a regular web page will work fine for nearly everyone. However, putting that same construct in your feed will cause a nontrivial number of people to "GET //example.com/foo.jpg" from your web server. It's irritating. If you then change your feed to hard-cod…

And I thought people who used RSS were technically aware and wouldn't use broken clients. How about collecting user gent strings and filing bugs, or producing a test suite?

Re: Protocol-Relative URLs to Fix Mixed-Content Warnings

#22

Post by pronoiac »

bgmd wrote: post #11

The problem this DOESN'T solve is that if the resource is not availale over SSL, then this won't work at all and will show broken links. I've got a project that addresses this by converting any URL to SSL: http://www.fixweb.co/ Just take whatever URL you want to access, like http://example.com/test.gif add the FixWeb.co address in front of it like this: https://fixweb.co/example.com/test.gif ^^^^^^^^^^^^^^^^^^ and it…

Oh look, you just implemented an open proxy. Those are rather prone to abuse, aren't they?

Re: Protocol-Relative URLs to Fix Mixed-Content Warnings

#23

Post by nodata »

rachelbythebay wrote: post #8

This isn't as simple as it sounds, particularly if you have something like an Atom feed. Putting an IMG SRC pointing at //example.com/foo.jpg in the HTML served as a regular web page will work fine for nearly everyone. However, putting that same construct in your feed will cause a nontrivial number of people to "GET //example.com/foo.jpg" from your web server. It's irritating. If you then change your feed to hard-cod…

What happened to and src="/path/to/asset"?

Re: Protocol-Relative URLs to Fix Mixed-Content Warnings

#24

Post by jbrechtel »

bgmd wrote: post #11

The problem this DOESN'T solve is that if the resource is not availale over SSL, then this won't work at all and will show broken links. I've got a project that addresses this by converting any URL to SSL: http://www.fixweb.co/ Just take whatever URL you want to access, like http://example.com/test.gif add the FixWeb.co address in front of it like this: https://fixweb.co/example.com/test.gif ^^^^^^^^^^^^^^^^^^ and it…

When would someone use this? If my content isn't available over HTTPS already then it's likely due to not wanting to support the load...in which case I'm not going to assume yours will handle it.

Or do you see this as more of an end user fix via a MITM proxy or something? Even then that sounds contrived.

What am I missing?

Re: Protocol-Relative URLs to Fix Mixed-Content Warnings

#25

Post by rimantas »

fotbr wrote: post #18
RKearney wrote: post #13

Earlier quoted context omitted.

No no no! Unless you absolutely need your content encrypted, all this does is add unnecessary latency to your site for the SSL handshakes. If your site hosts zero external content, and all of your content is hosted from the same domain, this wouldn't be as big of an issue. However, most sites host content from 4-5 different domains, which means you're going to have 4-5 different SSL handshakes, thus resulting in a mu…

If you're constantly pulling content from 4-5 different domains, perhaps you should re-think your sites architecture to minimize that. Sometimes it's unavoidable, but a lot of the time it's simply due to laziness or because the web developers are practicing the cargo-cult method of development. Yes, this means you probably need to re-evaluate whether your "like/share/connect/plusone this" really needs to be on every…

  > If you're constantly pulling content from 4-5 different
  > domains, perhaps you should re-think your sites
  > architecture to minimize that.
And if you are not you may be interested in doing that — browsers have limited number of connections per domain so splitting your assets across 2-4 domains allows to download more resources in parallel.

http://developer.yahoo.com/performance/rules.html#split

Re: Protocol-Relative URLs to Fix Mixed-Content Warnings

#26

Post by fotbr »

rimantas wrote: post #25
fotbr wrote: post #18

Earlier quoted context omitted.

If you're constantly pulling content from 4-5 different domains, perhaps you should re-think your sites architecture to minimize that. Sometimes it's unavoidable, but a lot of the time it's simply due to laziness or because the web developers are practicing the cargo-cult method of development. Yes, this means you probably need to re-evaluate whether your "like/share/connect/plusone this" really needs to be on every…

> If you're constantly pulling content from 4-5 different > domains, perhaps you should re-think your sites > architecture to minimize that. And if you are not you may be interested in doing that — browsers have limited number of connections per domain so splitting your assets across 2-4 domains allows to download more resources in parallel. http://developer.yahoo.com/performance/rules.html#split

Or, simplify your pages. The current direction of web development and design -- having hundreds or even thousands (yes, thousands) of assets in a single page is often counter productive, and borderline stupid.
Post reply on HN