You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@shindig.apache.org by Mat Mannion <M....@warwick.ac.uk> on 2010/08/05 13:15:14 UTC

Scheme-less proxy/concat URIs

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.Mannion@warwick.ac.uk

Re: Scheme-less proxy/concat URIs

Posted by Paul Lindner <pl...@linkedin.com>.

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 <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.goku@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 <ch...@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.Mannion@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 <pl...@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.Mannion@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 <pl...@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.goku@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.Mannion@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.Mannion@warwick.ac.uk
> > > > >> >> >
> > > > >> >>
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Paul Lindner -- plindner@linkedin.com --
> linkedin.com/in/plindner
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Mat Mannion
> > > > >> Web Developer
> > > > >> IT Services
> > > > >> University of Warwick
> > > > >> Coventry
> > > > >> CV4 7AL
> > > > >>
> > > > >> Tel: 024 765 74433
> > > > >> Email: M.Mannion@warwick.ac.uk
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Mat Mannion
> > > > Web Developer
> > > > IT Services
> > > > University of Warwick
> > > > Coventry
> > > > CV4 7AL
> > > >
> > > > Tel: 024 765 74433
> > > > Email: M.Mannion@warwick.ac.uk
> > > >
> > >
> >
>



-- 
Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner

Re: Scheme-less proxy/concat URIs

Posted by Gagandeep Singh <ga...@google.com>.

Can't AbsolutePathReferenceRewriter be run as part of ProxyServlet to first
convert the relative urls to absolute and then the proxyUriManager could
convert these correctly to schemeless uri ?

Thanks
Gagan




On Fri, Aug 13, 2010 at 1:58 PM, Mat Mannion <M....@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.goku@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 <ch...@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.Mannion@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 <pl...@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.Mannion@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 <pl...@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.goku@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.Mannion@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.Mannion@warwick.ac.uk
> >> > > >> >> >
> >> > > >> >>
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> > --
> >> > > >> > Paul Lindner -- plindner@linkedin.com --
> linkedin.com/in/plindner
> >> > > >> >
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> --
> >> > > >> Mat Mannion
> >> > > >> Web Developer
> >> > > >> IT Services
> >> > > >> University of Warwick
> >> > > >> Coventry
> >> > > >> CV4 7AL
> >> > > >>
> >> > > >> Tel: 024 765 74433
> >> > > >> Email: M.Mannion@warwick.ac.uk
> >> > > >>
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Mat Mannion
> >> > > Web Developer
> >> > > IT Services
> >> > > University of Warwick
> >> > > Coventry
> >> > > CV4 7AL
> >> > >
> >> > > Tel: 024 765 74433
> >> > > Email: M.Mannion@warwick.ac.uk
> >> > >
> >> >
> >>
> >
>
>
>
> --
> Mat Mannion
> Web Developer
> IT Services
> University of Warwick
> Coventry
> CV4 7AL
>
> Tel: 024 765 74433
> Email: M.Mannion@warwick.ac.uk
>

Re: Scheme-less proxy/concat URIs

Posted by Mat Mannion <M....@warwick.ac.uk>.

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 <ch...@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....@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.goku@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 <ch...@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.Mannion@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 <pl...@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.Mannion@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 <pl...@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.goku@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.Mannion@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.Mannion@warwick.ac.uk
>> >> > > >> >> >
>> >> > > >> >>
>> >> > > >> >
>> >> > > >> >
>> >> > > >> >
>> >> > > >> > --
>> >> > > >> > Paul Lindner -- plindner@linkedin.com --
>> linkedin.com/in/plindner
>> >> > > >> >
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> > > >> --
>> >> > > >> Mat Mannion
>> >> > > >> Web Developer
>> >> > > >> IT Services
>> >> > > >> University of Warwick
>> >> > > >> Coventry
>> >> > > >> CV4 7AL
>> >> > > >>
>> >> > > >> Tel: 024 765 74433
>> >> > > >> Email: M.Mannion@warwick.ac.uk
>> >> > > >>
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > --
>> >> > > > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
>> >> > > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Mat Mannion
>> >> > > Web Developer
>> >> > > IT Services
>> >> > > University of Warwick
>> >> > > Coventry
>> >> > > CV4 7AL
>> >> > >
>> >> > > Tel: 024 765 74433
>> >> > > Email: M.Mannion@warwick.ac.uk
>> >> > >
>> >> >
>> >>
>> >
>>
>>
>>
>> --
>> Mat Mannion
>> Web Developer
>> IT Services
>> University of Warwick
>> Coventry
>> CV4 7AL
>>
>> Tel: 024 765 74433
>> Email: M.Mannion@warwick.ac.uk
>>
>



