my current question is closely related to this , but much more specific. We must plan a design strategy for the purpose described in this question.
We want to do this by rewriting HTML in ASP.NET web forms. My question is: which strategy is the best in terms of feasibility , performance efficiency, and legacy application implementation efforts .
What should I do
It is basically to get the HTML output of the web form, parse it and replace specific URLs according to user rules. In this example, I would rewrite all the static content to the CDN URLs, but it can be easily extended to URL rewriting methods. I found lots (and I really mean lots ) of articles about rewriting URLs in terms of URLs such as http://myblog.com/2092 , which are interpreted as http://myblog.com/Default.aspx?post=2092 , but I have not found that no one is showing me how to correctly format the old style URL for the shorter format directly from within the HTML (so the page will display the short URL directly) [edit] without deep code intervention.
Strategy 1
As in the answer to the above question, write an HTTP module that intercepts HTML and overwrites it. In fact, I looked around and saw that I could set up a Response.Filter stream object that does HTML filtering.
- Pros: I can embed the HTTP module in an outdated application, configure overwrite rules via XML, and install the old CRM / ecommerce application to load static content from CDN without touching its code at all .
- Cons: I suspected that (and the comment here confirms my suspects) to override the
Stream Write method, which works in a partial buffer in the general case, could lead to poor replacements. Suppose the Write method is first called with a piece like ttp://mydomain.com/static/ima (where I assume that <img src="h has already been written before), and then ge.png" /> (like that that guess the final URL: -P) with the rewrite rule, which regexes http://mydomain.com/static/[^"]* at http://cdn.com/path/$1 , the replacement is not performed. To get around this, I could use a MemoryStream or something like this to buffer a complete set of data and then perform replacements, but this can cause problems on heavily loaded servers.
Strategy 2
Overriding the Page Render method as described here
- Pros: does not suffer from a chunking problem
- Cons: requires a base class definition for all pages. New applications are possible, unsure of support for legacy applications. The problem seems to be related to the fact that you cannot directly create the HttpTextWriter.
Obviously, for the new webapps that we will need to develop, I would adopt strategy 2, but I really like to use dynamic components , since they can be easily connected when the application requires them (therefore, if our new application is installed without a CDN, function is disabled).
In short, my questions are:
How would you fix both cons strategies (especially the 1st one)? And, of course, do you have other strategies to achieve this goal?
Thanks.
source share