Bug #5737

WEBrick doesn't support keep alive connections for 204 and 304 responses

Added by Aaron Patterson over 3 years ago. Updated about 3 years ago.

[ruby-core:41581]
Status:Assigned
Priority:Normal
Assignee:Hiroshi Nakamura
ruby -v:ruby 2.0.0dev (2011-12-07 trunk 33966) [x86_64-darwin11.2.0] Backport:

Description

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

204_304_keep_alive.patch Magnifier (1.79 KB) Aaron Patterson, 12/10/2011 09:46 AM

noname (500 Bytes) Anonymous, 12/13/2011 12:23 PM


Related issues

Duplicated by Ruby trunk - Bug #5758: webrickのhttpresponseについて Closed 12/14/2011

History

#1 Updated by Aaron Patterson over 3 years ago

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

Applied this in r34023

#2 Updated by Hiroshi Nakamura over 3 years ago

  • 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?

#3 Updated by Anonymous over 3 years ago

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/

#4 Updated by Yui NARUSE over 3 years ago

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

#5 Updated by Eric Hodel over 3 years ago

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.

#6 Updated by Koichi Sasada about 3 years ago

  • Assignee set to Hiroshi Nakamura
  • Category set to lib

#7 Updated by Shyouhei Urabe about 3 years ago

  • Status changed from Open to Assigned

Also available in: Atom PDF