locked
UpdatePanel posts back to wrong URL when URLMappings used in a "subdirectory" RRS feed

  • Question

  • User64499103 posted

    I have an update panel that has a button that expands a section for editing content, however after it loads the content to edit, the postback throws a 404, I can track the pages it's trying to go to as well.

     say this is a URL Mapping:

    <add url="~/products/myproduct.aspx" mappedUrl="~/prodTemplate.aspx?pageID=6"/>

    The postback will go to  "/products/prodTemplate.aspx?pageID=6", which doesn't work as products is an 'imaginary" directory

     if I set the postback URL on the button explicitly to go to "~/products/myproduct.aspx", it goes to "products/products/myproduct.aspx"

    This used to work fine in the betas when it was called Atlas, now it's broken.  Also have the image button problem where if you click the topmost or leftmost column of pixels in the image, it gives an error.

    Tuesday, March 6, 2007 2:21 PM

All replies

  • User1515264362 posted

    You must be using a url rewriter module, but which?

    If I just do a simple url rewrite from ~/subdir/foo.aspx to ~/bar.aspx it works fine with or without an update panel. So there must be something more to it. If you can build a repro that doesn't use any external libraries (i.e. write your own url rewriting code) it would help isolate it.

    Tuesday, March 6, 2007 4:31 PM
  • User64499103 posted

    http://msdn.microsoft.com/en-us/library/system.web.configuration.urlmappingssection.aspx

     URLMappings are part of ASP .Net 2.0 and are just set in the web.config file in the System.Web configuration section, it's not like I'm using ISAPI rewrite or anything, I think it's a bug introduced between Beta and 1.0 in ASP.Net Ajax.

    Tuesday, March 6, 2007 9:02 PM
  • User1515264362 posted

    The problem is on a normal postback, the action initially posts to the "real" url. So the action is emitted in response to the postback as if the url is relative to the real location. Are you seeing that the post initially works, but then only on the 2nd attempt it fails?

    I'll look more into it but you should be able to work around it by manually changing the form action itself.

    Try this:

    function pageLoad(sender, args) {
        if(args.get_isPartialLoad()) {
            // update form action
            var form = $get('Form1');
            form._initialAction = form.action = '../prodTemplate.aspx?pageID=6';
        }
    }

    If your querystring is dynamic you could build the action up from it instead of hard coding it like this. Just be sure to set the form._initialAction as well as the form.action... this is how PageRequestManager detects cross page postbacks, and you don't want it to think a regular post is a cross page postback.

    Wednesday, March 7, 2007 2:07 PM
  • User64499103 posted

    so it should keep posting to that same URL, not move it up a directory after the first postback and combine the real URL one with the mapped one's directory

    setting the postback URL seems like it should work and I should not have to hack to the form action with javascript, I'd rather have a reason why it's doing this than to just put in a work-around. 

    Wednesday, March 7, 2007 3:15 PM
  • User-1254343091 posted

    We are experiencing the same problem described in this post. Are there any insights besides the JavaScript work-around described here?

     

    Thanks!

    Wednesday, April 18, 2007 5:40 PM
  • User1515264362 posted

    If you take out the update panel and just do a normal post, you will see that the page will actually post directly to the unmapped url. That means your url rewriting is gone after a postback. That probably isn't what you would want, correct? If you implement a url rewriting scheme that actually changes what the form action is, so that posts go to the mapped url instead, not only will it avoid this issue, but it will work better in general. With this scheme, you have the possibility of the server side thinking the current request is in a different directory than the browser thinks, so things like ResolveClientUrl may report unusable paths. Any way you look at it, its best to avoid that scenario in the first place, so I recommend you take a look at the url rewriting post by Scott Guthrie,

    http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx

     

    Wednesday, April 18, 2007 5:53 PM
  • User1907391030 posted

    Add this to your page:

    Sys.Application.add_load(function()
    {
        var form = Sys.WebForms.PageRequestManager.getInstance()._form;
        form._initialAction = form.action = window.location.href;
    });
    
     
    Wednesday, April 18, 2007 11:51 PM
  • User-1606698118 posted

     

    Add this to your page:

    Sys.Application.add_load(function()
    {
        var form = Sys.WebForms.PageRequestManager.getInstance()._form;
        form._initialAction = form.action = window.location.href;
    });
    

     

     

    I LOVE YOU! I spent many hours today trying to figure out why my update panels were not working with my ISAPI Rewrite site and this just solved it for me. Thank you very much!

    Thursday, August 21, 2008 4:44 PM
  • User-697093121 posted

    Add this to your page:

    Sys.Application.add_load(function()
    {
        var form = Sys.WebForms.PageRequestManager.getInstance()._form;
        form._initialAction = form.action = window.location.href;
    });
    

     

     

     

    Thanks a million Jeffrey. I experienced this behavior when moving a working app from IIS7 to IIS6. After adding your script everything worked perfectly in IIS6 as well.

     

    Cheers!

     

    Kenneth 

    Tuesday, March 31, 2009 4:06 AM
  • User-957428673 posted

    is this javascript or c#
    and where i supposed to add ?

    Wednesday, July 8, 2020 3:25 AM