[racket-users] http response 204 (no content) with content-encoding "gzip"

['John Clements' via Racket Users]

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-”
  #"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 # 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.

Re: [racket-users] http response 204 (no content) with content-encoding "gzip"

[Greg Hendershott]

Certain status codes "MUST NOT" include a response body, including 204 [0].

For those, you could say not even a `peek-byte` is necessary. Although
I guess there wouldn't be any harm.

Definitely for the other variants -- even "SHOULD NOT" -- then
peek-byte makes sense.


[0]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html


On Wed, Sep 2, 2015 at 1:15 PM, 'John Clements' via Racket Users
 wrote:
> 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-”
>   #"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 # 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.

-- 
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.

Re: [racket-users] http response 204 (no content) with content-encoding "gzip"

['John Clements' via Racket Users]

> On Sep 2, 2015, at 1:38 PM, Greg Hendershott  
> wrote:
> 
> Certain status codes "MUST NOT" include a response body, including 204 [0].
> 
> For those, you could say not even a `peek-byte` is necessary. Although
> I guess there wouldn't be any harm.
> 
> Definitely for the other variants -- even "SHOULD NOT" -- then
> peek-byte makes sense.

Okay, I’ve made a (3-line) pull request. Jay, are you the right one to take a 
look at this?

John

> 
> 
> [0]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
> 
> 
> On Wed, Sep 2, 2015 at 1:15 PM, 'John Clements' via Racket Users
>  wrote:
>> 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-”
>>  #"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 # 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.



-- 
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.