http 301 redirect works but proxy does not

Jun 2, 2009 at 4:49 PM

Using the sample web application, we have the following redirect rule:

RewriteRule ^/URLRe/proxy/(.*)$ http://$1 [NC,R=301]

When we change it to use proxy instead as in

RewriteRule ^/URLRe/proxy/(.*)$ http://$1 [NC,P]

the redirect doesn't happen and results in an invalid url causing a http 404.

The first redirect working would indicate that the module loads and the rule is correct.

The System event log does not log any errors upon failing.

Anything obvious we are missng?

Coordinator
Jun 2, 2009 at 6:58 PM

>> the redirect doesn't happen and results in an invalid url causing a http 404.

The redirect would not happen because you changed it to a proxy. A proxy creates a connection to another server to download the data. As for why the 404 is happening, my guess is that a connection isn't being made to the other server. Can you please post your web.config. Nick

Jun 3, 2009 at 3:34 PM

Ok, different poster, same team as the thread starter.

We took a peek at the web.config and there was an invalid proxy configured. Taking it out solved the issue. However we had exactly the same "indefinate loading" issue as a previous poster, i.e. the chunking issue. Next steps - we used the pre-release 3.0 version and made the required changes to the web.config, reproduced here:

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

<configSections>

<section name="managedFusion.rewriter" type="ManagedFusion.Rewriter.Configuration.ManagedFusionRewriterSectionGroup"/>

</configSections>

<managedFusion.rewriter xmlns="http://managedfusion.com/xsd/managedFusion/rewriter">

<rules engine="Apache">

<apache defaultFileName="rewriter.rules" />

</rules>

<rewriter>

<proxy useAsyncProxy="true" />

</rewriter>

</managedFusion.rewriter>

<system.web>

<compilation debug="true">

<assemblies>

<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

<add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />

<add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

</assemblies>

</compilation>

<customErrors mode="Off" />

   <httpModules>

<add name="RewriterModule" type="ManagedFusion.Rewriter.RewriterModule, ManagedFusion.Rewriter"/>

</httpModules>

</system.web>

<system.codedom>

<compilers>

<compiler language="c#;cs;csharp" extension=".cs" warningLevel="4" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">

<providerOption name="CompilerVersion" value="v3.5" />

<providerOption name="WarnAsError" value="false" />

</compiler>

</compilers>

</system.codedom>

</configuration>

Now we get the following error:

Length cannot be less than zero.
Parameter name: length

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

Exception Details: System.ArgumentOutOfRangeException: Length cannot be less than zero.
Parameter name: length

Source Error: 

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.


Stack Trace: 

[ArgumentOutOfRangeException: Length cannot be less than zero.
Parameter name: length]
System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy) +7492983
ManagedFusion.Rewriter.Engines.ApacheEngine.GetRuleSet(String relativePath) in C:\Documents and Settings\BerardiN\Desktop\ManagedFusion\ManagedFusion.Rewriter\Source\Engines\ApacheEngine.cs:87
ManagedFusion.Rewriter.Engines.ApacheEngine.RunRules(HttpContext context) in C:\Documents and Settings\BerardiN\Desktop\ManagedFusion\ManagedFusion.Rewriter\Source\Engines\ApacheEngine.cs:275
ManagedFusion.Rewriter.Manager.RunRules(HttpContext context) in C:\Documents and Settings\BerardiN\Desktop\ManagedFusion\ManagedFusion.Rewriter\Source\Manager.cs:113
ManagedFusion.Rewriter.RewriterModule.context_BeginRequest(Object sender, EventArgs e) in C:\Documents and Settings\BerardiN\Desktop\ManagedFusion\ManagedFusion.Rewriter\Source\RewriterModule.cs:118
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +68
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75

Coordinator
Jun 3, 2009 at 4:35 PM

Is the name of your rules file? 

rewriter.rules

Jun 3, 2009 at 6:14 PM

