- Very easy: Turn .aspx pages into .ashx httphandlers when possible.
Most of your .aspx logic deals with the responses directly and does
not need to be part of a heavy .net page handler. That brings the next
point.

- Very easy: Profile your application (my favorite profiler is
http://www.jetbrains.com/profiler/, there's a free eval). You'll
immediatly realise that the previous point is critical: The useless
asp.net page logic consumes a large part of the requests cpu time
which could be easily avoided simply by turning your .aspx into ashx.
Once your done with that, I'm sure you'll find other useless hotspots.

- Easy: Introduce a couple of Provider or Strategy patterns to allow
for customization: One may for instance wish to add response caching,
rule based proxies or even static generation. All of those would
currently need to tap into your code whereas with a couple of
web.config based providers/interfaces, one could easily add their own
logic without interfering with yours.
That simply involves abstracting some entry point classes into either
abstract factories or interfaces, and replacing the current hard coded
access with singletons loaded according to their web.config settings,
while making your current implementation the default configuration.
You may look at DotNetNuke providers logic for an example.
Here are a few suggestions for entry points to provider: early in the
processing of incoming requests (to allow for early interception of
your logic with cached responses for instance), early in the
processing of outgoing requests (to allow for mangling with the proxy
for instance), for your various processors/replacers (to allow for
static generation for instance -->  replace the resources' uri with
local files' uri rather than the current .aspx uris), late in the
outgoing response (to allow for late processing like caching or static
file generation).
The first and last one can also be achived with a httpmodule without
touching your code though since Asp.Net already provides that
mechanism to process requests/response before and after your code, yet
it's probably cleaned if you directly offer those entry points

-A little harder yet scalable: For string processing, either use
compiled regexes (Expresso can help a lot if you're not familiar with
regex) or XPath queries (using HtmlAgilityPack for instance) rather
than raw index based processing (cf your performance class). I'm
pretty sure you can achieve much better performances with much less
code using either of those techniques.

Ok that's quite a few suggestions already.
I'm sorry I can't help much with the code for now, but I hope I had my
explanations clear enough for consideration

First of all I have to say thanks to your attention.
There is a bit more problem about this proxy that you may don't know.
I'll talk about that, first lets review your suggestions.

* Your first suggestion "Turn .aspx pages into .ashx httphandlers".
That is the point that I didn't think about it.
Actually there are some .aspx pages that they shouldn't deal with user
interface and yes they are performance penalty.
You will see the changes in next release. Thanks.

* I used VS 2008 Code Analysis and some performance improvements came
from that. I get JetBrains profiler and it seems good. And i see
JetBrains pointed me about pages load delay.

* Having provider based pipeline needs a complete rewrite of current
processes.
Current pipeline is grown slowly since v3 (Last engine rewrite) and I
was thinking how to compact the engine together again.
Provider based pipelines brings abstraction and easy customization to
the project, but it is time consuming. And no one asked me about such
thing except you!
I'm working on this project when i'm free, so i have to have enough
reason to do such thing.
However there is an easy to use class called Presentation that
represent you an up level implementation of ASProxy.

* And regex! doh!
I didn't use Regexes in this project because I could write a better
sollution to procces the large strings and codes. Yes the problem with
regexes is long strings.
The main difficulty of regexes is buggy and errornouse Html and css
codes that the web is full of them.
It is not possible to write any combination of regex to process these
codes, and as you can see ASProxy can process lots of them.
However still regex is really needed but not as a solution, just as a
helper.

your suggestions are good, but they are about asp.net!
The ASProxy difficulties isn't only asp.net, in the last version still
there are problems with javascript, dynamic content "DOM", html tag
attributes and so on.

If you what more details here is a summary:
* processing javascript scripts inside html tag attributes
* processing javascript evals!
* changing download pipeline to allow the user to save the data to the
disk instead of memory.
* providing a good enough administration interface with lots of
limiter and log options.
* flash bytecode decompiler to override the network loads. (bringing
youtube).

Regards,
Salar

On Apr 18, 2:52 am, jsbo...@aricie.fr wrote:

I'll review that more.
Thanks.

On Apr 18, 2:59 am, jsbo...@aricie.fr wrote: