Marc, In the "SPGetCurrentSite" function's documentation, it states the function will return the complete site URL.
I noticed in the lated release (2014.01), the "SPGetCurrentSite" function returns the string from "currentContext.thisSite" (if available). That result is a relative URL, stripping the protocol and domain from the front end. i.e., returns "/sites/path/subpath" instead of "https://mydomain/sites/path/subpath" (at least it does so in IE and SP 2007). It's not a huge deal unless the user's code is doing a full text comparison of that string and is expecting the full URL (as was my case in a particular instance--which is how I discovered this).
I noticed the code will defer to a web service call (WebUrlFromPageUrl) to get the URL if "currentContext.thisSite" isn't available. The web service returns the complete site URL. So, in this function, the two methods will return the string to the user differently depending on the method the function uses. That may cause some confusion in the long run.
Thanks,
Geoff
I noticed in the lated release (2014.01), the "SPGetCurrentSite" function returns the string from "currentContext.thisSite" (if available). That result is a relative URL, stripping the protocol and domain from the front end. i.e., returns "/sites/path/subpath" instead of "https://mydomain/sites/path/subpath" (at least it does so in IE and SP 2007). It's not a huge deal unless the user's code is doing a full text comparison of that string and is expecting the full URL (as was my case in a particular instance--which is how I discovered this).
I noticed the code will defer to a web service call (WebUrlFromPageUrl) to get the URL if "currentContext.thisSite" isn't available. The web service returns the complete site URL. So, in this function, the two methods will return the string to the user differently depending on the method the function uses. That may cause some confusion in the long run.
Thanks,
Geoff