I've just double-checked, and the answer is yes, the rules file is named "rewriter.rules". Contents below:

RewriteEngine On

#RewriteLog         ./rewriter.log
RewriteLogLovel    9

#RewriteRule    ^/c/a(.*)    http://www.google.com?q=$1    [NC,P]

RewriteRule     ^/c/a/(.*)    http://127.0.0.1:8080/a-3.4.0.0-pre20090601/$1    [NC,P]

(PS: The log file above is commented out, not sure how to set the path 100% - a full path complains about "not being a virtual directory" and the relative path complains about being relative. Not too worried about it though, as long as the Proxy works)

Jun 3, 2009 at 6:25 PM

The URL I'm trying to access is:

http://127.0.0.1/c/a/

Not sure if that adds any value, but rather too much info than too little.

The strange thing is that now the Google query (that used to work), doesn't do so anymore, even with a R=301 instead of a P.

Not too surprising judging by the stacktrace, i.e. ruleparsing being the issue here.

(PS: Yes, I've noticed the spelling mistake on the LogLovel above, I've removed those lines completely, the problem persists.)

Coordinator
Jun 3, 2009 at 7:30 PM
Edited Jun 3, 2009 at 7:30 PM

Well turn on RewriteLogLevel 9 and set RewriteLog to the file name to a file within the web application full path.  And see what comes out. 

You are using pre-release of 3.0 version, and the method has changed since the version you have, so I am unable to reproduce the issue you are seeing through the exception.

Jun 3, 2009 at 7:40 PM

100% right. Do you possibly have a DLL of the current version availble to test with? Since I need to try the new series, we might as well do it on a current version.

Coordinator
Jun 3, 2009 at 8:53 PM

There is nothing at this time.  But I know for a fact that the Rules file did load with that version, because there are many others using it. 

Jun 4, 2009 at 6:32 AM

Ok, log switched on - unfortunately it doesn't shed much (any?) light... This is the only output after trying http://127.0.0.1/c/a/g/test:

 

Rule Processing: RewriteLogLevel: 9
Rule Processing: RewriteRule: ^/c/a/g/(.*) http://www.google.com?q=$1 [NC,R=301]
Rule Processing: RewriteRule: ^/c/a/p/(.*) http://www.google.com?q=$1 [NC,P]
Rule Processing: Managed Fusion Rewriter Version: 3.0.0.14964

 

Stacktrace:

 

ArgumentOutOfRangeException: Length cannot be less than zero.

Parameter name: length]

System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy) +7492983

ManagedFusion.Rewriter.Engines.ApacheEngine.GetRuleSet(String relativePath) in C:\Documents and Settings\BerardiN\Desktop\ManagedFusion\ManagedFusion.Rewriter\Source\Engines\ApacheEngine.cs:87

ManagedFusion.Rewriter.Engines.ApacheEngine.RunRules(HttpContext context) in C:\Documents and Settings\BerardiN\Desktop\ManagedFusion\ManagedFusion.Rewriter\Source\Engines\ApacheEngine.cs:275

ManagedFusion.Rewriter.Manager.RunRules(HttpContext context) in C:\Documents and Settings\BerardiN\Desktop\ManagedFusion\ManagedFusion.Rewriter\Source\Manager.cs:113

ManagedFusion.Rewriter.RewriterModule.context_BeginRequest(Object sender, EventArgs e) in C:\Documents and Settings\BerardiN\Desktop\ManagedFusion\ManagedFusion.Rewriter\Source\RewriterModule.cs:118

System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +68

System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75

 

In this setup "c" is a virtual directory pointing to c:\Inetpub\wwwroot\c and "a" is another virtual directory pointing to c:\Inetpub\wwwroot\c\a. The web.config is setup for the application that resides in the "a" directory.


Jun 4, 2009 at 7:50 AM

Simplified the config with a single directory at the root instead of nested virtual directories. (ISAPI execute access, script access) The problem persists exactly as detailed above.