urlrewriter Work Item Rss Feed

Created Issue: Exceptions not handled in ProxyAsyncHandler.EndProcessRequest [10940]

jumpinjackie — Fri, 20 Jan 2012 04:54:17 GMT

If any exceptions are thrown in this method, it will take down the whole site (where this rewriter is set up) with it.

Adding a catch block to the try/finally prevents this

Created Issue: Running on Exchange 2010 Default WebSite [10939]

elberfeld — Tue, 02 Aug 2011 05:53:27 GMT

I tried to add the URL Rewriter on the DefaultWebsite of an Exchange 2010 Server (Windows Server 2008 R2 x64 / IIS 7.5) to make other internal applications avalable by using the currently published Exchange OWA Site which ist accessible from the internet and seured by a valid SSL certificate.

Once I added the Files (bin Directory, ManagedFusion.Rewriter.txt andweb.config) into the c:\inetpub\wwwroot\ directory the whole Site ist not acessible anymore.

I get the following error in the Eventlog (in german).

Translations:
Event message: Es ist ein Konfigurationsfehler aufgetreten. > a configuration error occured

-------
Event code: 3008
Event message: Es ist ein Konfigurationsfehler aufgetreten.
Event time: 02.08.2011 07:20:42
Event time (UTC): 02.08.2011 05:20:42
Event ID: e1437b0f44044858a6a9b4dc4a57a864
Event sequence: 3
Event occurrence: 1
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1/ROOT/owa-12-129567360398077096
Trust level: Full
Application Virtual Path: /owa
Application Path: E:\Exchange\ClientAccess\owa\
Machine name: MEDUSA

Process information:
Process ID: 6260
Process name: w3wp.exe
Account name: NT-AUTORITÄT\SYSTEM

Exception information:
Exception type: ConfigurationErrorsException
Exception message: Die Datei oder Assembly "ManagedFusion.Rewriter" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.

Request information:
Request URL: https://chronos.connectiv.de:443/owa/
Request path: /owa/
User host address: 79.234.163.77
User:
Is authenticated: False
Authentication Type:
Thread account name: NT-AUTORITÄT\SYSTEM

