JRuby's environment variables are provided by the Java Development
Kit's (JDK's) classes, which present them as a map from string to
string. In order to do this, those environment variable names and
values must be decoded into characters, which breaks any variables
that are intended to be "raw" bytes not necessarily decodable with
the default system encoding.
This issue is detailed in jruby/jruby#6248. The only solution on
the JRuby side will be to bypass the JDK environment variable API
and go directly to the native getenv/setenv system calls. This is
not likely to happen in the near future, due to the complexity of
such a change and the rarity of undecodable environment values.
The exclude here was added due to the Windows platform also having
a similar sensitivity to character encodings when working with
environment variables. It seems appropriate to expand this skip
to the "java" platform, as the root issue is largely the same.
https://github.com/ruby/webrick/commit/dc453e5c3c
instead of `@root.encoding`.
And fallback to ASCII-8BIT when filesystem encoding is US-ASCII.
When `@root.encoding` is not compatible filesystem encoding,
`Encoding::CompatibilityError` raised at `webrick/httpservlet/filehandler.rb:341`.
So `DocumentRoot` must be compatible with filesystem encoding.
https://rubyci.org/logs/mswinci.japaneast.cloudapp.azure.com/vc12-x64/ruby-master/log/20200619T054159Z.fail.html.gz
```
1) Failure:
WEBrick::TestFileHandler#test_cjk_in_path [D:/tmp/mswin-build20200619-14304-utgij/ruby/test/webrick/utils.rb:72]:
exceptions on 2 threads:
webrick log start:
[2020-06-19 16:28:42] ERROR `/あ.txt' not found.
webrick log end
Filesystem encoding is Windows-31J.
<"200"> expected but was
<"404">.
---
<[]> expected but was
<["[2020-06-19 16:28:42] ERROR `/\xE3\x81\x82.txt' not found.\n"]>.
```
`prevent_directory_traversal` treats `path_info` as filesystem encoding.
So path_info should be filesystem encoding in request URL.
On some environments, fallback to ASCII-8BIT when EncodingError.
"hack" was too short. The tests checks the error html, which includes
hostname. GitHub Actions hostname seems randomly generated, and it may
include the indicator string.
https://github.com/ruby/ruby/runs/784896235
```
1) Failure:
WEBrick::TestHTTPResponse#test_prevent_response_splitting_cookie_headers_cr [/home/runner/work/ruby/ruby/src/test/webrick/test_httpresponse.rb:71]:
Expected /hack/ to not match "HTTP/1.1 500 Internal Server Error\r\nContent-Type: text/html; charset=ISO-8859-1\r\n\r\n<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.0//EN\">\n<HTML>\n <HEAD><TITLE>Internal Server Error</TITLE></HEAD>\n <BODY>\n <H1>Internal Server Error</H1>\n WEBrick::HTTPResponse::InvalidHeader\n <HR>\n <ADDRESS>\n WEBrick/1.6.0 (Ruby/2.8.0/2020-06-18) at\n fv-az89.dddawhu1s14uzpjkiz5fhackre.cx.internal.cloudapp.net:80\n </ADDRESS>\n </BODY>\n</HTML>\n".
```
This change uses longer indicator "cracked_indicator_for_test" instead.
http://ci.rvm.jp/logfiles/brlog.trunk-theap-asserts.20200618-002305
```
I, [2020-06-18T00:28:11.661066 #31625] INFO -- : 1) Failure:
I, [2020-06-18T00:28:11.661157 #31625] INFO -- : WEBrick::TestFileHandler#test_cjk_in_path [/tmp/ruby/v3/src/trunk-theap-asserts/test/webrick/utils.rb:72]:
I, [2020-06-18T00:28:11.661216 #31625] INFO -- : exceptions on 1 threads:
I, [2020-06-18T00:28:11.661269 #31625] INFO -- : U+3042 from UTF-8 to US-ASCII
```
Surprisingly (at least for me), `server[:DocumentRootOptions]`
on Webrick is global information and it affect the result of
test_short_filename. Random order test fails because of global
information change. I doubt it is bug, but to fix random order
test, I restore the value.
While the stripping of header values is required by RFC 2616 4.2 and
RFC 7230 3.2.4, the squishing is not and can break things, such as
when one header contains an HMAC of another header.
Fixes Ruby Bug 7021.
https://github.com/ruby/webrick/commit/8b96088a86
This is a follow up to d9d4a28f1c.
The commit prevented CRLR, but did not address an isolated CR or an
isolated LF.
Co-Authored-By: NARUSE, Yui <naruse@airemix.jp>
WEBrick::HTTPProxyServer implementes HTTP proxy using
WEBrick and Net::HTTP.
WEBrick accepts HTTP/1.0 clients and
Net::HTTP uses always HTTP/1.1.
However HTTP/1.1 supports chunked transfer coding HTTP/1.0 doesn't.
Chunked transfer coding doesn't require that
content-length before the content is sent.
But non-chunked transfer coding require content-length before
the content is sent.
So, when HTTP/1.0 clients connects WEBrick::HTTPProxyServer and
origin server returns chunked response,
WEBrick::HTTPProxyServer needs to store whole content to
know the length of it.
This patch do it using tempfile.
Remove extraneous spaces after the status code that is
non-compliant with RFC, i.e `HTTP 200 OK `, to unnecessary
confusion for WEBrick users, by a risk that WEBrick instances in
the wild will have server responses flagged as suspicious or
malicious due to a similar bug in [Cobalt Strike
misconfiguration].
Reported by Matt Tennis <mtennis@paloaltonetworks.com>
[Cobalt Strike misconfiguration]: https://blog.fox-it.com/2019/02/26/identifying-cobalt-strike-team-servers-in-the-wild/
So that a customized HTTPServer subclass can use it's own
Request/Response classes.
To apply the override, make a subclass of WEBrick::HTTPServer
and override the
`create_request_and_response(with_webrick_config)` method. The
method should return an Array of [request, response].
To check whether the Server supports this method (i.e. when
using older versions of WEBrick when needing this
functionality), you can ask the server if it responds to the
method
server.respond_to?(:create_request_and_response)
This is backportable.
[ruby-core:69604] [Feature #11266]
From: Julik Tarkhanov <me@julik.nl>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66452 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
OpenSSL complains abour our keys being small and weak :<
Make them big and strong with 2048-bit RSA keys and SHA256 digests
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66152 b2dd03c8-39d4-4d8f-98ff-823fe69b080e