-- 
Mat Mannion
Web Developer
IT Services
University of Warwick
Coventry
CV4 7AL

Tel: 024 765 74433
Email: M.Mannion@warwick.ac.uk

Re: Scheme-less proxy/concat URIs

Posted by Christiaan Hees <ch...@q42.nl>.

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....@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.goku@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 <ch...@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.Mannion@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 <pl...@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.Mannion@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 <pl...@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.goku@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.Mannion@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.Mannion@warwick.ac.uk
> >> > > >> >> >
> >> > > >> >>
> >> > > >> >
> >> > > >> >
> >> > > >> >
> >> > > >> > --
> >> > > >> > Paul Lindner -- plindner@linkedin.com --
> linkedin.com/in/plindner
> >> > > >> >
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> --
> >> > > >> Mat Mannion
> >> > > >> Web Developer
> >> > > >> IT Services
> >> > > >> University of Warwick
> >> > > >> Coventry
> >> > > >> CV4 7AL
> >> > > >>
> >> > > >> Tel: 024 765 74433
> >> > > >> Email: M.Mannion@warwick.ac.uk
> >> > > >>
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Mat Mannion
> >> > > Web Developer
> >> > > IT Services
> >> > > University of Warwick
> >> > > Coventry
> >> > > CV4 7AL
> >> > >
> >> > > Tel: 024 765 74433
> >> > > Email: M.Mannion@warwick.ac.uk
> >> > >
> >> >
> >>
> >
>
>
>
> --
> Mat Mannion
> Web Developer
> IT Services
> University of Warwick
> Coventry
> CV4 7AL
>
> Tel: 024 765 74433
> Email: M.Mannion@warwick.ac.uk
>

Re: Scheme-less proxy/concat URIs

Posted by Mat Mannion <M....@warwick.ac.uk>.

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 <ga...@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 <ch...@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.Mannion@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 <pl...@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.Mannion@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 <pl...@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.goku@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.Mannion@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.Mannion@warwick.ac.uk
>> > > >> >> >
>> > > >> >>
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> > --
>> > > >> > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
>> > > >> >
>> > > >>
>> > > >>
>> > > >>
>> > > >> --
>> > > >> Mat Mannion
>> > > >> Web Developer
>> > > >> IT Services
>> > > >> University of Warwick
>> > > >> Coventry
>> > > >> CV4 7AL
>> > > >>
>> > > >> Tel: 024 765 74433
>> > > >> Email: M.Mannion@warwick.ac.uk
>> > > >>
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Mat Mannion
>> > > Web Developer
>> > > IT Services
>> > > University of Warwick
>> > > Coventry
>> > > CV4 7AL
>> > >
>> > > Tel: 024 765 74433
>> > > Email: M.Mannion@warwick.ac.uk
>> > >
>> >
>>
>



-- 
Mat Mannion
Web Developer
IT Services
University of Warwick
Coventry
CV4 7AL

Tel: 024 765 74433
Email: M.Mannion@warwick.ac.uk

Re: Scheme-less proxy/concat URIs

Posted by John Hjelmstad <fa...@google.com>.

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 <ga...@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 <ch...@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.Mannion@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 <pl...@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.Mannion@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 <pl...@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.goku@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.Mannion@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.Mannion@warwick.ac.uk
> > > >> >> >
> > > >> >>
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Mat Mannion
> > > >> Web Developer
> > > >> IT Services
> > > >> University of Warwick
> > > >> Coventry
> > > >> CV4 7AL
> > > >>
> > > >> Tel: 024 765 74433
> > > >> Email: M.Mannion@warwick.ac.uk
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
> > > >
> > >
> > >
> > >
> > > --
> > > Mat Mannion
> > > Web Developer
> > > IT Services
> > > University of Warwick
> > > Coventry
> > > CV4 7AL
> > >
> > > Tel: 024 765 74433
> > > Email: M.Mannion@warwick.ac.uk
> > >
> >
>

