Reinventing Response.Redirect



  • I'm generally fairly forgiving when I encounter "eccentric" code written by former developers where I work as I've done my fair share of messy hacks. However, I recently encountered an amazing piece of code.

    This page is posted to by another page (car_edit.asp), and they use a unique method of getting back to the page after processing the form submission. The code for this app is littered with similar code, but this represents it quite well.

     



  •  A couple things here.

    A. This is VbScript running on the client, so they would not use response.redirect, as that redirects the HTTP Response.

    B. Vbscript in the client means it only runs on IE.

    C. Obviously we are dealing with popups, and this code is used to navigate the correct open window.

     

     I don't see any WTF's here, assuming that this is vintage mid 90's classic ASP, before javascript became the norm. I'd be concerned if someone recently wrote this.

     



  •  While this is a WTF, unuse of server-side redirecting is not always a WTF

    I had to take care of redirecting certain requests.  I had no control over the referring link, which opened them in a new window (like 300x600) with none of the navigation buttons.  Since it didn't have php (or equivalent) installed (and I had no control over that), I had to resort to javascript.  The advantage was that I could resize the page before I redirected.  The disadvantage was that anyone who disabled javascript would be looking at the wrong page.  

    Now that I think about it, I may have been able to do something in .htaccess to redirect it, but that's my last job, not my current one, and thus no longer my problem.  I hope that company burns in hell.  Now that I look for where its links used to be, it seems to be burning quite well.  Fuckers.



  • I'm generally the "add redundancy to accomodate my paranoia" type.  The last site i developed had a homebrew redirect function that would:

    1) Set redirect headers
    2) Add a META redirect tag
    3) Add a JavaScript redirect
    4) Add link telling the user he's being redirected, and should "click here" if it doesn't happen.

    There's no way you're going to get lost on that site.



  • @Jonathan Holland said:

    A. This is VbScript running on the client, so they would not use response.redirect, as that redirects the HTTP Response.
    B. Vbscript in the client means it only runs on IE.

    It's not vbscript running on the client.  See the <% and %> tags?  the server code is building the html page prior to flushing it to the client.

    @Jonathan Holland said:

    C. Obviously we are dealing with popups, and this code is used to navigate the correct open window.

    Why would you assume that?



  • @clively said:

    It's not vbscript running on the client.  See the <% and %> tags?  the server code is building the html page prior to flushing it to the client.

    Yes, but what it is building is the client-side onload method, in vbscript.  Server-side code building client-side vbscript to redirect...



  • @clively said:

    @Jonathan Holland said:

    A. This is VbScript running on the client, so they would not use response.redirect, as that redirects the HTTP Response.
    B. Vbscript in the client means it only runs on IE.

    It's not vbscript running on the client.  See the <% and %> tags?  the server code is building the html page prior to flushing it to the client.

    @Jonathan Holland said:

    C. Obviously we are dealing with popups, and this code is used to navigate the correct open window.

    Why would you assume that?

     

     window.parent is referring to the window that opened a popup. 



  • @Jonathan Holland said:

    @clively said:

    @Jonathan Holland said:

    A. This is VbScript running on the client, so they would not use response.redirect, as that redirects the HTTP Response.
    B. Vbscript in the client means it only runs on IE.

    It's not vbscript running on the client.  See the <% and %> tags?  the server code is building the html page prior to flushing it to the client.

    @Jonathan Holland said:

    C. Obviously we are dealing with popups, and this code is used to navigate the correct open window.

    Why would you assume that?

     

     window.parent is referring to the window that opened a popup. 

     

    Actually, no. window.parent refers to the parent frame in a frameset. What you mean is window.opener.

    As such, this code isn't really a WTF.  "window.parent.navigate" refreshes the parent frame of the page, which is something you can't do in purely server-side code.



  • Ah you are correct. Its been a very long time since I wrote any code that worked with popups, with them being evil and all :)

    Regardless, its manipulating the client, not the server, so it makes no sense to use Response Redirect...after all, there is no response to redirect :)

      



  • @Jonathan Holland said:

    Ah you are correct. Its been a very long time since I wrote any code that worked with popups, with them being evil and all :)

    Regardless, its manipulating the client, not the server, so it makes no sense to use Response Redirect...after all, there is no response to redirect :)

     

     

    Not sure what you mean... is this a critique of the code, or the OP? 



  • @lilakuh said:

    @Jonathan Holland said:

    Ah you are correct. Its been a very long time since I wrote any code that worked with popups, with them being evil and all :)

    Regardless, its manipulating the client, not the server, so it makes no sense to use Response Redirect...after all, there is no response to redirect :)

     

     

    Not sure what you mean... is this a critique of the code, or the OP? 

     

    Critiquing the OP for posting a non WTF.

     



  • @Jonathan Holland said:

    Critiquing the OP for posting a non WTF.

     

    And there you have it.



  • @Jonathan Holland said:

    Critiquing the OP for posting a non WTF.
     

     Gotcha :) 



  • The code redirects to the originating page, either in the same window, or by breaking out of a frame or iframe etc. Breaking out requires client-side trickery, but the first case should be just a http header. So there's a WTF, if you squint a little bit.

    Besides, why the code should be breaking out of framesets after processing a POST-dump-to-db in the first place may be its own WTF...



  • I should have probably given a bit more background on this. But with this particular system, posting code for all of the pieces isn't feasible. I'll try to explain it though.

    The page(s) in question are set-up as a frameset containing a header and a body frame. The header contains the number of the item being edited and the save button. The body contains the form and a Javascript function to submit it. When someone clicks save in the header it fires off the Javascript function in the body to submit the form. The submitted data is processed and the user is sent back to the edit page via client-side VBScript generated by the page which processed the POST. I do admit the example I posted requires some sort of work-around to break out of the frame, but in this situation the ideal thing would have been setting the form's target attribute to the parent frame. The pages in this system use client-side VBScript for all page redirection, even when frames are not involved or when breaking out of frames isn't required.



  • @Jonathan Holland said:

    after all, there is no response to redirect :)
    Yes there is. The code is choosing to send a script with client-side code to go to a different page in that response, rather than to redirect it.



  • Show me a way to break out of a frameset using server code.

     


Log in to reply