Reverse Proxy to different server loads infinitely.

May 26, 2009 at 4:49 PM
Edited May 26, 2009 at 4:49 PM

Got this thing here:



RewriteEngine on

RewriteRule ^/(.*)$$1 [P]



Now if I just open this page, it literally loads to death, nothing happens. SMSniff says that it sends a normal http request, but nothing comes back! 

It is a complete proxying of a board, for testing purposes. After I tested it for a while, I recognized I got a cookie from the proxy. At sometime it worked it seems!


I tried it with another local http server on another local port before, it worked fine there.


Any help?

May 26, 2009 at 5:02 PM

Please post the headers that you say load indefinitly.

May 26, 2009 at 5:09 PM
Edited May 26, 2009 at 5:12 PM



Well, theres only the GET Headers, theres no answer at all!



GET / HTTP/1.1

User-Agent: Opera/9.64 (Windows NT 6.1; U; de) Presto/2.1.1


Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1

Accept-Language: de-DE,de;q=0.9,en;q=0.8

Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1

Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0

Cookie: *Censored*

Cookie2: $Version=1

Connection: Keep-Alive, TE

TE: deflate, gzip, chunked, identity, trailers



I put the cookies out, before something not good is in there ;)



IE Just says connection error... Nothing usable but... 

Google Chrome says this:

(Website not available... blah blah... The error is down there, maybe usable!)

Diese Webseite ist nicht verfügbar.

Die Webseite unter ist möglicherweise vorübergehend nicht verfügbar oder ist jetzt unter einer neuen Webadresse aufrufbar.

 Weitere Informationen zu diesem Fehler

Unten finden Sie die ursprüngliche Fehlermeldung

Fehler 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unbekannter Fehler.


May 26, 2009 at 6:16 PM
Edited May 26, 2009 at 6:16 PM

The browser error is the first clue to the problem. 


This tells us that there is a problem with the chunked encoding that is happening.  I am going to be releasing the 3.0 version of the software in the next couple of days.  But back in March I released a preview release that had a number of updates to the Proxy.  One of the updates was the handling of the chunked encoding.

Please try that version that is attached to the work item, and let me know if that fixes the issue.

May 26, 2009 at 6:32 PM

I gotta say, it works PERFECTLY! You should make this version the official version in my opinion!


Thanks a lot, your rewriter rocks!

May 26, 2009 at 7:01 PM

Couple more days and it will be, I am currently dog fooding it on my blog.  I usually do that for 5 days before I release.

May 26, 2009 at 7:18 PM
Edited May 26, 2009 at 7:54 PM

I encountered something else: How do I make your rewriter refresh the rewrites-file? Entering something new and just saving it doesn't work, it seems.


EDIT: Looks like editing the Web.Config works, even by just putting in a comment! But it doesn't look like a good permanent solution!

Can I maybe run a refresh function by vb/c# code?

May 26, 2009 at 8:05 PM

It should be getting refreshed.

But that may have been borken in the interm release you have.  See this file

For details on how it was implimented in methods AddRuleSetMonitoring and RuleSetExpired.

May 26, 2009 at 9:34 PM

It seems this RuleSetCollection isn't really accessible from the application code. The codeword "internal" does that, right? I thought I could just use the refreshrules function. The same is for the AddRuleSetMonitoring and RuleSetExpired functions. 


Will it be fixed in the next release, so it checks for changes?  

May 27, 2009 at 3:40 PM

It is already working in the latest release.  You are using an unsupported preview release, some things may be broken.  For the time being you will need to just manually restart the application pool.  

May 27, 2009 at 7:41 PM

Sorry, it seems I wasn't really thinking when I wrote that post. Of course the main releases already do that. 

Looking forward to the next main release including the chunked encoding fix! Again, thanks for your help, and thanks a lot to your company and you for releasing software open-source, while also giving support to users!



Jun 23, 2009 at 2:55 AM

With regards to the issues in the OP: I am experiencing the same issue.

The environment is as follows:

  • IIS7
  • Vista Enterprise x64
  • Default app pool in integrated mode.

I am testing the Strophe javascript library for XMPP-BOSH to an Openfire server running on my localhost @ port 7070.

The main application is sitting at http://localhost/strope/example/echobot.html.  The Openfire HTTP endpoint is located at http://localhost:7070/http-bind.

The connection for Strophe is pointing to "/strophe/http-bind".  So my rule is as follows:

RewriteEngine On

RewriteRule ^/strophe/http-bind(.*)$ http://localhost:7070/http-bind [P]

My web.config file is as follows:

<?xml version="1.0" encoding="UTF-8"?>
	<!-- Integrate the following in to the <configuration> tag -->
		<section name="managedFusion.rewriter" type="ManagedFusion.Rewriter.Configuration.ManagedFusionRewriterSectionGroup"/>
	<managedFusion.rewriter xmlns="">
		This is just a minimal sample configuration file that shows how to declare
		the configuration sections.
		Because an XML Schema Definition (XSD) is generated for each configuration
		section, it should be trivial to edit these files because you have
		IntelliSense on the XML definition.
		<rules engine="Apache">
			<apache defaultFileName="ManagedFusion.Rewriter.txt" />
			<proxy useAsyncProxy="true" />
	<!-- Integrate the following in to the <system.webServer> tag -->
		<validation validateIntegratedModeConfiguration="false"/>
		<modules runAllManagedModulesForAllRequests="true">
			<add name="RewriterModule" type="ManagedFusion.Rewriter.RewriterModule, ManagedFusion.Rewriter"/>
			<add name="RewriterProxyHandler" preCondition="integratedMode" verb="*" path="RewriterProxy.axd" type="System.Web.HttpForbiddenHandler, System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

Currently, the observed behavior is that the request simply times out.  The Openfire server is running, for sure, as entering http://localhost:7070/http-bind returns a response from the internal web server (jetty) or Openfire.  I've read through a few of the posts on reverse proxy configuration and I cannot figure out what I'm doing wrong on this one.  Any insight would be much appreciated; I've been fighting Openfire for half a day now to get even the most basic BOSH example working :-/

Jun 23, 2009 at 3:02 AM

Ah, got it.

It was due to a misspelled value for defaultFileName.

Perhaps a FileNotFoundException would be useful?  The current behavior seems to just cause it to hang.