Re: Scheme-less proxy/concat URIs

Posted by Gagandeep singh <ga...@gmail.com>.

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 <ch...@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....@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 <pl...@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.Mannion@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 <pl...@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.goku@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.Mannion@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.Mannion@warwick.ac.uk
> > >> >> >
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Mat Mannion
> > >> Web Developer
> > >> IT Services
> > >> University of Warwick
> > >> Coventry
> > >> CV4 7AL
> > >>
> > >> Tel: 024 765 74433
> > >> Email: M.Mannion@warwick.ac.uk
> > >>
> > >
> > >
> > >
> > > --
> > > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
> > >
> >
> >
> >
> > --
> > Mat Mannion
> > Web Developer
> > IT Services
> > University of Warwick
> > Coventry
> > CV4 7AL
> >
> > Tel: 024 765 74433
> > Email: M.Mannion@warwick.ac.uk
> >
>

Re: Scheme-less proxy/concat URIs

Posted by Christiaan Hees <ch...@q42.nl>.

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

On Tue, Aug 10, 2010 at 3:33 PM, Mat Mannion <M....@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 <pl...@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.Mannion@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 <pl...@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.goku@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.Mannion@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.Mannion@warwick.ac.uk
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
> >> >
> >>
> >>
> >>
> >> --
> >> Mat Mannion
> >> Web Developer
> >> IT Services
> >> University of Warwick
> >> Coventry
> >> CV4 7AL
> >>
> >> Tel: 024 765 74433
> >> Email: M.Mannion@warwick.ac.uk
> >>
> >
> >
> >
> > --
> > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
> >
>
>
>
> --
> Mat Mannion
> Web Developer
> IT Services
> University of Warwick
> Coventry
> CV4 7AL
>
> Tel: 024 765 74433
> Email: M.Mannion@warwick.ac.uk
>

Re: Scheme-less proxy/concat URIs

Posted by Mat Mannion <M....@warwick.ac.uk>.

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 <pl...@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....@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 <pl...@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.goku@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....@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.Mannion@warwick.ac.uk
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
>> >
>>
>>
>>
>> --
>> Mat Mannion
>> Web Developer
>> IT Services
>> University of Warwick
>> Coventry
>> CV4 7AL
>>
>> Tel: 024 765 74433
>> Email: M.Mannion@warwick.ac.uk
>>
>
>
>
> --
> Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
>



-- 
Mat Mannion
Web Developer
IT Services
University of Warwick
Coventry
CV4 7AL

Tel: 024 765 74433
Email: M.Mannion@warwick.ac.uk

Re: Scheme-less proxy/concat URIs

Posted by Paul Lindner <pl...@linkedin.com>.

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....@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 <pl...@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.goku@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....@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.Mannion@warwick.ac.uk
> >> >
> >>
> >
> >
> >
> > --
> > Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
> >
>
>
>
> --
> Mat Mannion
> Web Developer
> IT Services
> University of Warwick
> Coventry
> CV4 7AL
>
> Tel: 024 765 74433
> Email: M.Mannion@warwick.ac.uk
>



-- 
Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner

Re: Scheme-less proxy/concat URIs

Posted by Mat Mannion <M....@warwick.ac.uk>.

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 <pl...@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 <ga...@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....@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.Mannion@warwick.ac.uk
>> >
>>
>
>
>
> --
> Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
>



-- 
Mat Mannion
Web Developer
IT Services
University of Warwick
Coventry
CV4 7AL

Tel: 024 765 74433
Email: M.Mannion@warwick.ac.uk

Re: Scheme-less proxy/concat URIs

Posted by Paul Lindner <pl...@linkedin.com>.

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 <ga...@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....@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.Mannion@warwick.ac.uk
> >
>



-- 
Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner

Re: Scheme-less proxy/concat URIs

Posted by Gagandeep singh <ga...@gmail.com>.

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....@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.Mannion@warwick.ac.uk
>