I'm also seeing schemeless URIs leaking into the CSS rewriter output.
Here's some output from samplecontainer:
div.bubble {
background-image:
url('//localhost:8080/gadgets/proxy?container=default&gadget=http%3A%2F%2Flocalhost%3A8080%2Fsamplecontainer%2Fexamples%2FSocialHelloWorld.xml&debug=0&nocache=0&url=http%3A%2F%2Flocalhost%3A8080%2Fsamplecontainer%2Fexamples%2Fbubble.gif');
background-repeat: no-repeat;
width: 202px;
What's confusing is that the tests as written
(StyleTagProxyEmbeddedUrlsVisitorTest) expect this broken output.
I'm going to set the scheme to http for now, I'd like to know why this is
the way it is. I can see schemeless URIs being useful in a javascript
context, but I cannot fathom how they're supposed to work otherwise.
Gagan/John can you fill us in?
On Thu, Aug 5, 2010 at 8:41 AM, Gagandeep singh <[email protected]>wrote:
> Hi Mat
>
> You could post a snippet of the html which has the scheme-less link, the
> iframe you are talking about and the culprit <base tag> in gadget html.
> That
> should help dev@ community understand the problem better.
> Also, you might want to take a look at
> AbsolutePathReferenceRewriter<
> http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/rewrite/AbsolutePathReferenceVisitor.java
> >.
> It expands all the relative urls relative to the base tag provided in the
> html. It doesnt have iframe-src for now, but i guess it can be added and
> might solve the problem your seeing.
>
> On Thu, Aug 5, 2010 at 4:45 PM, Mat Mannion <[email protected]>
> wrote:
>
> > Hi all,
> >
> > I understand the thinking behind scheme-less proxy/concat URIs, but I
> > don't think they're working as intended. The problem is that the
> > intention is that they should be on the same scheme as the iframe
> > renderer, but we then insert a <base> tag with the gadget URI, which
> > means that the URIs for /proxy and /concat are actually on the same
> > scheme as the gadget - this is causing issues for us as we don't run
> > the shindig server on HTTP at all. At least, this is the behaviour I'm
> > seeing in Google Chrome.
> >
> > Could someone take a look at this and tell me if I'm right in my
> > deduction that this is what's causing the problem?
> >
> > Thanks in advance,
> >
> > Mat
> >
> > --
> > Mat Mannion
> > Web Developer
> > IT Services
> > University of Warwick
> > Coventry
> > CV4 7AL
> >
> > Tel: 024 765 74433
> > Email: [email protected]
> >
>
--
Paul Lindner -- [email protected] -- linkedin.com/in/plindner
