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.
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.
Chrome 75+ started to strictly enforce X.509 keyUsage against TLS server
certificates. Webrick supports generating instant self-signed
certificates for debugging purpose and these certificates lacks required
keyUsage for modern TLS. So adding the following keyUsages:
- digitalSignature (for server authentication)
- keyAgreement (for DH key exchange)
- dataEncipherment (for data encryption)
References:
- https://tools.ietf.org/html/rfc5280#section-4.2.1.3
- https://crbug.com/795089
- https://boringssl-review.googlesource.com/c/34604
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.
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
The values of @header are expected to be all strings;
WEBrick::HTTPResponse::[]=(key, val) explicitly converts the second
argument to a string and assigns it to @header hash.
However, there were some points in WEBrick internal code that assigns
non-String to @header. This change fixes the issues.
The values are checked by `header_value =~ /\r\n/` in check_header.
The type confusion caused conflict with removal of `Object#=~`
[Feature #15231].
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65984 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Based on patch by akr [ruby-core:88477], use Tempfile.create
to avoid unnecessary unlink call. Unlike akr's original patch,
this does not change the return value of flush.
Thanks-to: Tanaka Akira <akr@fsij.org>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64363 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
They are assigned automatically when pushing gem file to rubygems.org.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64213 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This adds a password_hash keyword argument to
WEBrick::HTTPAuth::Htpasswd#initialize. If set to :bcrypt, it
will create bcrypt hashes instead of crypt hashes, and will
raise an exception if the .htpasswd file uses crypt hashes.
If :bcrypt is used, then instead of calling
BasicAuth.make_passwd (which uses crypt),
WEBrick::HTTPAuth::Htpasswd#set_passwd will set the bcrypt
password directly. It isn't possible to change the
make_passwd API to accept the password hash format, as that
would break configurations who use Htpasswd#auth_type= to set
a custom auth_type.
This modifies WEBrick::HTTPAuth::BasicAuth to handle checking
both crypt and bcrypt hashes.
There are commented out requires for 'string/crypt', to handle
when String#crypt is deprecated and the undeprecated version is
moved to a gem.
There is also a commented out warning for the case when
the password_hash keyword is not specified and 'string/crypt'
cannot be required. I think the warning makes sense to nudge
users to using bcrypt.
I've updated the tests to test nil, :crypt, and :bcrypt values
for the password_hash keyword, skipping the bcrypt tests if the
bcrypt library cannot be required.
[ruby-core:88111] [Feature #14940]
From: Jeremy Evans <code@jeremyevans.net>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64060 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
