Whole page replacement

Reflecting to modify the underlying stream is not going to be supported either.   What is the specific use case for this and can you provide examples?  Is there a reason you cannot define your custom url as a new route with a definition that omits headers, etc?  This is how oauth authorization works, it's a page route that's page definition only defines a content region.   This is the way the platform wants rendering to occur, modifying the rendering via code is not intended and can break core functionality

We have a requirement where a customer requires rendering just a single widget without any other widgets including locked ones on the page, so the page layout does indeed only have the one widget, but it renders the locked header and footer widgets.  We need just the single widget rendered, in the previous iterations we did this using a http post filter on the content once Verint had rendered the page.   

We have a requirement where a customer requires rendering just a single widget without any other widgets including locked ones on the page, so the page layout does indeed only have the one widget, but it renders the locked header and footer widgets.  We need just the single widget rendered, in the previous iterations we did this using a http post filter on the content once Verint had rendered the page.   

Can you provide an example of the API that was used so I can review it?    You can still accomplish this the way I described

[assembly: PreApplicationStartMethod(typeof(FourRoads.VerintCommunity.RenderingHelper.RenderingHelperApplicationStart), "Start")]

public class RenderingHelperApplicationStart
{
    /// <summary>
    /// Dynamically registers HTTP Module
    /// </summary>
    public static void Start()
    {
        DynamicModuleUtility.RegisterModule(typeof(RenderingHelperModule));
    }
}

This didn't use API's as it wasn't possible and still isn't possible it seems.

We didn't support HttpModules, same as we don't support HttHandlers.  Where functionality was reasonable for extensibility we built APIs for them.  For example HttpHandlers are not supported, but RAW custom routes are the API equivalent.   HttpModules provide privileged access to low level application functions that could create significant issues functionally, performance wise an security wise within the platform.

I suggest taking the route of defining the url and page as a content section only in a custom INavigable Plugin Type  plugin

That won't work as we need the theme, javascript and widget rendering, just not the header and footer regions, unless I have misunderstood some functionality?

Adding a page via that plugin with only a content region defined in the xml is only emitting widget regions, all platform related functionality is still provided, including css, javascript etc.   

Maybe I am misunderstanding something, if I wanted to render just one widget on the page, but not render anything in the header or footer regions including widgets that are locked in the theme how can you achieve that with INavigable Plugin Type? 

INavigable.RegisterUrls -> IUrlController.AddPage(...), PageDefinitonOptions.DefaultPageXml would be your page xml defining only the content region, not header or footer region.  In The content region xml you define the widget you want there.

IUrlController Plugin Supplementary Type 

 PageDefinitionOptions Plugin Supplementary Type 

but that still renders the header and footer regions from the theme?

Additionally we have requirements where a plugin would want to stop rendering the header and footer widgets programmatically for any particular page. 

No, it does not. This is an example of a page doing just as I described.   It has no header or footer region for widgets to render in.

As for other pages, it is not supported to alter the layouts or content of platform defined pages outside of what you can do in the UI, this is why there is no access to the default definitions, same as default widgets