39

During today's maintenance, I've noticed an annoying side effect to certain error pages. I happened to end up on https://workplace.stackexchange.com/error?aspxerrorpath=/ when trying to navigate to The Workplace. An interesting side effect of that error scheme is that if you refresh that page, even after the error no longer occurs, you'll continue getting the error page, as if the site was still down. It's because the error redirects you to a URL that will always show you the error.

Since it's an ASPX error, not a "normal" error like the 404 pages, I'm not sure it can be changed, but ideally if you hit an error page you shouldn't be "stuck" on that error page. The error was fleeting, but the error URL scheme isn't.

4
  • 5
    I find this incredibly irritating too. And I sometimes continue refreshing not realizing the URL changed and I need to change it back to the URL I wanted.
    – animuson StaffMod
    Sep 16, 2012 at 3:25
  • 1
    This was a limitation of MVC3, we'll take a look again if we can do anything about it with MVC4. Sep 16, 2012 at 10:44
  • 1
    @Nick: has the situation changed at all? I've already commented on Kevin's answer, below, but a couple of dupes popped up recently, both here on Meta Stack Exchange (meta.stackexchange.com/questions/307294/…) and over on meta.SO (meta.stackoverflow.com/questions/363741/…). Feb 23, 2018 at 11:59
  • Could we at the very least make the error page include a "Try again" link with the intended URL so that people don't need to hand-edit the URL or retrace their navigation steps?
    – jamesdlin
    Jun 28, 2018 at 18:42

3 Answers 3

5

For modern browsers, maybe window.history.pushState can help? On the client side, in the HTML:

<script>
  window.history.pushState(null, 'Oops! Something Bad Happened!', '/')
</script>

This would change the URL as shown in the location bar into that of the homepage, without reloading the current page. Hence: the error page would still be shown, but when refreshing the browser, the homepage would be loaded instead.

I don't know if this needs relative URLs to be changed (maybe clicking relative URLs now also uses the new URL as the base), but it seems the error page doesn't have any anyway. Also, if the error page originated from a POST, a refresh might be a POST too. To avoid that, one would first need to redirect using GET, to show the error page. And after that fire the JavaScript.

(One can easily try when viewing this very page: just type javascript: in the location bar and paste the above line. For Firefox you'll need Firebug's console instead; Firefox doesn't allow all JavaScript in the location bar anymore.)

3

MVC4 has come and been deployed, but we still don't have a good solution.

It'd be nice to have, but I've got to basically table this for the foreseeable future.

7
  • window.history.pushState(null, 'Oops! Something Bad Happened!', '/') ...?
    – Arjan
    Sep 27, 2012 at 21:15
  • 2
    @Arjan - by the time our code can act we don't have anything about the request beyond the uri; no query strings, no user sessions, nada. It's hard to recover reasonably in the face of an arbitrary error there, we'd be GET'ing things that were originally POST'd, refreshing things that couldn't possibly work (due to missing parameters) and all sorts of fun there. I'd rather reliably broken than flakily fixed. Sep 27, 2012 at 21:18
  • The above snippet would indeed not keep the URL that caused the error (though the aspxerrorpath=/ suggests you might actually know that), but make a refresh show the homepage instead. I'd like that much better than the current behaviour? Or maybe indeed a browser refresh might be a POST if the error originated from a POST? Then more JavaScript would be needed to first redirect to the error page one more time...
    – Arjan
    Sep 27, 2012 at 21:21
  • (But if "the foreseeable future" has a more robust solution then surely we can wait; I don't see too many errors at all!)
    – Arjan
    Sep 27, 2012 at 21:22
  • 6
    Out of curiosity now that we're in 2018, some five and a half years later, has the situation changed, given that there are now two (potential) dupes of this request: meta.stackexchange.com/questions/307294/… and meta.stackoverflow.com/questions/363741/… Feb 23, 2018 at 11:57
  • 1
    foreseeable future is 6 to 8 weeks. Replace weeks by years and it looks like we are entering the time window very soon ;)
    – Pac0
    Feb 24, 2018 at 10:12
  • I know I have handled that on MVC 4 and 5 sites (IIS hosted), in such a way that my users were never redirected to an error page but always stayed on the failing one. It was requiring a mix of IIS configuration, Asp.Net configuration and a custom handle error attribute, but it was doable. I do not have anymore the details since I am not working with such a setup currently (and I do never take with me things I have done at previous employers).
    – Frédéric
    Feb 25, 2018 at 20:40
1

This seems to have been .

In the last few months, when I've gotten a server error, I've noticed that the URL is the same as what I was trying to load, rather than of the form /error?aspxerrorpath=[...]. An easy case to reproduce is this link. Refreshing the page would thus lead to the actual page being loaded rather than the same error page.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .