IIS httpErrors ExecuteURL hängt eine seltsame Abfragezeichenfolge wie 500; http: //mysite.com/failed-page an die Ziel-URL an

8

Ich habe auf IIS-Fehlerseiten ein seltsames Verhalten festgestellt. Ich habe dieses Setup:

<httpErrors errorMode="Custom" existingResponse="Replace">
 <remove statusCode="500" />
  <error statusCode="500" responseMode="ExecuteURL" path="/error-page" />
</httpErrors>

Wenn manchmal ein ASP.NET-Fehler auftritt, weil die Abfragezeichenfolge zu lang ist, tritt sofort der zweite Fehler auf, wenn versucht wird, die URL der Fehlerseite auszuführen. Ich habe das Problem daran verfolgt, dass IIS die ursprüngliche URL an die URL der Fehlerseite anfügt, wie:

Original: http://example.com/someurl?id=some_very_long_query_string_causing_security_exception
Error: /error-page?500;http://example.com/someurl?id=some_very_long_query_string_causing_security_exception

Das ist ein großes Problem. Wenn die ursprüngliche URL fehlschlägt, weil eine Abfragezeichenfolge zu lang ist, schlägt auch die Fehlerseite mit dem angehängten Material fehl, da die Abfragezeichenfolge noch länger ist!

Ich glaube, das ist der dümmste Fehler in IIS. Weiß jemand, ob es dafür einen Patch des Service Packs gab? Im schlimmsten Fall, wenn bis jetzt nichts behoben ist, gibt es eine Möglichkeit, dieses Verhalten oder irgendwelche Tricks zu deaktivieren, um zu verhindern, dass IIS unerwünschte Inhalte an die Fehlerseite anfügt? Weil es den gesamten benutzerdefinierten Fehlerseitenmechanismus bricht.

iis iis-7.5 Hase
quelle
Sir, ich hatte das gleiche Problem. Hast du es gelöst?
Denis
1
1 Ich habe die gleiche Frage gestellt auf Stackoverflow hier . Würde eine Antwort lieben.
Muhammad Rehan Saeed

Antworten:

1

Wenn Sie dem Pfad einen abschließenden Schrägstrich hinzufügen (z. B. path = "/ error-page /"), werden der Fehlercode und die angehängte URL nicht mehr angehängt. Beachten Sie, dass die ursprüngliche fehlerhafte URL beibehalten wird, z

mitchjhill
quelle