For background info on this technique (which I was unaware of) please read http://blog.httpwatch.com/2010/02/10/using-protocol-relative-urls-to-switch-between-http-and-https/
Now that I understand this I'd be happy to get these schemeless URLs back in place -- we should probably be aware of the css issue linked above as well. The css issue I noted was not a problem after all, the display issue was caused by the redefinition of the osapi endpoints.. On Thu, Aug 12, 2010 at 5:19 PM, John Hjelmstad <[email protected]> wrote: > As has been discussed, the rationale for this is to support HTTP and HTTPS > without mixed-content warnings. > > We could do this easily if we had a context object with the current schema > in it. Some installations of Shindig do, and can override the hook in > DefaultIframeUriManager (and others): > > protected String getScheme(Gadget gadget, String container) { > // Scheme-relative by default. Override for specific use cases. > return null; > } > > > --j > > On Thu, Aug 12, 2010 at 5:07 PM, Gagandeep singh <[email protected] > >wrote: > > > Hi Mat, Paul > > > > Sorry for the late response. I tried looking up what the browser behavior > > is > > for uri's without a scheme but could not find anything useful. I have had > > my > > own doubts about schemeless uri's (i still have some), but i vaguely > > remember Ziv explaining and convincing me that it is better to output a > > schemeless uri. The argument was something along the lines that the > browser > > can use the same scheme as that of the page that emits the uri and we > don't > > go through the trouble of figuring out the scheme by looking at the > gadget > > url etc. > > > > From a correctness point of view, there is nothing wrong in emitting > uri's > > with scheme and schemeless uri's can be confusing. The tests written > > in StyleTagProxyEmbeddedUrlsVisitorTest > > just test what the proxyUriManager emits :) So if we finalize on getting > > rid > > of schemeless uris, please go ahead and modify the tests appropriately. > All > > we care about is that proxying functionality is retained. > > > > And it so happens that schemeless uri's also work within css, just like > > they > > currently work with any other url generated by the page html. The browser > > uses the scheme of the html page the css is loaded in context of. Btw, > what > > was the javascript use case you had in mind ? > > > > On Wed, Aug 11, 2010 at 2:52 PM, Christiaan Hees <[email protected]> > > wrote: > > > > > I think I found something related to this. > > > A post to metadata with something like: > > > > > > > > > {"context":{"country":"US","language":"en","view":"default","container":"default"},"gadgets":[{"url":" > > > http://www.google.com/ig/modules/hello.xml","moduleId":1}]} > > > > > > returns an invalid iframeUrl: > > > iframeUrl: "// > > > > > > > > > http://localhost:8080/gadgets/ifr?url=http%3A%2F%2Fwww.google.com%2Fig%2Fmodules%2Fhello.xml&container=default&view=%25view%25&lang=%25lang%25&country=%25country%25&debug=%25debug%25&nocache=%25nocache%25&v=8090dbad37029ea9eaa5e6c6d9cef98a > > > " > > > > > > You can see it on this page with firebug: > > > http://localhost:8080/container/sample-metadata.html > > > > > > > > Good find. It seems the problem arises from the following snippet in > > DefaultIframeUrimanager: > > > > // 2. Set host/authority. > > String host; > > if (usingLockedDomain(gadget, container)) { > > host = ldGen.getLockedDomainPrefix(gadget.getSpec().getUrl()) + > > getReqVal(container, LOCKED_DOMAIN_SUFFIX_KEY); > > } else { > > host = getReqVal(container, UNLOCKED_DOMAIN_KEY); > > } > > uri.setAuthority(host); > > > > What is happening is that we are setting the authority as " > > http://localhost:8080"; and scheme as null, whereas we should be setting > > authority as "localhost:8080". The following snippet in container.js > > explains why this happens: > > > > "defaultShindigTestHost": "http://${SERVER_HOST}:${SERVER_PORT}";, > > "gadgets.uri.iframe.unlockedDomain": "${Cur['defaultShindigTestHost']}", > > > > > > A small fix would be to do this: > > "defaultShindigTestAuthority": "${SERVER_HOST}:${SERVER_PORT}", > > "gadgets.uri.iframe.unlockedDomain": > > "${Cur['defaultShindigTestAuthority']}", > > > > > > On Tue, Aug 10, 2010 at 3:33 PM, Mat Mannion <[email protected] > > >wrote: > > > > > > > Yes, sorry - wrote the mail in a rush. It should be the same as the > > > iframe > > > > URL. > > > > > > > > On 10 August 2010 13:36, Paul Lindner <[email protected]> wrote: > > > > > actually to avoid mixed-content warnings you'll probably want to > > match > > > > the > > > > > scheme of the iframe URL. > > > > > > > > > > On Tue, Aug 10, 2010 at 5:29 AM, Mat Mannion < > > [email protected] > > > > >wrote: > > > > > > > > > >> Can we set the scheme to be the same as the gadget URL, rather > than > > > > >> guessing at http? > > > > >> > > > > >> Mat > > > > >> > > > > >> On 10 August 2010 10:48, Paul Lindner <[email protected]> > > wrote: > > > > >> > I'm also seeing schemeless URIs leaking into the CSS rewriter > > > output. > > > > >> > Here's some output from samplecontainer: > > > > >> > > > > > >> > div.bubble { > > > > >> > > > > > >> > background-image: > > > > >> > > > > > >> > > > > > > > > > > url('//localhost:8080/gadgets/proxy?container=default&gadget=http%3A%2F%2Flocalhost%3A8080%2Fsamplecontainer%2Fexamples%2FSocialHelloWorld.xml&debug=0&nocache=0&url=http%3A%2F%2Flocalhost%3A8080%2Fsamplecontainer%2Fexamples%2Fbubble.gif'); > > > > >> > > > > > >> > background-repeat: no-repeat; > > > > >> > > > > > >> > width: 202px; > > > > >> > > > > > >> > > > > > >> > What's confusing is that the tests as written > > > > >> > (StyleTagProxyEmbeddedUrlsVisitorTest) expect this broken > output. > > > > >> > > > > > >> > I'm going to set the scheme to http for now, I'd like to know > why > > > this > > > > is > > > > >> > the way it is. I can see schemeless URIs being useful in a > > > javascript > > > > >> > context, but I cannot fathom how they're supposed to work > > otherwise. > > > > >> > Gagan/John can you fill us in? > > > > >> > > > > > >> > On Thu, Aug 5, 2010 at 8:41 AM, Gagandeep singh < > > > [email protected] > > > > >> >wrote: > > > > >> > > > > > >> >> Hi Mat > > > > >> >> > > > > >> >> You could post a snippet of the html which has the scheme-less > > > link, > > > > the > > > > >> >> iframe you are talking about and the culprit <base tag> in > gadget > > > > html. > > > > >> >> That > > > > >> >> should help dev@ community understand the problem better. > > > > >> >> Also, you might want to take a look at > > > > >> >> AbsolutePathReferenceRewriter< > > > > >> >> > > > > >> > > > > > > > > > > http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/rewrite/AbsolutePathReferenceVisitor.java > > > > >> >> >. > > > > >> >> It expands all the relative urls relative to the base tag > > provided > > > in > > > > >> the > > > > >> >> html. It doesnt have iframe-src for now, but i guess it can be > > > added > > > > and > > > > >> >> might solve the problem your seeing. > > > > >> >> > > > > >> >> On Thu, Aug 5, 2010 at 4:45 PM, Mat Mannion < > > > [email protected] > > > > > > > > > >> >> wrote: > > > > >> >> > > > > >> >> > Hi all, > > > > >> >> > > > > > >> >> > I understand the thinking behind scheme-less proxy/concat > URIs, > > > but > > > > I > > > > >> >> > don't think they're working as intended. The problem is that > > the > > > > >> >> > intention is that they should be on the same scheme as the > > iframe > > > > >> >> > renderer, but we then insert a <base> tag with the gadget > URI, > > > > which > > > > >> >> > means that the URIs for /proxy and /concat are actually on > the > > > same > > > > >> >> > scheme as the gadget - this is causing issues for us as we > > don't > > > > run > > > > >> >> > the shindig server on HTTP at all. At least, this is the > > > behaviour > > > > I'm > > > > >> >> > seeing in Google Chrome. > > > > >> >> > > > > > >> >> > Could someone take a look at this and tell me if I'm right in > > my > > > > >> >> > deduction that this is what's causing the problem? > > > > >> >> > > > > > >> >> > Thanks in advance, > > > > >> >> > > > > > >> >> > Mat > > > > >> >> > > > > > >> >> > -- > > > > >> >> > Mat Mannion > > > > >> >> > Web Developer > > > > >> >> > IT Services > > > > >> >> > University of Warwick > > > > >> >> > Coventry > > > > >> >> > CV4 7AL > > > > >> >> > > > > > >> >> > Tel: 024 765 74433 > > > > >> >> > Email: [email protected] > > > > >> >> > > > > > >> >> > > > > >> > > > > > >> > > > > > >> > > > > > >> > -- > > > > >> > Paul Lindner -- [email protected] -- > linkedin.com/in/plindner > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> Mat Mannion > > > > >> Web Developer > > > > >> IT Services > > > > >> University of Warwick > > > > >> Coventry > > > > >> CV4 7AL > > > > >> > > > > >> Tel: 024 765 74433 > > > > >> Email: [email protected] > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > > Paul Lindner -- [email protected] -- linkedin.com/in/plindner > > > > > > > > > > > > > > > > > > > > > -- > > > > Mat Mannion > > > > Web Developer > > > > IT Services > > > > University of Warwick > > > > Coventry > > > > CV4 7AL > > > > > > > > Tel: 024 765 74433 > > > > Email: [email protected] > > > > > > > > > > -- Paul Lindner -- [email protected] -- linkedin.com/in/plindner
