Project

General

Profile

Actions

Bug #5737

closed

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

Added by tenderlovemaking (Aaron Patterson) over 12 years ago. Updated over 4 years ago.

Status:
Closed
Target version:
-
ruby -v:
ruby 2.0.0dev (2011-12-07 trunk 33966) [x86_64-darwin11.2.0]
[ruby-core:41581]

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


Files

204_304_keep_alive.patch (1.79 KB) 204_304_keep_alive.patch tenderlovemaking (Aaron Patterson), 12/10/2011 09:46 AM
noname (500 Bytes) noname Anonymous, 12/13/2011 12:23 PM

Related issues 1 (0 open1 closed)

Has duplicate Ruby master - Bug #5758: webrickのhttpresponseについてClosed12/14/2011Actions

Updated by tenderlovemaking (Aaron Patterson) over 12 years ago

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

Applied this in r34023

Updated by nahi (Hiroshi Nakamura) over 12 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?

Updated by Anonymous over 12 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/

Updated by naruse (Yui NARUSE) over 12 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 [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

Updated by drbrain (Eric Hodel) over 12 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.

Actions #6

Updated by ko1 (Koichi Sasada) about 12 years ago

  • Category set to lib
  • Assignee set to nahi (Hiroshi Nakamura)
Actions #7

Updated by shyouhei (Shyouhei Urabe) about 12 years ago

  • Status changed from Open to Assigned

Updated by mame (Yusuke Endoh) over 5 years ago

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

Updated by normalperson (Eric Wong) over 5 years ago

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)

Actions #10

Updated by jeremyevans0 (Jeremy Evans) over 4 years ago

  • Status changed from Assigned to Closed
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0