# Mysterious Content-Length: 0

**URL:** <https://www.ruby-forum.com/t/mysterious-content-length-0/127485>\
**Category:** Rails\
**Created:** [January 29, 2008, 6:43pm UTC](https://www.ruby-forum.com/t/mysterious-content-length-0/127485 "2008-01-29T18:43:05Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![fxn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/77aa72/32.png) [@fxn](https://www.ruby-forum.com/u/fxn)\
**Post date:** [January 29, 2008, 6:43pm UTC](https://www.ruby-forum.com/t/mysterious-content-length-0/127485/1 "2008-01-29T18:43:05Z")

</div>

I am lost here. I have a very simple action:

```
# DELETE /bookings/{id}
def destroy
  adapter = adapter_for(@booking.chain_id)
  adapter.cancel(@booking)
  if @booking.update_attribute(:cancelled, true)
    head :no_content
  else
    raise BookingGatewayError::SuccessfulButUnregistered
  end
end

```

that returns a 204 if successful. In all my trials and in hello world  
applications I’ve done to debug this the Content-Length is 1 (you know  
Rails unconditionally sends a space as a workaround for Safari):

```
HTTP/1.1 204 No Content
Connection: close
Date: Tue, 29 Jan 2008 18:05:16 GMT
Status: 204 No Content
X-Runtime: 0.00507
Cache-Control: no-cache
Server: Mongrel 1.1.3
Content-Type: text/html; charset=utf-8
Content-Length: 1

```

but same rails in vendor, same mongrel, same everything I can think of  
gives a 0 in the production server:

```
HTTP/1.1 204 No Content
Date: Tue, 29 Jan 2008 18:20:07 GMT
Server: Mongrel 1.1.3
Status: 204 No Content
X-Runtime: 0.09667
Cache-Control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 0

```

What could explain that 0?

– fxn

---

<div class="post-metadata">

**Author:** ![fxn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/77aa72/32.png) [@fxn](https://www.ruby-forum.com/u/fxn)\
**Post date:** [January 29, 2008, 7:17pm UTC](https://www.ruby-forum.com/t/mysterious-content-length-0/127485/2 "2008-01-29T19:17:58Z")

</div>

On Jan 29, 6:40 pm, Xavier N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

There’s nothing like explaining something to find it out.

I’ve remembered in production mod\_proxy is running and it isn’t in  
development or in the rest of the trials. I could reproduce it that  
way, looks like the Apache module is ignoring that somehow. Perhaps it  
ignores the response body altogether because it is a 204? I’ll try to  
continue figuring out what’s up with mod\_proxy, but at least I have a  
hint now.

This is relevant because it means if you are behind mod\_proxy the  
workaround is nullified.

– fxn