As I understand the HTTP protocol (that is, some but not lots), the most reasonable thing for the server to do if it discovers an error after the status code has been sent seems to be to just hang up and let the client realize that *something* went wrong. I don't mean just truncate the output; I mean the server should say "here comes another chunk" and then close the TCP connection, so it cannot be mistaken for a valid response. (The servlet should probably make a note so the next request doesn't just fail in exactly the same way.)
Is there are reason not to change the web server to do this automatically? Ryan On Mon, May 25, 2020 at 7:30 PM Norman Gray <norman.g...@glasgow.ac.uk> wrote: > > Thank you, Brian and Jesse, for your thoughts on this. There may still > be an exception problem here, though. > > (and sorry for being sluggish to respond) > > On 16 May 2020, at 20:16, Norman Gray wrote: > > > Now, in tracking this down I can see that I have a wrong design here: > > the servlet has started producing output before the exception is > > thrown, so it's at this point really too late for me to be throwing > > errors and producing custom 5xx error pages. > > Brian said: > > > 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. > > and Jesse: > > > I suggest thinking of a servlet as a response builder, and, if > > possible, to > > delegate serialization of the response (output-response & friends) > > till > > after a response? value has been created. > > I agree this is the right way of thinking about things here, and it's > reassuring to have that confirmed. Part of what was confusing me was > that it's not particularly clear from the documentation what > serve/servlet's #:servlet-responder is there for. It appears to be just > an odd spelling of 'exception handler', as far as I can tell from the > code. > > Indeed it's true that, once the HTTP status code has hit the wire, > there's no provision in the protocol to change one's mind and come up > with a different status (it's possible that forthcoming HTTP/3, with its > concern to multiplex content on the wire, will come up with something > here, but I haven't examined HTTP/3 in detail, and I'd be surprised if > this was one of its concerns). > > However, a problem comes when the serialiser _does_ produce a 'real' > exception -- meaning an exception that isn't one that I expected it to > produce. In that case, the response.rkt code just hangs. > > Consider: > > #lang racket/base > (require web-server/servlet > web-server/servlet-env) > > (define (make-response/output writer) > (λ (req) > (response 200 #"OK" (current-seconds) #"text/plain" '() > writer))) > > (define my-app/simple > (make-response/output > (λ (op) > (display "hello" op)))) > (define my-app/error > (make-response/output > (λ (op) > (error "Oooops") > (display "Hello" op)))) > (define my-app/handlers > (make-response/output > (λ (op) > (with-handlers ((exn:fail? (λ (ex) (display "Eeek!" op)))) > (error "Oooops") > (display "Hello" op))))) > > (serve/servlet my-app/error > #:servlet-regexp #rx"" > #:command-line? #t) > > If we run this server, and dereference <http://localhost:8000/>, for > example with curl, then the retrieval simply hangs. > > It appears that the handler in > web-server-lib/web-server/response.rkt:148 is supposed to handle this > case, but it appears not to. I think it's possible the handler should > be in to-chunker-t instead or as well. > > This means that a further possibility is to have an exception handler > within the serialiser, and handle exceptions appropriately there (as in > my-app/handlers above). However all this means that a carefully-written > servlet _must_ have such handlers, if an inadvertent exception in the > serialiser procedure isn't to stall a client. > > Best wishes, > > Norman > > > -- > Norman Gray : https://nxg.me.uk > SUPA School of Physics and Astronomy, University of Glasgow, UK > > -- > 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/AB2357DF-5A41-429F-A7BB-7B4321EEDBE3%40glasgow.ac.uk > . > -- 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/CANy33qmudUR7KrmjR1v57QfPnanjaUeO-OybCFXWeJr-eNdVMQ%40mail.gmail.com.
