suzanne.soy/racket
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Ignoring some bad network errors re Robby

Browse Source
This commit is contained in:
Jay McCarthy 2013-04-29 13:20:24 -06:00
parent bbd24edb54
commit 4b84fc7b48
1 changed files with 45 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

82
collects/web-server/private/dispatch-server-unit.rkt
View File

@ -73,40 +73,48 @@
(define conn (define conn
(new-connection config:initial-connection-timeout (new-connection config:initial-connection-timeout
ip op (current-custodian) #f)) ip op (current-custodian) #f))
;; HTTP/1.1 allows any number of requests to come from this input (with-handlers
;; port. However, there is no explicit cancellation of a ([(λ (x)
;; connection---the browser will just close the port. This leaves ;; This error is "Connection reset by peer" and doesn't
;; the Web server in the unfortunate state of config:read-request ;; really indicate a problem with the server.
;; trying to read an HTTP and failing---with an ugly error (and (exn:fail:network:errno? x)
;; message. This call to peek here will block until at least one (= 54 (exn:fail:network:errno-errno x))))
;; character is available and then transfer to read-request. At (λ (x)
;; that point, an error message would be reasonable because the (kill-connection! conn))])
;; request would be badly formatted or ended early. However, if ;; HTTP/1.1 allows any number of requests to come from this input
;; the connection is closed, then peek will get the EOF and the ;; port. However, there is no explicit cancellation of a
;; connection will be closed. This shouldn't change any other ;; connection---the browser will just close the port. This leaves
;; behavior: read-request is already blocking, peeking doesn't ;; the Web server in the unfortunate state of config:read-request
;; consume a byte, etc. ;; trying to read an HTTP and failing---with an ugly error
(define the-evt ;; message. This call to peek here will block until at least one
(choice-evt ;; character is available and then transfer to read-request. At
(handle-evt ;; that point, an error message would be reasonable because the
(port-closed-evt ip) ;; request would be badly formatted or ended early. However, if
(λ (res) ;; the connection is closed, then peek will get the EOF and the
(kill-connection! conn))) ;; connection will be closed. This shouldn't change any other
(handle-evt ;; behavior: read-request is already blocking, peeking doesn't
(peek-bytes-evt 1 0 #f ip) ;; consume a byte, etc.
(λ (res) (define the-evt
(cond (choice-evt
[(eof-object? res) (handle-evt
(kill-connection! conn)] (port-closed-evt ip)
[else (λ (res)
(define-values (kill-connection! conn)))
(req close?) (handle-evt
(config:read-request conn config:port port-addresses)) (peek-bytes-evt 1 0 #f ip)
(set-connection-close?! conn close?) (λ (res)
(config:dispatch conn req) (cond
(if (connection-close? conn) [(eof-object? res)
(kill-connection! conn) (kill-connection! conn)]
(connection-loop))]))))) [else
(define (connection-loop) (define-values
(sync the-evt)) (req close?)
(connection-loop)) (config:read-request conn config:port port-addresses))
(set-connection-close?! conn close?)
(config:dispatch conn req)
(if (connection-close? conn)
(kill-connection! conn)
(connection-loop))])))))
(define (connection-loop)
(sync the-evt))
(connection-loop)))