“Bad Read-Header-Line header: #<eof>” while substituting

DoneSubmitted by Ludovic Courtès.
Details
3 participants
  • Ludovic Courtès
  • Ludovic Courtès
  • Christopher Baines
Owner
unassigned
Severity
serious
L
L
Ludovic Courtès wrote on 15 Mar 15:26 +0100
“Bad Read-Header-Line header: #<e of>” while substituting
(address . bug-guix@gnu.org)
87eeggh4rh.fsf@inria.fr
As reported by a few people on IRC, ‘guix substitute’ sometimes fails ina way that I just experienced (from8154beffd8c121e953a7c4cd75c3eebfcc073a9a):
Toggle snippet (46 lines)downloading from https://ci.guix.gnu.org/nar/gzip/0bji0q5n59595xaqkqrp2gv52lbz55xz-libpng-1.6.37 . libpng-1.6.37 275KiB 11.0MiB/s 00:00 [##################] 100.0%
downloading from https://ci.guix.gnu.org/nar/lzip/h3a5ygxxh4gakhnl53mq7z9b43l8z05g-python-minimal. python-minimal-wrapper-3.8.2 351B 293KiB/s 00:00 [##################] 100.0%
downloading from https://ci.guix.gnu.org/nar/lzip/h8j09yb5d8dh3jffvpzawxslig9bwhdr-freetype-2.10.. freetype-2.10.4 600KiB 3.0MiB/s 00:00 [##################] 100.0%
building /gnu/store/2wfzazqz9g5xizi4vq4pv75nkh1m24bp-perl-5.30.2.drv...Backtrace:In guix/ui.scm: 2164:12 19 (run-guix-command _ . _)In guix/scripts/substitute.scm: 691:2 18 (guix-substitute . _)In unknown file: 17 (with-continuation-barrier #<procedure thunk ()>)In ice-9/boot-9.scm: 1736:10 16 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)In unknown file: 15 (apply-smob/0 #<thunk 7fcb3b3594a0>)In ice-9/boot-9.scm: 1736:10 14 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) 1736:10 13 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) 1731:15 12 (with-exception-handler #<procedure 7fcb3a7c4150 at ice-9/boot-9.scm:1815:7 (exn)> _)In guix/scripts/substitute.scm: 740:17 11 (_) 434:7 10 (process-substitution _ "/gnu/store/ns00dyapjbq9037dwrxa7hc31dvir00n-grub-minimal-2.)In ice-9/boot-9.scm: 1736:10 9 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)In guix/scripts/substitute.scm: 443:9 8 (_)In ice-9/boot-9.scm: 1731:15 7 (with-exception-handler #<procedure 7fcb3a7d37b0 at ice-9/boot-9.scm:1815:7 (exn)> _) 1669:16 6 (raise-exception _ #:continuable? _) 1667:16 5 (raise-exception _ #:continuable? _) 1669:16 4 (raise-exception _ #:continuable? _) 1764:13 3 (_ #<&compound-exception components: (#<&error> #<&irritants irritants: (read-header) 1669:16 2 (raise-exception _ #:continuable? _) 1667:16 1 (raise-exception _ #:continuable? _) 1669:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1669:16: In procedure raise-exception:Bad Read-Header-Line header: #<eof>
This is the kind of issue that ‘with-cached-connection’ as it can beseen in 9158020d7853b6e7925802e0d0a082801c680e8f avoided:
Toggle snippet (23 lines)(define* (call-with-cached-connection uri proc #:optional (open-connection open-connection-for-uri/cached)) (let ((port (open-connection uri))) (catch #t (lambda () (proc port)) (lambda (key . args) ;; If PORT was cached and the server closed the connection in the ;; meantime, we get EPIPE. In that case, open a fresh connection and ;; retry. We might also get 'bad-response or a similar exception from ;; (web response) later on, once we've sent the request, or a ;; ERROR/INVALID-SESSION from GnuTLS. (if (or (and (eq? key 'system-error) (= EPIPE (system-error-errno `(,key ,@args)))) (and (eq? key 'gnutls-error) (eq? (first args) error/invalid-session)) (memq key '(bad-response bad-header bad-header-component))) (proc (open-connection uri #:fresh? #t)) (apply throw key args))))))
I think 7b812f7c84c43455cdd68a0e51b6ded018afcc8e and subsequent commitsmay have caused this regression. In particular, in20c08a8a45d0f137ead7c05e720456b2aea44402,‘call-with-connection-error-handling’ is now used, but that one doesn’tcatch the exceptions mentioned above, in this case ‘bad-header’.
Ludo’.
L
L
Ludovic Courtès wrote on 15 Mar 15:31 +0100
control message for bug #47157
(address . control@debbugs.gnu.org)
87czw0h4j3.fsf@gnu.org
severity 47157 seriousquit
C
C
Christopher Baines wrote on 15 Mar 18:02 +0100
Re: bug#47157: “Bad Read-Header-Line header: #<eof>” while substituting
(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)(address . 47157@debbugs.gnu.org)
871rcgfiz9.fsf@cbaines.net
Ludovic Courtès <ludovic.courtes@inria.fr> writes:
Toggle quote (84 lines)> As reported by a few people on IRC, ‘guix substitute’ sometimes fails in> a way that I just experienced (from> 8154beffd8c121e953a7c4cd75c3eebfcc073a9a):>> --8<---------------cut here---------------start------------->8---> downloading from https://ci.guix.gnu.org/nar/gzip/0bji0q5n59595xaqkqrp2gv52lbz55xz-libpng-1.6.37 .> libpng-1.6.37 275KiB 11.0MiB/s 00:00 [##################] 100.0%>> downloading from https://ci.guix.gnu.org/nar/lzip/h3a5ygxxh4gakhnl53mq7z9b43l8z05g-python-minimal.> python-minimal-wrapper-3.8.2 351B 293KiB/s 00:00 [##################] 100.0%>> downloading from https://ci.guix.gnu.org/nar/lzip/h8j09yb5d8dh3jffvpzawxslig9bwhdr-freetype-2.10..> freetype-2.10.4 600KiB 3.0MiB/s 00:00 [##################] 100.0%>> building /gnu/store/2wfzazqz9g5xizi4vq4pv75nkh1m24bp-perl-5.30.2.drv...> Backtrace:> In guix/ui.scm:> 2164:12 19 (run-guix-command _ . _)> In guix/scripts/substitute.scm:> 691:2 18 (guix-substitute . _)> In unknown file:> 17 (with-continuation-barrier #<procedure thunk ()>)> In ice-9/boot-9.scm:> 1736:10 16 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)> In unknown file:> 15 (apply-smob/0 #<thunk 7fcb3b3594a0>)> In ice-9/boot-9.scm:> 1736:10 14 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)> 1736:10 13 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)> 1731:15 12 (with-exception-handler #<procedure 7fcb3a7c4150 at ice-9/boot-9.scm:1815:7 (exn)> _)> In guix/scripts/substitute.scm:> 740:17 11 (_)> 434:7 10 (process-substitution _ "/gnu/store/ns00dyapjbq9037dwrxa7hc31dvir00n-grub-minimal-2.)> In ice-9/boot-9.scm:> 1736:10 9 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)> In guix/scripts/substitute.scm:> 443:9 8 (_)> In ice-9/boot-9.scm:> 1731:15 7 (with-exception-handler #<procedure 7fcb3a7d37b0 at ice-9/boot-9.scm:1815:7 (exn)> _)> 1669:16 6 (raise-exception _ #:continuable? _)> 1667:16 5 (raise-exception _ #:continuable? _)> 1669:16 4 (raise-exception _ #:continuable? _)> 1764:13 3 (_ #<&compound-exception components: (#<&error> #<&irritants irritants: (read-header)> 1669:16 2 (raise-exception _ #:continuable? _)> 1667:16 1 (raise-exception _ #:continuable? _)> 1669:16 0 (raise-exception _ #:continuable? _)>> ice-9/boot-9.scm:1669:16: In procedure raise-exception:> Bad Read-Header-Line header: #<eof>> --8<---------------cut here---------------end--------------->8--->> This is the kind of issue that ‘with-cached-connection’ as it can be> seen in 9158020d7853b6e7925802e0d0a082801c680e8f avoided:>> --8<---------------cut here---------------start------------->8---> (define* (call-with-cached-connection uri proc> #:optional> (open-connection> open-connection-for-uri/cached))> (let ((port (open-connection uri)))> (catch #t> (lambda ()> (proc port))> (lambda (key . args)> ;; If PORT was cached and the server closed the connection in the> ;; meantime, we get EPIPE. In that case, open a fresh connection and> ;; retry. We might also get 'bad-response or a similar exception from> ;; (web response) later on, once we've sent the request, or a> ;; ERROR/INVALID-SESSION from GnuTLS.> (if (or (and (eq? key 'system-error)> (= EPIPE (system-error-errno `(,key ,@args))))> (and (eq? key 'gnutls-error)> (eq? (first args) error/invalid-session))> (memq key '(bad-response bad-header bad-header-component)))> (proc (open-connection uri #:fresh? #t))> (apply throw key args))))))> --8<---------------cut here---------------end--------------->8--->> I think 7b812f7c84c43455cdd68a0e51b6ded018afcc8e and subsequent commits> may have caused this regression. In particular, in> 20c08a8a45d0f137ead7c05e720456b2aea44402,> ‘call-with-connection-error-handling’ is now used, but that one doesn’t> catch the exceptions mentioned above, in this case ‘bad-header’.
I think the behaviour changed unintentionally with [1], however,thinking about the connection reuse in process-substitution comparedwith http-multiple-get, there's no attempt here to look at if the serverhas specified whether the connection should be closed.
1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f50f5751fff4cfc6d5abba9681054569694b7a5c
Just like http-multiple-get, it's probably worth trying to check theheaders of the response, look at whether the server has indicated thatthe connection should be closed, and if so, close the connection,forcing a new one to be established for future requests.
I haven't tested this theory, but maybe if that happened, then someoccurrences of trying to read a response, and not being able to would beprevented.
-----BEGIN PGP SIGNATURE-----
iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmBPkypfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2JhaW5lcy5uZXQACgkQXiijOwuE9XcL/hAAlXF3sB5OW9jZtO5eGKwDnRqIxQfmSDXaWNEDujhBYdKQCy8rsab5FBhE2A4WoTpHCbDWrRH/eXlPTCSd1Z+FO80zsShvD7O5qtM4vBXZsOCI5Fze+jUEx5P7MCDiszOQ3BSfR2yp43TAD33c6W/Ax20uXklDuSff4CQXNUnYtwItAB1i+LYO1Cde1jIXcUwwx9QJZY77HMaWqdvOkMaLWXYPA/eR/D9k34Er/E0AFbuoLKj0keVs52pVfgwEvVcL5RZDiU9hEB3vPEAyFrnjwY1kjv55UmZlUehu21hK4HVBzuaaJCNENAdUjzYkuaMlMAgjmHMFv2uyBGChq6EIje2XsNN/NGs1gpiC0naNCWxit1FhnymQxfcxlSwnE1WbNLEGulaR4k0BJwC+K4jLW/yuo9iFF64gU7DKxgqeqCXkWID9V6jkoxd3/N0zsrdoqPPx7/n4wHwRpSP/8bJwp5/NHtTmSN42d5OAqOL8dJzBOmxOqkrqJAuiO9AX3IGwnT0fa38mTH0zGemfkHSB+7UFUhET4eRveKz7QIvZeDeCpSRJ485qBbdgdZrr4gEoh5TaM5eZJdiEjrOub1cJVf80OtAn+75YbiJ0O/AxTZg6Ya7bYO/TcZbIzNE6gSTLmLX20f01AjGVXpPklCXmStDTEyMyaDtWOzLyw1b6q1w==w5/u-----END PGP SIGNATURE-----
C
C
Christopher Baines wrote on 15 Mar 20:53 +0100
(address . 47157@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)
87v99sdwh9.fsf@cbaines.net
Christopher Baines <mail@cbaines.net> writes:
Toggle quote (102 lines)> Ludovic Courtès <ludovic.courtes@inria.fr> writes:>>> As reported by a few people on IRC, ‘guix substitute’ sometimes fails in>> a way that I just experienced (from>> 8154beffd8c121e953a7c4cd75c3eebfcc073a9a):>>>> --8<---------------cut here---------------start------------->8--->> downloading from https://ci.guix.gnu.org/nar/gzip/0bji0q5n59595xaqkqrp2gv52lbz55xz-libpng-1.6.37 .>> libpng-1.6.37 275KiB 11.0MiB/s 00:00 [##################] 100.0%>>>> downloading from https://ci.guix.gnu.org/nar/lzip/h3a5ygxxh4gakhnl53mq7z9b43l8z05g-python-minimal.>> python-minimal-wrapper-3.8.2 351B 293KiB/s 00:00 [##################] 100.0%>>>> downloading from https://ci.guix.gnu.org/nar/lzip/h8j09yb5d8dh3jffvpzawxslig9bwhdr-freetype-2.10..>> freetype-2.10.4 600KiB 3.0MiB/s 00:00 [##################] 100.0%>>>> building /gnu/store/2wfzazqz9g5xizi4vq4pv75nkh1m24bp-perl-5.30.2.drv...>> Backtrace:>> In guix/ui.scm:>> 2164:12 19 (run-guix-command _ . _)>> In guix/scripts/substitute.scm:>> 691:2 18 (guix-substitute . _)>> In unknown file:>> 17 (with-continuation-barrier #<procedure thunk ()>)>> In ice-9/boot-9.scm:>> 1736:10 16 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)>> In unknown file:>> 15 (apply-smob/0 #<thunk 7fcb3b3594a0>)>> In ice-9/boot-9.scm:>> 1736:10 14 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)>> 1736:10 13 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)>> 1731:15 12 (with-exception-handler #<procedure 7fcb3a7c4150 at ice-9/boot-9.scm:1815:7 (exn)> _)>> In guix/scripts/substitute.scm:>> 740:17 11 (_)>> 434:7 10 (process-substitution _ "/gnu/store/ns00dyapjbq9037dwrxa7hc31dvir00n-grub-minimal-2.)>> In ice-9/boot-9.scm:>> 1736:10 9 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)>> In guix/scripts/substitute.scm:>> 443:9 8 (_)>> In ice-9/boot-9.scm:>> 1731:15 7 (with-exception-handler #<procedure 7fcb3a7d37b0 at ice-9/boot-9.scm:1815:7 (exn)> _)>> 1669:16 6 (raise-exception _ #:continuable? _)>> 1667:16 5 (raise-exception _ #:continuable? _)>> 1669:16 4 (raise-exception _ #:continuable? _)>> 1764:13 3 (_ #<&compound-exception components: (#<&error> #<&irritants irritants: (read-header)>> 1669:16 2 (raise-exception _ #:continuable? _)>> 1667:16 1 (raise-exception _ #:continuable? _)>> 1669:16 0 (raise-exception _ #:continuable? _)>>>> ice-9/boot-9.scm:1669:16: In procedure raise-exception:>> Bad Read-Header-Line header: #<eof>>> --8<---------------cut here---------------end--------------->8--->>>> This is the kind of issue that ‘with-cached-connection’ as it can be>> seen in 9158020d7853b6e7925802e0d0a082801c680e8f avoided:>>>> --8<---------------cut here---------------start------------->8--->> (define* (call-with-cached-connection uri proc>> #:optional>> (open-connection>> open-connection-for-uri/cached))>> (let ((port (open-connection uri)))>> (catch #t>> (lambda ()>> (proc port))>> (lambda (key . args)>> ;; If PORT was cached and the server closed the connection in the>> ;; meantime, we get EPIPE. In that case, open a fresh connection and>> ;; retry. We might also get 'bad-response or a similar exception from>> ;; (web response) later on, once we've sent the request, or a>> ;; ERROR/INVALID-SESSION from GnuTLS.>> (if (or (and (eq? key 'system-error)>> (= EPIPE (system-error-errno `(,key ,@args))))>> (and (eq? key 'gnutls-error)>> (eq? (first args) error/invalid-session))>> (memq key '(bad-response bad-header bad-header-component)))>> (proc (open-connection uri #:fresh? #t))>> (apply throw key args))))))>> --8<---------------cut here---------------end--------------->8--->>>> I think 7b812f7c84c43455cdd68a0e51b6ded018afcc8e and subsequent commits>> may have caused this regression. In particular, in>> 20c08a8a45d0f137ead7c05e720456b2aea44402,>> ‘call-with-connection-error-handling’ is now used, but that one doesn’t>> catch the exceptions mentioned above, in this case ‘bad-header’.>> I think the behaviour changed unintentionally with [1], however,> thinking about the connection reuse in process-substitution compared> with http-multiple-get, there's no attempt here to look at if the server> has specified whether the connection should be closed.>> 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f50f5751fff4cfc6d5abba9681054569694b7a5c>> Just like http-multiple-get, it's probably worth trying to check the> headers of the response, look at whether the server has indicated that> the connection should be closed, and if so, close the connection,> forcing a new one to be established for future requests.>> I haven't tested this theory, but maybe if that happened, then some> occurrences of trying to read a response, and not being able to would be> prevented.
I've now actually got around to testing this, I'm no expert at runningthe substitute script manually without the guix-daemon, but I gave it ago, using a local NGinx instance which just allowed two requests perconnection.
With these changes [2], connections were closed when appropriate and anew one is established when the next nar is fetched.
2: https://issues.guix.gnu.org/47174
When testing using the same approach with master, I get this exception[3], so either I'm doing something wrong, or this isn't a circumstanceunder which there can be a bad-header issue. Regardless, I'm not surewhat's going on with this exception below.
3:ice-9/boot-9.scm:1669:16: In procedure raise-exception:Wrong number of values returned to continuation (expected 2)
-----BEGIN PGP SIGNATURE-----
iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmBPu1JfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2JhaW5lcy5uZXQACgkQXiijOwuE9Xfh+w/9EbWSWeht2vYbWh/5lPi5itYR2PABmcKHJTe26bliASrUcDCuYEpL531rahykntPMAwQinJXf7Lx5gfWJquVuw74u+XhWOee9bOcqxsN+UPLuXXOVa6I+ExN9pdUG4csuRMbJDHM9TGCZsMC/rvFv+olVRUBWO7AixMJcsJklo9w6pMhlaI6ar5ytGC7aOxbUZP57EGuwqofcKMt4Yv0MvmpeYdMPupy2lf/SnCQ4guojZ/4JQqCJtm0164StGKbILdvTAmD0SNSv9P6f1lFwqIiHHHoFuEUCfIxBRt2blDd7LAqbWzvLzK3hUtGGXCKGNVXVOCO8EjDtxU9sUxchSvUb9yhms+dOgfBO07UA7s1AeqpJGzx88K6Rpsk4/esy7IACS1k8RPt38Dxp98VVj+TwAB7pg18ug985OhK/GLSRMz/efpAcRw9g1PCnmodN0Yco0+ekaYnAT0iPWmK+XyNCU3JALFmuaks+qVDWJIuFUtSVLOeoF2H6lZoxkHE0JLFW2Z2WbZipooNZQgIPLhzovOWf0yNvw1zXSnjVqKQb3FxA0k8YygoWVfLVJvxKFam9+S1QbWaGR0MpcjmlzhkYEueMp3UtkVsOqrA2+TDN589LBVSnmTEfxN2nyHVPb57iz1mVTPWeLY76h7D/Rsf3STEiZCxpfSkzfjyZWhY==Fb25-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 15 Mar 21:30 +0100
(name . Christopher Baines)(address . mail@cbaines.net)(address . 47157@debbugs.gnu.org)
87a6r4cg88.fsf@gnu.org
Christopher Baines <mail@cbaines.net> skribis:
Toggle quote (18 lines)>> I think 7b812f7c84c43455cdd68a0e51b6ded018afcc8e and subsequent commits>> may have caused this regression. In particular, in>> 20c08a8a45d0f137ead7c05e720456b2aea44402,>> ‘call-with-connection-error-handling’ is now used, but that one doesn’t>> catch the exceptions mentioned above, in this case ‘bad-header’.>> I think the behaviour changed unintentionally with [1], however,> thinking about the connection reuse in process-substitution compared> with http-multiple-get, there's no attempt here to look at if the server> has specified whether the connection should be closed.>> 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f50f5751fff4cfc6d5abba9681054569694b7a5c>> Just like http-multiple-get, it's probably worth trying to check the> headers of the response, look at whether the server has indicated that> the connection should be closed, and if so, close the connection,> forcing a new one to be established for future requests.
I think that’s not enough because we can’t rely on the server’s stateintent here.
For example, you have a keep-alive connection that you keep in cache.Minutes later, you come back and send a request over that port. If theserver dropped the connection in the meantime, that can manifest in anyof the ways we’ve seen: 'bad-response when attempting to read theresponse, some 'gnutls-error, 'system-error and EPIPE, etc. There’s noway to determine in advance whether the socket is fine.
That’s why the initial approach was to wrap all the call sites were thesocket was known to be possibly “tainted” in ‘with-cached-connection’.
Toggle quote (5 lines)> I've now actually got around to testing this, I'm no expert at running> the substitute script manually without the guix-daemon, but I gave it a> go, using a local NGinx instance which just allowed two requests per> connection.
I believe in this case ‘port-closed?’ returns true because thesocket/TLS record port got closed right at the end of the response, soit’s the “easy” case; I don’t think it captures the situation Idescribed above where an error comes up later while trying to writeto/read from the port.
Ludo’.
C
C
Christopher Baines wrote on 15 Mar 21:37 +0100
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 47157@debbugs.gnu.org)
87sg4wdugg.fsf@cbaines.net
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (44 lines)> Christopher Baines <mail@cbaines.net> skribis:>>>> I think 7b812f7c84c43455cdd68a0e51b6ded018afcc8e and subsequent commits>>> may have caused this regression. In particular, in>>> 20c08a8a45d0f137ead7c05e720456b2aea44402,>>> ‘call-with-connection-error-handling’ is now used, but that one doesn’t>>> catch the exceptions mentioned above, in this case ‘bad-header’.>>>> I think the behaviour changed unintentionally with [1], however,>> thinking about the connection reuse in process-substitution compared>> with http-multiple-get, there's no attempt here to look at if the server>> has specified whether the connection should be closed.>>>> 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f50f5751fff4cfc6d5abba9681054569694b7a5c>>>> Just like http-multiple-get, it's probably worth trying to check the>> headers of the response, look at whether the server has indicated that>> the connection should be closed, and if so, close the connection,>> forcing a new one to be established for future requests.>> I think that’s not enough because we can’t rely on the server’s state> intent here.>> For example, you have a keep-alive connection that you keep in cache.> Minutes later, you come back and send a request over that port. If the> server dropped the connection in the meantime, that can manifest in any> of the ways we’ve seen: 'bad-response when attempting to read the> response, some 'gnutls-error, 'system-error and EPIPE, etc. There’s no> way to determine in advance whether the socket is fine.>> That’s why the initial approach was to wrap all the call sites were the> socket was known to be possibly “tainted” in ‘with-cached-connection’.>>> I've now actually got around to testing this, I'm no expert at running>> the substitute script manually without the guix-daemon, but I gave it a>> go, using a local NGinx instance which just allowed two requests per>> connection.>> I believe in this case ‘port-closed?’ returns true because the> socket/TLS record port got closed right at the end of the response, so> it’s the “easy” case; I don’t think it captures the situation I> described above where an error comes up later while trying to write> to/read from the port.
Yeah, of course, I think error handling is needed as well, it justoccurred to me when looking at this issue and the relevant code.
-----BEGIN PGP SIGNATURE-----
iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmBPxZBfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNFODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2JhaW5lcy5uZXQACgkQXiijOwuE9XeivA//WjkDgeggXZKfZyzacELl6b7tcx0BS2Ql7ZaubFvK0Y2rFwEfBUsmCAhTtOsfh/+Q+PsaekXSMxrhUV7greS7LLesrFCbvidrn+sWmQ5M6sj/+pp5bh/Xk3VKJiy3bC2bjGzskxt2LJq8c/Nxw9hZpg8qsGwZSqI3TU0r/nmvh8B+7OuQ4zjBtLGM3uF3H1GTdqnfQyQr4B+K5HmYlk3YECegdRcyJy0nOedztwAIBrJrXFYqsQTS9GmQfg8EnMb+T7c+jXUptFDniKJPLhGldfV2NrBNqhjYw+sRsKwX1XEwgzhii7AxUPNI2xUeu2RorZgHjIwYRlMh82GNEMz5VP0mYx3kbVrCdBhcHvqlELuaK+21uv4g6mg+VPUTvjCdPuDWimdZ2MJX3GaACQk7ed+8erb2zn+0YH91i+yLxlCFwoF9YHIhNsrmFLc7IvxZzsl5FSDQyfS56xsHvbreqWW8d0OfJ6GYXFaf0oNY8TMVC2yy28mOBKvJQTeGxdaJAORmfNOrA4Rl52oVgNuiWnGzpkg/yRdmHYdbXTVzHYzf2byvlwOwot7JBaSPxHGPzbl4KglOCb2RxwpM0luEtce2CwK3uVprvt1afnrW4kUPJeGXnkVmyKbinioMuQ9AV9VBZfDrO7VrHurcQd3xDJ/CcLnF8nUXv9WqaGi8iCE==A6Tc-----END PGP SIGNATURE-----
L
L
Ludovic Courtès wrote on 18 Mar 17:04 +0100
(name . Christopher Baines)(address . mail@cbaines.net)(address . 47157-done@debbugs.gnu.org)
8735wsmos2.fsf@gnu.org
This should now be fixed by c37e3b92ad0334ba2fe7ee4e98631f0a4edeee21.
Thanks, Chris!
Ludo’.
Closed
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 47157@debbugs.gnu.org