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] > > >
