protocol-relative

Make an app with UIWebView which open a webpage with protocol-relative styles & images, such as <img src="//example.com/image.png"> (examples for http or https ). Override the page loading process via your custom NSURLConnection , this way . Result: it won't display the images! Though, Safari and other browsers show them correctly... I inspected the page opened in WebView and saw weird requests there. They looked like regular URLs, but with applewebdata scheme, e.g. applewebdata://art-u1.infcdn.net/articles_uploads/2/2586/thumb/3Dtouch%20Main-665x.png . Yay! It doesn't know the "base" scheme

I note in the PHP manual which states the following: HTTP/1.1 requires an absolute URI as argument to » Location: including the scheme, hostname and absolute path, but some clients accept relative URIs. To facilitate users with preference for a HTTPS everywhere connection, I am thinking of changing the headers in my PHP scripts from: header("Location: http://www.example.com/"); to header("Location: //www.example.com/"); I have tested the above code to be working on my firefox browser, but I am not sure whether it is an advisable thing to do. Or whether I should extract the protocol from $

So consider a protocol-relative URL like so; //www.example.com/file.jpg The idea I've had in my head for as long as I can remember is that protocol-relative URLs are in fact absolute URLs. They behave exactly like absolute URLs, and never do they work like relative URLs. I wouldn't expect this to make the browser go find something at http://www.example.com///www.example.com/file.jpg The URL defines the host and the path (like an absolute URL does), and the scheme is inherited from whatever the page used, and therefore it makes a complete unambiguous URL, i.e. an absolute URL. Right? Now, upon

Is anyone aware of whether it is problematic to use protocol relative URLs for an image source to prevent mixed content security warnings. For example linking an image like: <img src="//domain.com/img.jpg" /> instead of: <img src="http://domain.com/img.jpg" /> or <img src="https//domain.com/img.jpg" /> In my testing i've not seen anything to suggest this is wrong but i'm not sure if it has edge cases where it will create problems. EDIT i've seen it throw errors when using PHP's getimagesize function. robjmills Found an interesting gotcha for the use of protocol relative URLs: You have to be

Possible Duplicate: Absolute URLs omitting the protocol (scheme) in order to preserve the one of the current page I recently noticed that the embed codes for the "like" and "tweet" buttons don't include the http protocol. For example: <script type="text/javascript" src="//platform.twitter.com/widgets.js"></script> <script>(function(d, s, id) { var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) {return;} js = d.createElement(s); js.id = id; js.src = "//connect.facebook.net/en_US/all.js#xfbml=1&appId=555"; fjs.parentNode.insertBefore(js, fjs); }(document, 'script', 'facebook

This question already has an answer here: URI starting with two slashes … how do they behave? 4 answers More and more, began to notice that the links in the source code on Web sites begin with two slashes. For example: <a href="//example.com/1.png">Image</a> Why do it? Matthew Flaschen It's a protocol-relative URL (typically HTTP or HTTPS). So if I'm on http://example.org and I link (or include an image, script, etc.) to //example.com/1.png , it goes to http://example.com/1.png . If I'm on https://example.org , it goes to https://example.com/1.png . This lets you easily avoid mixed content

Scheme relative URLs (network-path references) are something that I've just found out about - where you don't specify the scheme of a URL and it picks it up from the current context. For example: <img src="//domain.com/img.png" /> will resolve to https://domain.com/img.png if the current scheme is HTTPS or http://domain.com/img.png if it is not. This seems like a very easy way to resolve those pesky problems of calling an external script or image on an SSL page without bringing up the dreaded error that some content on a page is not secure. The benefit seems obvious, but what I don't seem to