Norman Gray writes:
> But what happens in this case (the my-app/error case in my example) is
> that the (server) program keeps going but the client stalls. The
> unexpected error in the response-output procedure is caught, and (as
> far as I can see) handled by killing the producer thread _with
I'm assuming chunked Transfer-Encoding, which is IIRC what the Racket web
server uses for unknown-length payloads. If the server hasn't committed to
chunked encoding (by sending the header), then it probably hasn't sent the
status code either. So truncation is definitely detectable.
RFC 7230 Secti
Ryan and Matthew, hello.
On 25 May 2020, at 19:43, Ryan Culpepper wrote:
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
AFAICT this is the intended behavior. To me it is consistent with the usual
policy: an uncaught error stops the program. If you want the program to keep
running, then you have to catch the error and make other arrangements. All my
servlet routes are surrounded by a top-level `with-handlers` bloc
Greetings.
I define a custom exception:
(define-struct (my-exception exn:fail) ())
(define (my-error fmt . args)
(let ((msg (apply format (cons fmt args
(raise (my-exception msg (current-continuation-marks)
The plan is that I can throw this within a servlet, and
5 matches
Mail list logo
