locked
Getting either "A potentially dangerous Request.Path value was detected from the client (%)" or "resource cannot be found" RRS feed

  • Question

  • User1756988842 posted

    This started as a simple update of a dynamic data project from 3.5 to 4.0 with some very minor db changes (field size increase).

    Everything went great from dev to test, but upon moving the site to production, I started getting the following error, but only when hitting update or cancel on two custom edit pages:

    "A potentially dangerous Request.Path value was detected from the client (%)"

    Reading through posts I found two suggestions related to upgrade issues and suggested the following web.config additions:

    <system.web>
        <httpRuntime requestPathInvalidCharacters="" requestValidationMode="2.0" />
        <pages validateRequest="false" />
    </system.web>

    for my situation, applying only the two httpruntime entries is enough to change the result, but that result is a "resource not found" error.  apparently now, the postback is duplicating the path, but replacing "%20" with " " and prepending it....

    Requested URL: /ECADWeb/Division Part/ECADWeb/Division%20Part/List.aspx

    The real url should be "/ECADWeb/Division%20Part/List.aspx"

    I've tried various combinations of the web.config attributes, but can only get these two results.

    Any help would be appreciated.

    Monday, December 16, 2013 11:11 PM

Answers

  • User-330204900 posted

    It may be a difference in the Machine.config between Dev and Live machines

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, December 17, 2013 7:13 PM

All replies

  • User-1509636757 posted

    One of the solution, but should be avoided is:

    <system.web>
        <httpRuntime requestPathInvalidCharacters="" requestValidationMode="2.0" />
        <pages validateRequest="false" />
    </system.web>

    So, I would suggest to avoid spaces in the url like you have in "Division Part".  You can replace spaces by underscore characters if required.

    hope it helps./.

    Tuesday, December 17, 2013 12:22 AM
  • User-1716253493 posted
    <%@ Page Language="C#" AutoEventWireup="true" ValidateRequest="false" ... %>

    Set on that page ValidateRequest to false

    Tuesday, December 17, 2013 1:20 AM
  • User-330204900 posted

    The best solution would be to avoid having the spaces in the URL at all you can do this using the [TableName("DivisionPart")] attribute and removing the space. What the error is really saying is you have a bad URL all the other fixes are doign is masking the issue.

    Tuesday, December 17, 2013 5:23 AM
  • User1756988842 posted

    Thank you all for the input.  Most of this I have tried to no avail.

    The frustrating part of the issue that may have slipped by most of you is that this works perfectly well in my Dev and Test environments.  The test environment is (almost) identical to the production environment (Both Wind 2003 SP2 standard).  However, none of these settings were required on the test server 

    I am frustrated at this inconsistency and the position this situation has put me in.  I'd like to understand what could be causing the difference for my edification.  Usres are using this system in production, despite the error, since the backing db fields have already been updated to longer strings and the updates from the erroring actually work, it's just the redirect back  to the list page that is breaking after the update.

    Steve, thanks for the reply and I'd like to expand on your suggestion.  It was my understanding that this was one of the benefits of DynamicData, to be able to easily control presentation abstracted from db schema or even the EF schema.  In fact my table (and EF entity) name is "Division_Part", but I was using the table name attribute to prettify the site.  I've not had issues with this at any point up to this last roll to production.

    Taking your queue, I've decided to stop using the space...

    I've made the changes to everything being "Division_Part" thruought the app and removed the workarounds from web.config and pages as mentioned above.  Again everything works as expected, all the way up to production.

    In production I'm still getting an error on cancel or update click in my custom edit pages which are trying to redirect to:

    Requested URL: /ECADWeb2/Division_Part/ECADWeb2/Division_Part/List.aspx

    Is there a place I'm missing where my custom page is mangling the target after update/cancel?

    Tuesday, December 17, 2013 2:23 PM
  • User-330204900 posted

    It may be a difference in the Machine.config between Dev and Live machines

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, December 17, 2013 7:13 PM