search

turquoiseowl / i18n

Smart internationalization for ASP.NET
Other
556 stars 155 forks source link

Schemeless URLs not handled #185

Open gitsno opened 9 years ago

gitsno commented 9 years ago

A common way to handle URLs that may or may not use SSL is to use schemeless URLs, such as //github.com/en/test, which will be accessed by the browser as http://github.com/en/test or https://github.com/en/test depending on whether or not the current page is using http or https (see http://tools.ietf.org/html/rfc3986#section-4.2).

Unfortunately the UriBuilder that is used in a number of places in i18n does not currently support schemeless URLs (see http://www.beta.microsoft.com/VisualStudio/feedbackdetail/view/805324/uribuilder-does-not-recognize-schemeless-urls-bing-com). This causes i18n to ignore schemeless URLs when URLs are localized in ProcessOutgoing - they are caught in the System.UriFormatException catch block.

turquoiseowl commented 9 years ago

Interesting. I was hoping http://tools.ietf.org/html/rfc3986#section-4.2 would elaborate on this, but all its does is describe 'network-path reference' (which look like UNC paths). Is that right?

Out of interest, we're talking about coding href URLs on a page to another site but with the same scheme as the current page? I see why you would want this for the same site (i.e. relative path); not clear on why for a URL to a different site?

gitsno commented 9 years ago

You're right - ie. we're not concerned about URLs to external sites. I mostly added the issue because it is causing an exception that could either be avoided altogether or at least handled intentionally. And in our case we're not going to rewrite our URLs anyway, we're going to use

The paths look a bit like UNC, but they are really just regular URIs without a scheme (no http: or https:). It makes it much simpler to handle cases where you allow access to a site using http or https and don't want the browser throwing up warnings about assets loading insecurely. While it would mostly be an issue for external sites only, it will affect sites that have a few different URLs, for example, we have our main site and then a few other hosts for things like static content and APIs, so then we do need to use a full absolute URL.