Strategies for debugging StaticContent in QED with SSL?

Hello,

I'm wondering if anyone has any experience routing a deployed QED Website instance to a local StaticContent instance? The trouble I'm having is that in QED everything is SSL/HTTPS, so if I use the routing page to route static content to my IP/port combo (ex. `10.123.1.1:81`), the root URL ends up being `https://10.123.1.1:81`, which won't work locally.

The other approach I tried was to use the following URL in the routing page:
`10.208.104.248-81.ip.next.qed.westlaw.com`

I would expect the URL above to act as a proxy between a server that has working SSL and my local StaticContent server which doesn't have SSL. This seems to work, but every file is coming back as an empty file.

So, has anyone found a working approach to routing QED to local static content? Any help is much appreciated!

Find more posts tagged with

environment

debugging

refinitiv-internal

Accepted answers

mark.maruska

Route locally for static content from QED.

1. Instead of using just the ip address `10.123.1.1:81`, make sure you're using the QED domain name like `10.123.1.1-81.ip.next.qed.westlaw.com`.

2. In many cases, the SSL certs are not quite right for internal environments. Please look to add SSL cert exceptions for all static content locations to ensure the files can be loaded. I don't think there is an explicit SSL cert error for static content, so that may appear to be getting blank files. One way to do this is by navigating to https

/[ipaddress]-[port].ip.next.qed.westlaw.com/Platform/js/v1/Core/Cobalt.Loader.js in your browser of choice. You will get a certificate error... add an exception for this certificate. We use self-signed certs.

4. Navigate to next.qed.westlaw.com/routing, then replace the “JavaScript” and “JavaScriptInternal” values with [ipaddress]-[port].ip.next.qed.westlaw.com and signon.

Note, in some scenarios, it may help to add the "sc-" prefix on the domain name so the iRules can help route more directly. For example, sc-[ipaddress]-[port].ip.next.qed.westlaw.com

All comments

mark.maruska

Andrew Gerber

Thanks Mark! I was using the wrong proxy URL (`qed` instead of `ci`), and didn't have my SSL exceptions entered.

James Greene

@Mark & @Andrew: So we use the "CI" domain names for routing QED to our local Static Content now instead of the "QED" domain names that we previously used? I'm fine with that so long as it works but I just want to know the state of things.

mark.maruska

Sorry, the QED domain names should work (like 10.123.1.1-81.ip.next.qed.westlaw.com). I know there have been issues with the routing for the QED domain names, so if they're not working, then try using the CI domain names.

EXPLORE OUR SITES