4 ms·

> In fact, we have yet to receive a single complaint regarding our multipart form posts resulting in actual browser navigation. Just out of curiosity, how do y

by diggan 3y ago

> In fact, we have yet to receive a single complaint regarding our multipart form posts resulting in actual browser navigation. Just out of curiosity, how do you handle errors, specifically timeouts here? I'm guessing the HTTP server serves a custom error page, does it have a reference to the previous page with all the data they tried to submit and so on? Probably how I would have handled it. Timeouts are a bit trickier, as the user would just see the browser error page and dassit. Nice thing with decoupling server responses from what the browser actually renders is that you can handle things like that exactly like how you (as a developer) want to, without breaking the current page. But, as always, it depends. Seems you folks are giving your users a lot of value from whatever you're doing regardless, so seems what you're doing is working :) Congrats.

chrismorgan 3y ago
Such error handling is easier, because it’s a normal part of the flow, rather than a separate path that’s not tested. If submitting fails to load the page, you get the normal browser error page and reload, submitting it again. And that’s what you want it to be, unless you can actively do something else in the meantime (which is still a good deal more complex and not typically supported by web apps). By contrast, my experience says that scripting-based submission is very flimsy in the presence of unreliable network. It’s crazy just how many things enter broken, unrecoverable states because it didn’t occur to the authors that maybe that fetch could fail, and maybe you might want to try again. Or worse, and practically never handled properly, when network conditions lead to a stuck request, where the client is waiting for something that will never come. In the browser, you just press F5/Ctrl+R/⌘R when you recognise this situation, but when scripting-powered the only way of fixing this may be briefly toggling the network adapter in order to kill the request (because you can’t just reload the page because you’d lose in-page form state, another of these things that the browser gives you for free but scripting plays havoc with, though Firefox is best at compensating), and hoping that leads the page to let you submit again. Seriously, scripting-based submission, navigation, &c. is reimplementing a lot of what the browser give you for free, and it can’t be done perfectly (e.g. tab loading indicator) and what is reimplemented is absolutely never as flawless as possible. Yes, you get some interesting advantages, but you lose a lot too, more than developers tend to admit.
- ivan_gammel 3y ago
  >In the browser, you just press F5/Ctrl+R/⌘R Many users have no idea what does that mean and will just panic seeing the default error page. They will not read the message there and either will abandon the form, reach customer support or will restart their flow. You are absolutely right about the complexity of the form submission when network problems are taken into account, but default browser behavior isn't the best solution.
  - chrismorgan 3y ago
    I suspect (though perhaps I’m naively optimistic) you may be doing the affected users an injustice. Most people will either practically never experience these error pages, or be familiar with them and their causes because they know their internet connection is dodgy at times. And the “Try Again” button’s pretty clear.
    - ivan_gammel 3y ago
      You will be indeed very optimistic to assume that generic „Try again“ is clear to everyone. In some cases the effects of it are unclear even to power users and they won’t click it. Let’s say I have got timeout page after clicking the final button in the checkout process: how do I know that it won’t place the order twice if I submit again? How do I know that it will submit it again correctly? After all, those timeouts happen often due to server-side delays. Today most people do not encounter those pages, because they interact with SPAs and more likely to encounter different error behavior. Good internet connection won’t prevent anything. Imagine a child accidentally unplugging the wifi router and grandma seeing the timeout page, because her browser doesn’t know that wifi is down. What she would do? This is the kind of situation IT support is dealing with regularly.
bob1029 3y ago
> how do you handle errors, specifically timeouts here? We don't. We are using stateless HTTP semantics throughout. There is no web socket or other streaming abstraction. You can key in a form, come back tomorrow and submit it and the server won't care (assuming business logic checks out). If the system is down at submission time and someone wants to retry after it comes up? No problem. The browser will give you an opportunity to resubmit the form data since the prior POST timed out. This has been a thing since ~forever. The end user experience when the service is completely down is that the browser displays "connection to server timed out" with various initial troubleshooting steps that the vendor manages. Either the server is up and everything works, or it is down and nothing does. Whatever partially-available thing we might be going for doesn't make much sense in my head.

by diggan 3y ago

chrismorgan 3y ago

Such error handling is easier, because it’s a normal part of the flow, rather than a separate path that’s not tested. If submitting fails to load the page, you get the normal browser error page and reload, submitting it again. And that’s what you want it to be, unless you can actively do something else in the meantime (which is still a good deal more complex and not typically supported by web apps). By contrast, my experience says that scripting-based submission is very flimsy in the presence of unreliable network. It’s crazy just how many things enter broken, unrecoverable states because it didn’t occur to the authors that maybe that fetch could fail, and maybe you might want to try again. Or worse, and practically never handled properly, when network conditions lead to a stuck request, where the client is waiting for something that will never come. In the browser, you just press F5/Ctrl+R/⌘R when you recognise this situation, but when scripting-powered the only way of fixing this may be briefly toggling the network adapter in order to kill the request (because you can’t just reload the page because you’d lose in-page form state, another of these things that the browser gives you for free but scripting plays havoc with, though Firefox is best at compensating), and hoping that leads the page to let you submit again. Seriously, scripting-based submission, navigation, &c. is reimplementing a lot of what the browser give you for free, and it can’t be done perfectly (e.g. tab loading indicator) and what is reimplemented is absolutely never as flawless as possible. Yes, you get some interesting advantages, but you lose a lot too, more than developers tend to admit.

ivan_gammel 3y ago
>In the browser, you just press F5/Ctrl+R/⌘R Many users have no idea what does that mean and will just panic seeing the default error page. They will not read the message there and either will abandon the form, reach customer support or will restart their flow. You are absolutely right about the complexity of the form submission when network problems are taken into account, but default browser behavior isn't the best solution.
- chrismorgan 3y ago
  I suspect (though perhaps I’m naively optimistic) you may be doing the affected users an injustice. Most people will either practically never experience these error pages, or be familiar with them and their causes because they know their internet connection is dodgy at times. And the “Try Again” button’s pretty clear.
  - ivan_gammel 3y ago
    You will be indeed very optimistic to assume that generic „Try again“ is clear to everyone. In some cases the effects of it are unclear even to power users and they won’t click it. Let’s say I have got timeout page after clicking the final button in the checkout process: how do I know that it won’t place the order twice if I submit again? How do I know that it will submit it again correctly? After all, those timeouts happen often due to server-side delays. Today most people do not encounter those pages, because they interact with SPAs and more likely to encounter different error behavior. Good internet connection won’t prevent anything. Imagine a child accidentally unplugging the wifi router and grandma seeing the timeout page, because her browser doesn’t know that wifi is down. What she would do? This is the kind of situation IT support is dealing with regularly.

bob1029 3y ago

> how do you handle errors, specifically timeouts here? We don't. We are using stateless HTTP semantics throughout. There is no web socket or other streaming abstraction. You can key in a form, come back tomorrow and submit it and the server won't care (assuming business logic checks out). If the system is down at submission time and someone wants to retry after it comes up? No problem. The browser will give you an opportunity to resubmit the form data since the prior POST timed out. This has been a thing since ~forever. The end user experience when the service is completely down is that the browser displays "connection to server timed out" with various initial troubleshooting steps that the vendor manages. Either the server is up and everything works, or it is down and nothing does. Whatever partially-available thing we might be going for doesn't make much sense in my head.