Releases: cloudfoundry/routing-release
Releases · cloudfoundry/routing-release
0.180.0
Release Highlights
- Operator can see a log message that indicates the number of tries when the Gorouter fails to connect to a backend in the gorouter.log details
- Golang has been updated to 1.10.3 for all routing components details here and here
- Release author can now specify an IP for the route-registrar using the job spec. If a host is not found in the job spec it will default to the IP of the VM the route-registrar is running on details
Using BPM for routing components
- We are now using BPM for gorouter details
- We are now using BPM for routing-api details
- We are now using BPM for route_registrar details
Note: BPM needs to be colocated on the VM for the components that are using BPM. If you are using cf-deployment, BPM is already colocated on the bosh deployed VMs, but if you are not using cf-deployment you would have to colocate the BPM job on the component VMs for gorouter, routing-api and route-registrar.
Bug fixes:
- Fixed a issue where query parameters were not sent to the application when preceded by a
//
anywhere in the URL. Now when the request URL includes a//
, the query parameters are sent to the application by the Gorouter details - Fixed an issue with symlinks to enable bosh-cli v5.x to work with routing-release details
- PID files are being deleted when the Gorouter stops details
Known Issues
- Due to the enabling of BPM in the gorouter job, if
router.enable_access_log_streaming
is set totrue
the gorouter job will fail to start. To get around this, you can setrouter.enable_access_log_streaming: false
if you also haverouter.write_access_logs_locally: true
. If you didn't previously write access logs to disk, then you'll want to keep an eye on disk usage. We'll plan to fix this behavior in the next release.
0.179.0
0.178.0
0.177.0 - DO NOT USE
Do not use this release in production.
0.176.0
Release Highlights
- Operators can now configure a manifest property
router.disable_log_forwarded_for
to disable logging of X-Forwarded-For header in gorouter logs. This is to comply with EU regulations that do not allow persisting personal data. For details - Operators can now configure a manifest property
router.disable_log_source_ip
to disable logging of source IP in gorouter logs. This is to comply with EU regulations that do not allow persisting personal data. For details
Bug fixes:
- We fixed an issue where Gorouter was not previously forwarding/settings the client certificate in the XFCC header when a request was being proxied through a route service. Gorouter now sets the XFCC header with the client certificate. See the manifest property
router.forwarded_client_cert
to understand the options available for forwarding a client certificate. For details - We fixed an issue when sanitizing X-Forwarded-For header, when
force_forwarded_proto_https: false
andsanitize_forwarded_proto: true
. When a request is received on port 443 with theX-Forwarded-Proto: http
the Gorouter sanitizes theX-Forwarded-For
header tohttp
instead of upgrading the connection. For details
Manifest Property Changes
0.175.0 | 0.176.0 | Default Value |
---|---|---|
did not exist | router.disable_log_forwarded_for |
false |
did not exist | router.disable_log_source_ip |
false |
0.175.0
Release Highlights
- Operators can now configure the manifest property
router.sanitize_forwarded_proto: true
to sanitize the X-Forwarded-Proto HTTP header in a request whenrouter.force_forwarded_proto_https
is set tofalse
. We recommend setting the property totrue
if the Gorouter is the first component to terminate TLS, and setting it tofalse
when your load balancer is terminating TLS and setting the X-Forwarded-Proto header details
Bug fixes:
- Fixed an issue where the Gorouter was temporarily(for 30 seconds) removing backends from the pool of available backends when a downstream client closes the connection while the request is still being processed. This could lead to temporary application unavailability details
- Fixed a bug where
request_timeout_in_seconds
was being set per connection and not per request, leading to requests timing out while the request is still being processed details - Fixed a bug where the router was temporarily(for 30 seconds) not removing a backend from the pool of available backends when a backend application instance was misbehaving (e.g. closing the connection or crashing). Operators would see
502
errors in the Gorouter logs details
Golang update:
- Gorouter and dependencies have been updated to Golang 1.10.1 details
Manifest Property Changes
0.174.0 | 0.175.0 | Default Value |
---|---|---|
did not exist | router.sanitize_forwarded_proto |
false |
0.174.0
Release Highlights
- When a connection to a TLS enabled backend fails, Gorouter tries to send a request to another backend of the app before returning a response to the client. In an environment where some backends are TLS enabled and some are not, if the Gorouter first chooses a TLS enabled backend and fails, and if it subsequently chooses a non TLS backend, then it will appropriately use a plain text request. details
Manifest Property Changes
- No manifest property changes
0.173.0
Release Highlights
- Previously if an operator sets
router.disable_http: true
in the Gorouter manifest, requests for a route bound to a route service running as an app on the platform would return a 502. This has now been fixed, route services will work as expected whenrouter.disable_http: true
details - Golang version updated from 1.9.1 to 1.9.4 details
Manifest Property Changes
- No manifest property changes
0.172.0
Release Highlights
- Fixes vulnerability https://www.cloudfoundry.org/blog/cve-2018-1221/
- We now accept a list and a range of ports for reservable ports for TCP routing. Details here
0.171.0
Release Highlights
- Gorouter now supports websocket connections to backend applications for routes registered with tls_ports details
- routing-release now enables operators to expose available UAA clients via BOSH links in cf-deployment details
- We see a performance degradation in this release, on further investigation we are confident this is not related to routing-release changes or stemcell changes. This strongly suggests it might be due to underlying IaaS performance. We see a 10% decrease in peak latency from 4150 requests/s to 3750 requests/s and an increase in latency at throughput above 2750 requests/s.
Manifest Property Changes
- No manifest property changes