I’m interacting with an HTTP server that recently responded with status #"HTTP/1.1 204 No Content” and headers
'(#"Content-Encoding: gzip" #"Request-Id: ec2f6fe5-5191-11e5-8007-000000000000” #"X-Influxdb-Version: 0.9.3” #"Date: Wed, 02 Sep 2015 16:44:48 GMT” #"Connection: close”) using http-sendrecv/url with default arguments results in an error (and not a terribly sensible one), because it tries to gunzip the empty input. I conjecture that this is a reasonable response from an HTTP server, and that in this situation http-sendrecv/url (and more specifically http-conn-recv!) should not signal an error, but just return the empty port. In fact, it appears to me that it should probably always be the case that an input port for which peek-byte returns #<eof> should be returned directly rather than being handed off to gunzip. If this seems like the right approach, I’ll make a pull request. Thanks! John -- 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. For more options, visit https://groups.google.com/d/optout.
