locked
Hosted deployment to subdomain RRS feed

  • Question

  • I have a Lightswitch 2012 that's currently hosted on an IIS server at GearHost.com.

    After I deploy my application to a subdomain of my main site (subdomain.mydomain.com), I can login, but I can't see any data. When I inspect the traffic using fiddler, I see messages like this:

    The URI 'http://mydomain.com/ApplicationData.svc/Microsoft_LightSwitch_GetCanInformation?dataServiceMembers='Tasks'
    is not valid since it is not based on 
    'http://subdomain.mydomain.com/subdomain/ApplicationData.svc/'

    My UrlRewrite look like this:

    <rewrite>
      <rules>
        <rule name="subdomain.mydomain.com" stopProcessing="true">
          <match url=".*" />
          <conditions>
            <add input="{HTTP_HOST}" pattern="^(subdomain.)mydomain.com" />
            <add input="{PATH_INFO}" pattern="^/subdomain/" negate="true" />
          </conditions>
          <action type="Rewrite" url="\subdomain\{R:0}" />
        </rule>
      </rules>
    </rewrite>
    
    I really need to resolve this so I can upgrade my customer to the latest version of LS.

    Any ideas?

    Thanks

    Jay Turpin


    Jay Turpin

    Sunday, January 20, 2013 2:45 PM

Answers

  • Jay,

    I think you're running into a known OData issue.

    Basically, the OData endpoints in LIGHTSWITCH have an idea of what their fully qualified URIs are.  The client also has an idea of what URI it used to access the site originally.  If you have a rewrite rule or a proxy or some other intermediary that changes the effective endpoint URI, the client and server will disagree about what the "proper" URI is for a given OData resource.

    The bottom line is that in some situations, the client will send the server a request with a URI in it that the server doesn't think it can serve -- because the server doesn't recognize the client supplied URI as "itself".

    I've recently adapted a WCF message inspector technique commonly used to fix proxying problems on vanilla OData services to the LIGHTSWITCH OData services.  This solution may work for you.  I'll need a day or two to write it up as a blog article and when that's complete, I can post back here.  If you'd like to try the solution earlier, send me an email at matt.evans@microsoft.com, and I'll mail back the content I have ready.

    Wednesday, January 23, 2013 10:11 PM

All replies

  • Anyone from the Lightswitch dev team out there?

    Jay Turpin

    Wednesday, January 23, 2013 4:35 PM
  • Jay,

    I think you're running into a known OData issue.

    Basically, the OData endpoints in LIGHTSWITCH have an idea of what their fully qualified URIs are.  The client also has an idea of what URI it used to access the site originally.  If you have a rewrite rule or a proxy or some other intermediary that changes the effective endpoint URI, the client and server will disagree about what the "proper" URI is for a given OData resource.

    The bottom line is that in some situations, the client will send the server a request with a URI in it that the server doesn't think it can serve -- because the server doesn't recognize the client supplied URI as "itself".

    I've recently adapted a WCF message inspector technique commonly used to fix proxying problems on vanilla OData services to the LIGHTSWITCH OData services.  This solution may work for you.  I'll need a day or two to write it up as a blog article and when that's complete, I can post back here.  If you'd like to try the solution earlier, send me an email at matt.evans@microsoft.com, and I'll mail back the content I have ready.

    Wednesday, January 23, 2013 10:11 PM
  • Thanks Matt! That sounds promising

    Jay Turpin

    Thursday, January 24, 2013 2:22 AM
  • Hi Matt,

    Did you ever get around to posting the article you mentioned?

    Thanks,

    Alex

    Wednesday, October 9, 2013 10:42 AM