User can provide a url in the route that starts with "forward:"
(instead of "http:" etc.) to handle the request locally.
Also properly ignores ignored routes, so they can be handled locally
(rather than giving up and sending 404).
Fixes gh-536
Still a release candidate (not yet GA), but seems to work, so we'll
try and update before Spring Cloud is released again.
Fixes gh-546, fixes gh-567, fixes gh-553 (probably)
Other Ribbon clients in Spring Cloud use a ServerIntrospector
to check if the Server wanted to be secure. This change levels things
up (and makes the Spring Feign Client a lit easier to customize).
See gh-414
Most clients send "Transfer-Encoding: chunked" so this isn't often
an issue, but if they don't (e.g. if you use "-H Expect:" with
curl) then it's not a great idea to slurp it all into memory.
Fixes gh-563
When using Ribbon the hystrix config and metrics are namespaced
as "RibbonCommand" (via the group key). the command key can then be
serviceId, making it easier to remember how to configure
Ribbon and Hystrix.
Fixes gh-329
There are usually some hints available, especially if the Server
came from Eureka. Unfortunately Server on it's own doesn't contain
enough information (why?), but as a fallback we can guess that
anyone using port 443 is secure.
Fixes gh-459
And also when using eureka-first for discovering config server.
The EurekaClient is very rigid and initializes itself, registering
with the remote service on instantiation. Hance it needs to be
in @RefreshScope for it to be properly refreshable. Doing that
leads to a sequence of other changes (e.g. to account for the
fact that there is no @RefreshScope in bootstrap context).
Fixes gh-551
When the parent (bootstrap) context registers the app as well as consuming
the registry it causes problems, e.g. when you refresh that context is
re-created and destroyed, which tends to unregister the app and it's hard
to get it back. It is simpler if the parent context use eureka read-only.
To ensure this we have to remove the @EnableDiscoveryClient from the
bootstrap context.
Tested with vanilla config server and eureka with the 'eureka-first'
sample and the 'zuul-proxy-eureka' sample.
Fixes gh-421
Reverts part of a change made for gh-349 and rationalizes a bit of the
Eureka configuration. The Eureka client cannot be shutdown without
attempting to restart it (but there isn't an obvious public API for
that), so it's better not to shut it down at all.
See gh-421
Should be no change for users of Boot 1.2 right now, but with this
patch it is possible to use 1.3 with the new conventions for metrics
(e.g. in particular exporting by declaring beans of type
MetricWriter)
When the Apache HTTP client is being set up for the Ribbon client we can jump
in and explicitly set a cookie policy. Obviously, since the client will generally
be shared across sessions, the only sensible default is IGNORE_COOKIES.
I couldn't find a way round this without using deprecated APIs (but there
are other instances of that in our code because of the way Netflix uses
it, so maybe that doesn't matter).
Fixes gh-301
If the app has a context path then the route locator does not match
the whole requestURI (as provided by the raw servlet API), but Spring
has a utility for stripping it off, so we can just use that.
Fixes gh-270
If there is a default route (/**) then the ZuulHandlerMapping will
mask the /error path in a normal Spring Boot application. This change
makes it a special case so that ZuulHandlerMapping will never map
the /error route (the one specified by the ErrorController).
Fixes gh-284
This was kind of ugly, and caused a static usage of the eureka
DiscoveryCLient to become necessary again, just so the @Bean that is
provided for the user stays accurate (it has to be the one in the main
application context, even if the parent boot strap has different
instance metadata).
I tested with a vanilla Eureka server and config server, and used the
client in tests/eureka-first.
Fixes gh-268
This change adds more data to the stream with {"type":"Ping"}
so (I believe) the existing dashboard client will discard it,
but stay alive.
Fixes gh-264
Since hostnames ahve quite strict syntax (e.g. no underscores) we should
validate the feign client name to prevent nasty surprises at runtime.
Fixes gh-263
It turns out that the suckiness of Zuul with multipart requests
comes almost entirely from the Multipart handling in Spring's
DispatcherServlet. This change makes the proxy routes available
on an alternative path /zuul/<normal_path> (where
/zuul is the default value of zuul.servletPath). I have
tested those with 800MB file uploads using the main method in
the FormZuulServletProxyApplicationTests and the main
observation is that there is no OutOfMemory error (no-one tries
to download the complete request body). It works with Ribbon
and with the simple (HttpClient) filter. With Ribbon you
will need to set some timeouts if you want to upload files
as large as that, e.g. see application.yml in the tests:
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 60000
ribbon:
ConnectTimeout: 3000
ReadTimeout: 60000
You need to set "Transfer-Encoding: chunked" in the
incoming request. Chrome does not do this by default
apparently, but I was able to test with curl, e.g.
$ curl -v -H "Transfer-Encoding: chunked" \
-F "file=@mylarg.iso" \
localhost:9999/zuul/direct/file
The old proxy paths through the DispatcherServlet are still
available (for backwards compatibility and for convenience of
having the paths available at the root of the context path).
Fixes gh-254
Because of the way that a FormBodyServletRequestWrapper was
implemented (extending the Zuul servlet 2.5 wrapper) it could
barf at runtime if anyone called its servlet 3.0 methods. The fix
for that was to extract our Servlet30RequestWrapper and extend that
instead.
Also tweaked the DebugFilter a bit so it doesn't try and display
the whole payload. Probably speeds up file uploads a bit but the
fact that we have to store the whole request body in memory is
going to kill us eventually.
See gh-254
If you are using AMQP there needs to be a ConnectionFactory (from
Spring Rabbit) in the application context. If there is a single
ConnectionFactory it will be used, or if there is a one qualified as
@[Hystrix,Turbine]ConnectionFactory it will be preferred over others,
otherwise the @Primary one will be used. If there are multiple
unqualified connection factories there will be an error.
See https://github.com/spring-cloud/spring-cloud-bus/issues/13
Listen for heartbeats from discovery so that state changes can trigger
a new status (and the client doesn't rely on the old address of the
server if it has now changed).
Fixes gh-232
It doesn't make sense to @EnableFeignClients in autoconfig
because the user needs to specify a package to scan. It does
make sense (sort of) to set up the encoder/decoder/logger etc.
See gh-226
When the URL is passed down to Ribbon and reconstructed from
a LoadBalancer the Server only knows about host and port, so the scheme
has to come from the original declaration.
There's still a potential problem with Eureka remote services that
are available with a non-secure port as well (probably fairly rare).
Fixes gh-221
Users need to know how to configure and use the Eureka
metadata because it isn't immediately obvious and does
require some decisions to be made.
Fixes gh-102
If the ServerProperties contain a servletPath then the handler mapping
does not contain that prefix, but the incoming request URI does. This leads
to some interesting prefix stripping gymnastics. All the existing tests
assumed that the prefix was empty (the default for a Spring boot app).
See gh-199
and also allow explicitly configured services to be unignored. I.e.
zuul:
ignoredServices: *
routes:
foo: /foo/**
Will expose only the foo service.
Fixes gh-198
Dave Syer