Thread information:
Thread ID: 1
Thread account name: NT-AUTORITÄT\SYSTEM
Is impersonating: False
Stack trace: bei System.Web.Configuration.ConfigUtil.GetType(String typeName, String propertyName, ConfigurationElement configElement, XmlNode node, Boolean checkAptcaBit, Boolean ignoreCase)
bei System.Web.Configuration.Common.ModulesEntry..ctor(String name, String typeName, String propertyName, ConfigurationElement configElement)
bei System.Web.HttpApplication.BuildIntegratedModuleCollection(List`1 moduleList)
bei System.Web.HttpApplication.GetModuleCollection(IntPtr appContext)
bei System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
bei System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
bei System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
bei System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)

Custom event details:

Closed Issue: Overwriting of Set-Cookie in Proxy [10813]

nberardi — Fri, 13 Aug 2010 19:47:08 GMT

I'm seeing something a little similar here. I have a JBoss application behind an IIS7 proxy and the proxy server is stripping the "set-cookie" HTTP headers from the server response.

Captures show:

1. Client sends login request. Proxy forwards to server

2. Server responds, including a set-cookie in the HTTP header

3. Proxy consumes this set-cookie and sends the response to the client "naked"

4. Client calls another page, sans-cookie. Server issues a new cookie, session is lost, authentication fails

Any suggestions? I've tried the suggested solution of disabling session-state for this app in IIS, but this has not changed anything.
Comments:

Fixed in 3.5.3

Closed Issue: Reverse Proxy Doesn't Handle Basic HTTP Authentication [10893]

nberardi — Fri, 13 Aug 2010 19:28:52 GMT

I setup version 3.5 as a reverse proxy, it works well with normal websites in backend server, but it can't handle the ones request authentication (HTTP authentication). The symptom is:

Proxy server: http://www.myproxy.com

Backend server: http://192.168.1.10

When I use internet browser access http://www.myproxy.com, the browser prompted the login box, I fill in the correct login name and password, it prompted to login again. I checked the HTTP log of the backend webserver, the status code is 401 Unauthorized.

The following are the configuration ManagedFusion.Rewriter

ManagedFusion.Rewriter:

RewriteEngine OnRewriteRule ^(.*) http://192.168.1.11$1 [P]

Both proxy and backend servers are Windows 2003 IIS6 with ASP.NET 2.0
Comments:

Fixed in 3.5.3

Commented Issue: Reverse Proxy Doesn't Handle Basic HTTP Authentication [10893]

ixquisite — Sat, 07 Aug 2010 02:37:28 GMT

Yes, definitely support this one - would be great to have! Might be important to mention that basic and encrypted (digest) - if that makes a difference - would be great to be supported. I am a complete novice here.

Created Issue: Support RewriteMap [10938]

DaCodeBoy — Tue, 25 May 2010 16:45:08 GMT

To enable reusing strings in the rules file, allow the use of the RewriteMap statement.

http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritemap

The simplest version (where the mappings must be specified in the rules file--not in an external file) would be sufficient.

Commented Issue: Overwriting of Set-Cookie in Proxy [10813]

nberardi — Wed, 19 May 2010 11:47:01 GMT

I can't think of any besides the obvious of mixing the proxy .NET headers with the headers from the server your are trying to proxy. This seems to be an IIS 7 issue. Which I can definitely see because if you ever look at the code for ASP.NET with reflector you will see a whole bunch of special cases built in to the framework for specifically IIS 7, that you won't see with IIS 6 or Cassini.

Commented Issue: Reverse Proxy Doesn't Handle HTTP Authentication [10893]

nberardi — Tue, 18 May 2010 16:37:19 GMT

Just to be clear we are talking about Basic HTTP Authentication. As described here: http://en.wikipedia.org/wiki/Basic_access_authentication Because I know from past experience that Windows and LDAP authentication isn't going to work. And I don't have enough resources to dedicate to figuring it out.

Commented Issue: Reverse Proxy Doesn't Handle HTTP Authentication [10893]

daern — Tue, 18 May 2010 15:13:47 GMT

I see the same thing here. Very interesting in the outcome of this...

Created Issue: Reverse Proxy Doesn't Handle HTTP Authentication [10893]

nberardi — Mon, 17 May 2010 18:53:13 GMT

Commented Issue: Overwriting of Set-Cookie in Proxy [10813]

daern — Mon, 17 May 2010 08:02:16 GMT

Hi Nick,

Thanks for the update and apologies for the delay in responding. Can you think of any issues with continuing to run the code with context.Response.ClearHeaders(); commented out as we have done? We've done plenty of testing this week and it's working flawlessly, as far as we can see.

Many thanks for a great tool. Very useful.

Regards,

Daern

Commented Issue: Overwriting of Set-Cookie in Proxy [10813]

nberardi — Mon, 10 May 2010 16:10:17 GMT

Seems to be a bug in IIS 7 handling, because it is working as it is suppose to on IIS 6. Issue probably needs to be opened with Microsoft on this.

Commented Issue: Overwriting of Set-Cookie in Proxy [10813]

nberardi — Mon, 10 May 2010 15:27:32 GMT

I don't have Wireshark setup on my machine. Please use fiddler for now.

Commented Issue: Overwriting of Set-Cookie in Proxy [10813]

daern — Mon, 10 May 2010 14:57:20 GMT

Ah, I see you don't like Wireshark. Here are the same dumps in text format.

Same data, just reformatted from the Wireshark trace :-)

Commented Issue: Overwriting of Set-Cookie in Proxy [10813]

daern — Mon, 10 May 2010 14:41:08 GMT

Ok, here's some logs (they're Wireshark, not Fiddler, but I hope this is ok. Apply an "http" filter and they're quite readable).

The files are:
client_failed.pcap - capture taken from the client browser PC using the 3.5 release
proxy_failed.pcap - capture taken from the proxy server using the 3.5 release
client_ok.pcap - capture taken from the client browser PC using the modified 3.5 release
proxy_ok.pcap - capture taken from the client browser PC using the modified 3.5 release

The key parts are the first HTTP response from the back-end server. (packet 8 in client_failed and packet 5 in proxy_failed) In this you can see the backoffice server returning:
Set-Cookie: JSESSIONID=uAq-xomRZxD2zSAMC91bHw**.node4; Path=/\r\n

...but the client doesn't see this and only sees the "standard" .NET crud.

Using the modified version, which has context.Response.ClearHeaders(); commented out from SendResponseToClient, the traces show that this set-cookie is no longer supressed and is passed to the client. Result: working application.

Closed Issue: querystring not passed along in proxy option [10389]

nberardi — Mon, 10 May 2010 13:59:10 GMT

When using RewriteRule with proxy option [P] the querystring should be passed to the proxy (especially when using [P, QSA]). However no querystring parameters are passed.
Comments:

closed as working with latest build

Created Issue: Overwriting of Set-Cookie in Proxy [10813]

nberardi — Mon, 10 May 2010 13:57:54 GMT

Commented Issue: querystring not passed along in proxy option [10389]

JustinVervoorn — Tue, 13 Apr 2010 14:14:52 GMT

When using RewriteRule with proxy option [P] the querystring should be passed to the proxy (especially when using [P, QSA]). However no querystring parameters are passed.
Comments: ** Comment from web user: JustinVervoorn **

Tested it in version 3.5.2.26426 and the querystring is now passing correctly. Thanks Nick!

Commented Issue: querystring not passed along in proxy option [10389]

nberardi — Tue, 13 Apr 2010 12:14:22 GMT

Please try the latest download.

Closed Issue: Default timeout for reverse proxy too short [10602]

nberardi — Thu, 08 Apr 2010 00:55:14 GMT

The default timeout for the reverse proxy is 100 000 milliseconds. In some situations, this is too short for us. Is it possible to make this timeout longer or configurable?
The 100 000 milliseconds value is the default for the property HttpWebRequest.Timeout, see http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.timeout.aspx. For myself, I have changed this property in the method ManagedFusion.Rewriter.ProxyHandler.SendRequestToTarget(..).

Thank you.
Comments:

Already supported.