Bug #5737: WEBrick doesn't support keep alive connections for 204 and 304 responses

• Status: Closed
• Assignee: normalperson (Eric Wong)
• Target version: -
• ruby -v: ruby 2.0.0dev (2011-12-07 trunk 33966) [x86_64-darwin11.2.0]
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN

[tenderlovemaking (Aaron Patterson)]

WEBrick doesn't support keep alive connections for 204 and 304 responses. If a 204 or 304 response is made along with a keepalive, a warning is issued and webrick closes the connection.

I've attached a patch that fixes the problem, and I will apply it if it's OK. :-)

[tenderlovemaking (Aaron Patterson)]

• Status changed from Open to Closed
• % Done changed from 0 to 100

Applied this in r34023

[nahi (Hiroshi Nakamura)]

• Status changed from Closed to Open

Sorry for not responding.

As a maintainer, I'll review the patch later. I don't understand now, the rationale why we should do keep-alive for 304/204 even if the response is neither chunked nor having content-length. Handling empty body would be needed instead?

On Tue, Dec 13, 2011 at 10:35:16AM +0900, Hiroshi Nakamura wrote:

Issue #5737 has been updated by Hiroshi Nakamura.

Status changed from Closed to Open

Sorry for not responding.

As a maintainer, I'll review the patch later. I don't understand now, the rationale why we should do keep-alive for 304/204 even if the response is neither chunked nor having content-length. Handling empty body would be needed instead?

The problem is that even if you specify a content length, webrick will
remove it:

https://github.com/ruby/ruby/blob/trunk/lib/webrick/httpresponse.rb#L186-189

So if you want to do keep-alive, even if you add a content length, you
will always get a warning. RFC2616 Section 4.4 says:

1.Any response message which "MUST NOT" include a message-body (such
  as the 1xx, 204, and 304 responses and any response to a HEAD
  request) is always terminated by the first empty line after the
  header fields, regardless of the entity-header fields present in
  the message

I think this means that clients will know the length of the body, and
clients can support keep-alive connections with no content-length for
these types of responses.

--
Aaron Patterson
http://tenderlovemaking.com/

[naruse (Yui NARUSE)]

Hiroshi Nakamura wrote:

As a maintainer, I'll review the patch later.
I don't understand now, the rationale why we should do keep-alive for 304/204
even if the response is neither chunked nor having content-length.
Handling empty body would be needed instead?

Why don't you use keep-alive though the best scenario of keep-alive benefit
such as 304 and 204?
And as RFC says, it is not "empty body", it doesn't have body.

Anyway as Aaron said in [ruby-core:41624],
RFC 2616 (Section 4.4 Message Length) insists that servers should
treat specially on the case of 1xx, 204, and 304.
http://tools.ietf.org/html/rfc2616#section-4.4

HTTPbis is the work trying to revise the HTTP spec.
http://tools.ietf.org/wg/httpbis/

It describes the more detailed Message-Body logic.

Moreover for the case of 304 (Not Modified), it should return content-length:

In the
case of a 304 (Not Modified) response to a GET request, Content-
Length indicates the size of the payload body (not including any
potential transfer-coding) that would have been sent in a 200 (OK)
response.
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-17#section-8.2

[drbrain (Eric Hodel)]

RFC 2616 section 8.1.2.1 states:

In order to remain persistent, all messages on the connection MUST have a self-defined message length (i.e., one not defined by closure of the connection), as described in section 4.4.

204 and 304 responses meet this requirement so should persist the connection.

[ko1 (Koichi Sasada)]

• Category set to lib
• Assignee set to nahi (Hiroshi Nakamura)

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Assigned

[mame (Yusuke Endoh)]

• Assignee changed from nahi (Hiroshi Nakamura) to normalperson (Eric Wong)

Looks to me we don't have to keep this ticket open, but just in case, I reassign this to the current maintainer of WEBrick.
@normalperson (Eric Wong), could you check this ticket?

[normalperson (Eric Wong)]

[e-mail] wrote:

Looks to me we don't have to keep this ticket open, but just in case, I reassign this to the current maintainer of WEBrick.
@normalperson (Eric Wong), could you check this ticket?

Right, this was already committed in r34024
(0cbec6027cfb755972f80aab57920008d50fe842)

[jeremyevans0 (Jeremy Evans)]

• Status changed from Assigned to Closed