Ludo',

I should really send this message in my Drafts folder since 14/4... :-/

On 14/04/17 11:54, Ludovic Courtès wrote:
> Tobias Geerinckx-Rice <me@tobias.gr> skribis:
>> One weird HTTP response from a server will kill ‘guix substitute’:
>> 
>> updating list of substitutes from 'https://foo'... 50.0%Backtrace:
>>  ... guix/ui.scm:1229:8: In procedure run-guix-command: 
>> guix/ui.scm:1229:8: Throw to key `bad-response' with args `("Bad 
>> Response-Line: ~s" (""))'. error: build failed: substituter 
>> `substitute' died unexpectedly
>> 
>> Attached is a patch to ignore such bad responses. The offending 
>> .narinfo will be ignored for that session, and not cached at all. 
>> The result:
> 
> I’m sure you expect this question: what bad responses did you get in 
> practice?  :-)

In fact, not really. The error message looked unambiguous to me: the
HTTP response (the first line returned to the client, e.g. "HTTP/1.1 200
OK") was simply empty, throwing an exception.

Interestingly, a newline seems to be required.

Using http://bad.http.response.tobias.gr as a substitute server triggers
it. http://no.http.response.tobias.gr does not.

> Usually that is a sign of a broken HTTP server.

I think it's actually something in-between me and the server. I'll take
a closer look next time this happens.

> Of course it’s  widespread enough, we’d better handle it, either in 
> Guix or directly in (web client) in Guile;

As I read it, (web client) considers throwing a BAD-RESPONSE exception
the best or only way to deal with an error like this. I agree.

> OTOH, if it’s a genuine problem, we’d better not hide it.

Well, we don't hide it, per se. Hence the error message.

I think throwing an unhandled exception is definitely the wrong thing to
do here — this kills even ‘guix --keep-going --fallback’. I'm less sure
about the right place to do it

Kind regards,

T G-R