On Saturday, May 16, 2020 at 3:16:18 PM UTC-4, Norman Gray wrote: > > [...] > The exception is thrown inside the 'output' procedure > that's provided as the last argument to the 'response' constructor (I > belatedly realise this is probably a bad idea). > [...] > But (a) what should I be doing? And (b) since that exception is caught > in this with-handlers clause, what is it that's producing the (default) > exception output message? And (c) should I expect the client just to > hang here? > > I'm guessing that an answer to (a) is 'avoid throwing exceptions inside > 'output', but given that that will sometimes happen, is the > output-response-body/chunked procedure doing the right thing here? Am I > missing something? >
I think you need to decide when to stream, and when not to stream. In my web framework, most requests involve computing the entire response string prior to calling (response ...), so if an error is encountered, I can send an error response instead of a success response. Currently, the only time I stream a response is when the client is downloading CSV output. In that case, there is little chance of an error occurring once the streaming begins. I just briefly reviewed some HTTP protocol information, and I couldn't find anything that would allow sending a 500 response after the 200 response has already be sent i.e. no way to switch from success to error mid-stream. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/c331d8b9-ce3c-4433-b50f-37432f2a8e3e%40googlegroups.com.
