The base href can't be schema-less because that would remove its purpose - to base Javascript-created relative links properly. There are gadgets in the wild using this behaviour at the moment so I would be nervous about changing the behaviour of the base URL now. Unfortunately, this is also the reason why we can't use a rewriter to do it, unless we are happy to break existing gadgets.
On 13 August 2010 10:32, Christiaan Hees <christi...@q42.nl> wrote: > Maybe the base href itself could also be schema-less? > But there's another downside of it: > *"Internet Explorer 7 & 8 will download stylesheets twice if the http(s) > protocol is missing."* > * > http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/ > * > > <http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/>On > Fri, Aug 13, 2010 at 10:28 AM, Mat Mannion <m.mann...@warwick.ac.uk> wrote: > >> As mentioned, this is a good policy, and definitely something that we >> want to do - but it simply doesn't work, because we output a <base> >> tag with the gadget URI in it (to make relative URIs work), which >> makes the scheme relative to the gadget URI, not the iframe renderer. >> This means that if the gadget URI is on a different scheme to the >> iframe renderer, you are guaranteeing mixed content warnings, not >> avoiding them! >> >> I have an example here from a trivial gadget: >> >> <Module> >> <ModulePrefs title="test" /> >> <Content type="html"> >> <![CDATA[ >> ><link rel="stylesheet" href="/static/gadgets/gmail/gmail.css" >> type="text/css" /> >> <p>This is just a test.</p> >> ]]> >> </Content> >> </Module> >> >> The output from the iframe renderer is: >> >> <html><head> >> <base href=" >> http://start-test.warwick.ac.uk/portal/gadgets/local/example/prefs-test.xml >> "><!-- >> snip.... --> >> >> <link href="// >> start-test.warwick.ac.uk/gadgets/proxy?container=warwick&gadget=http%3A%2F%2Fstart-test.warwick.ac.uk%2Fportal%2Fgadgets%2Flocal%2Fexchange%2Fliveedu-mail.xml&debug=0&nocache=0&refresh=3600&url=https%3A%2F%2Fstart-test.warwick.ac.uk%2Fstatic%2Fgadgets%2Fgmail%2Fgmail.css >> " >> rel="stylesheet" type="text/css"> >> </head> >> <body dir="ltr"> >> <p>This is just a test.</p> >> <script>gadgets.util.runOnLoadHandlers();</script></body></html> >> >> The link href in this gadget will resolve to >> http://start-test.warwick.ac.uk/gadgets/proxy (scheme relative to the >> base href), but the iframe renderer is called from https, thereby >> throwing mixed content warnings. >> >> Mat >> >> On 13 August 2010 01:19, John Hjelmstad <fa...@google.com> 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 <gagan.g...@gmail.com >> >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 <christi...@q42.nl> >> >> 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 <m.mann...@warwick.ac.uk >> >> >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 <plind...@linkedin.com> >> 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 < >> >> m.mann...@warwick.ac.uk >> >> > > >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 <plind...@linkedin.com> >> >> 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 < >> >> > gagan.g...@gmail.com >> >> > > >> >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 < >> >> > m.mann...@warwick.ac.uk >> >> > > > >> >> > > >> >> 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: m.mann...@warwick.ac.uk >> >> > > >> >> > >> >> > > >> >> >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > -- >> >> > > >> > Paul Lindner -- plind...@linkedin.com -- >> linkedin.com/in/plindner >> >> > > >> > >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> -- >> >> > > >> Mat Mannion >> >> > > >> Web Developer >> >> > > >> IT Services >> >> > > >> University of Warwick >> >> > > >> Coventry >> >> > > >> CV4 7AL >> >> > > >> >> >> > > >> Tel: 024 765 74433 >> >> > > >> Email: m.mann...@warwick.ac.uk >> >> > > >> >> >> > > > >> >> > > > >> >> > > > >> >> > > > -- >> >> > > > Paul Lindner -- plind...@linkedin.com -- linkedin.com/in/plindner >> >> > > > >> >> > > >> >> > > >> >> > > >> >> > > -- >> >> > > Mat Mannion >> >> > > Web Developer >> >> > > IT Services >> >> > > University of Warwick >> >> > > Coventry >> >> > > CV4 7AL >> >> > > >> >> > > Tel: 024 765 74433 >> >> > > Email: m.mann...@warwick.ac.uk >> >> > > >> >> > >> >> >> > >> >> >> >> -- >> Mat Mannion >> Web Developer >> IT Services >> University of Warwick >> Coventry >> CV4 7AL >> >> Tel: 024 765 74433 >> Email: m.mann...@warwick.ac.uk >> > -- Mat Mannion Web Developer IT Services University of Warwick Coventry CV4 7AL Tel: 024 765 74433 Email: m.mann...@warwick.ac.uk
