In the first installment in this series, we laid out the context for the latest set of technologies in HDX MediaStream Multimedia Redirection, and explained what’s in 7.16. In this post, we will explain the differences between HTML5 Video Redirection and Browser Content Redirection and do a deep dive into the technologies.
Browser Content Redirection is a new feature introduced in XenApp/XenDesktop 7.16.
It allows the entire browser content area (a.k.a. viewport) to be seamlessly redirected to the client for selected webpages or domains. Previous versions of XenApp/XenDesktop (7.12 or higher) ship with a similar feature called HTML5 Video Redirection, which redirects only HTML5 <video> elements to the client.
These are complementary technologies to offload various types of resource-hungry multimedia tasks to endpoint devices, increasing server scalability and providing an enhanced experience for users.
These two features may be enabled independently, or they can both be enabled, to handle a greater set of circumstances.
The previously released HTML5 Video Redirection feature is useful for offloading some videos from webpages to Windows (4.5 or higher) and Linux (13.5 or higher) Receiver endpoints. It utilizes HDX MediaStream Multimedia Redirection components (a.k.a. RAVE) to redirect and render the video client-side. The currently shipping version, however, is limited to streaming only videos that don’t utilize the Media Source Extensions (MSE) API or Encrypted Media Extensions (EME) DRM. These extensions are commonly used to provide Adaptive Bitrate or streaming videos, or copyright-protected media.
Browser Content Redirection is capable of redirecting the entire web page contents to the endpoint device, when a user browses to a URL that was whitelisted, using a compatible version of Receiver with the new feature (Receiver for Windows 4.10, or Receiver for Linux coming out early 2018). This redirection happens seamlessly, so that when browsing non-whitelisted pages, they are loaded and rendered on the server side. When the user navigates to a URL in the whitelist, the entire page is loaded and rendered on the client side, instead. Once the user navigates away from whitelisted pages, the server resumes processing and rendering the pages server-side. All this happens seamlessly to the user. DASH and HLS are supported.
Additionally, Browser Content Redirection includes functionality for allowing clients without direct access to a web server to access it across an ICA connection. For instance, if the content is hosted on a server inside a private network, or if the endpoint device does not have internet access, we can still download the page across a virtual channel and render it client-side. Access to resources inside protected networks may be controlled via policies by configuring the redirection components to access webpages using a proxy server on the VDA’s network. Thus, any requests for page content may be validated, filtered, and selectively allowed based on what content users try to access and from where.
Let’s look at the network diagram of Browser Content Redirection doing Server Fetch Client Render:
- VDA remotes IE11 instance to Receiver via ICA/Thinwire. User navigates to YouTube.com
- VDA IE Browser fetches content from YouTube, and the Add-On (BHO) injects the JavaScript HdxVideo.js into the webpage’s HTML code. Add-on will read the whitelisted websites from a Studio Policy and inject only on those (YouTube will be whitelisted by default).
- HDXvideo.js
- HdxVideo.js is executed on the VDA’s IE Browser, and it calls the Browser Service via WebSockets.
- Now, via the Control Virtual Channel the VDA’s Browser Service communicates with Receiver, instructing Receiver to instantiate the Rendering Engine (HdxBrowser.exe) and overlay it on the Remoted Browser’s Viewport.
- Note that the Address Bar on the Remoted IE is still the VDA’s Browser Address Bar. Id est, the Address Bar is not recreated locally, only the Viewport (user’s visible area of a web page).
- Last step is for the VDA to create a TCP Port Forwarding Socket that the Receiver Rendering Engine can use to fetch content.
- Server Fetch Client Render (SFCR) process begins. Receiver Rendering Engine is configured to point to a Listen Port (<localhost>:<Listen Port>).
- This Listen Port is where the Rendering Engine sends its HTTP/S Requests. These requests will then be forwarded via the Browser Virtual Channel back to the VDA.
- The TCP Port Forwarding Service then relays all traffic through the Forward Proxy (BlueCoat, NetScaler Secure Web Gateway, etc.), and returns HTTP/S Responses from YouTube back to Receiver Rendering Engine (HdxBrowser.exe). Rendering of the entire webpage begins locally.
- Note that the TCP Port Forwarding Service knows the FQDN of the BlueCoat / NS-SWG since this was explicitly configured in a Studio Policy (‘Browser Content Redirection Proxy server configuration’).
- The Forward Proxy is required because otherwise HdxBrowser.exe would have unrestricted access to the Intranet, and from a Security perspective some Enterprises would like to restrict that.
- Note that if you are using Client Fetch Client Render, step 3.4 (and subsequent) do not happen. HdxBrowser.exe will fetch the content directly from YouTube.com
When to use Browser Content Redirection, and when to use HTML5 Video Redirection:
Ultimately, HTML5 Video Redirection and Browser Content Redirection serve two different use cases. Browser Content Redirection is ideally suited for externally facing public websites such as YouTube whereas HTML5 Video Redirection is ideal for situations where you have control over the webpages. Having control over the webpages means having the ability to customize them by adding our JavaScript to the pages’ HTML code, as well as ensuring that the video players used on these pages are compatible with our video redirection technology and will remain so in the foreseeable future.
A company intranet or portal is a classic example of this use case.
HTML5 Video Redirection provides a slightly lighter-weight redirection mechanism, where only the video is redirected to the endpoint. The video redirection is supported on any endpoint that supports HDX MediaStream Multimedia Redirection (Windows and Linux Receivers) and has the necessary decoder hardware and software components to render H.264 video (Media Foundation / DirectShow for Windows, Gstreamer 0.10 or 1.x for Linux with the ‘ugly codecs’).
In HTML5 Video Redirection, if there are any dependencies or behaviors specific to the server-side browser components (Extensions, Internet Explorer version, policies, etc.), they won’t be affected by the redirection. Additionally, the browser context and state, such as authentication and cookies is preserved (allowing Single Sign-On solutions). Also, since we are bypassing the browser’s media engine and leveraging our own Citrix Media Engine, this allows us to extend the browser’s capabilities and support things like Multicast, even for HTML5.
Another key factor that informs your decision on which feature to use is security. If your webpage content must remain in the virtual desktop’s network, you should either render the pages server-side or use only the HTML5 Video Redirection feature.
The Browser Content Redirection feature will download webpages to the client side, to be rendered. For this first release, plugins (like Flash or Silverlight) will be disabled by default.
Lastly, if you have pages that do heavy JavaScript processing, or animations via CSS, JavaScript, or the HTML5 Canvas element, Browser Content Redirection may provide an additional benefit. Even a fairly simple animation could potentially result in significant CPU costs, encoding the video frames to be sent to the client. Though HTML5 Video Redirection isn’t designed to be able to handle any of these cases, Browser Content Redirection can potentially offload them to your endpoint and greatly improve the user experience while decreasing datacenter costs.
We will be improving Browser Content Redirection and adding more features all throughout 2018.
So stay tuned to HDX!
Citrix TechBytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Click here for more TechBytes and subscribe.
Want specific TechBytes? Let us know! tech-content-feedback@citrix.com
