[ruby-core:63382] [ruby-trunk - Bug #9986] WEBrick content-length being set when transfer-encoding is chunked

Issue #9986 has been updated by Leonard Garvey.


I don't believe this is a duplicate of #9927. This occurs if you're not iss=
uing a HEAD request and affects Safari with standard rack applications whic=
h use the Rack::Chunked middleware.

~~~
=E1=90=85 curl -i http://localhost:8000
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Server: WEBrick/1.3.1 (Ruby/2.1.2/2014-05-08)
Date: Sat, 28 Jun 2014 01:50:46 GMT
Content-Length: 26
Connection: Keep-Alive

Hello world%
~~~

Which can be replicated with the following webrick server:

~~~
require 'webrick'

server =3D WEBrick::HTTPServer.new :Port =3D> 8000

server.mount_proc '/' do |req, res|
  res.status      =3D 200
  res.chunked     =3D false
  res["Transfer-Encoding"] =3D 'chunked'
  res.body =3D "5\r\nHello\r\n6\r\n world\r\n0\r\n\r\n"
end

trap 'INT' do server.shutdown end
server.start
~~~


Note that this response includes the both the Transfer-Encoding: chunked he=
ader and the Content-Length header. This (to my understanding) is against R=
FC2616 Section 4(http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html) alt=
hough I'd agree that Safari is also not complying with the spec too:=20

> Messages MUST NOT include both a Content-Length header field and a non-id=
entity transfer-coding. If the message does include a non- identity transfe=
r-coding, the Content-Length MUST be ignored.



----------------------------------------
Bug #9986: WEBrick content-length being set when transfer-encoding is chunk=
ed
https://bugs.ruby-lang.org/issues/9986#change-47426

* Author: Leonard Garvey
* Status: Rejected
* Priority: Normal
* Assignee: Hiroshi Nakamura
* Category: lib
* Target version:=20
* ruby -v: trunk, ruby 2.1.2p95
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
It's possible to get WEBrick to return both Transfer-Encoding: chunked and =
a calculated Content-length header. If the Transfer-encoding header is set =
via WEBrick::HTTPResponse#[]=3D then #chunked? will return false and the co=
ntent length will be set during the setup_headers method. This causes issue=
s with rack and safari (example code for rack can be seen https://github.co=
m/rack/rack/issues/618#issuecomment-47355492). As far as I'm aware WEBrick =
shouldn't return a content-length when a transfer-encoding chunked header i=
s present. Messages MUST NOT include both a Content-Length header field and=
 a transfer-coding. as per http://www.w3.org/Protocols/rfc2616/rfc2616-sec4=
.html

The following test can be placed into test_httpresponse.rb to demonstrate t=
he issue:

~~~
    def test_200_chunked_does_not_set_content_length
      res.body        =3D 'hello'
      res.status      =3D 200
      res.chunked     =3D false
      res["Transfer-Encoding"] =3D 'chunked'
      res.setup_header

      assert_nil res.header.fetch('content-length', nil)
    end
~~~

I've added a patchfile which includes the above test and a fix for the issu=
e.



---Files--------------------------------
webrick_transfer_encoding_chunked_content_length.patch (1.07 KB)


--=20
https://bugs.ruby-lang.org/