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
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
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
The ProxyRouteLocator now has a retryable property (default
null which means Ribbon will choose the default - usually false).
Fixes gh-115, fixes gh-124
The main problem here was the ZuulProperties being used everywhere. I also
took the opportunity to thin out the top level zuul package and keep the
web and route locator pieces in sub-packages for readability.
Fixes gh-172
A cleaner separation of ribbon and the eureka-dependent ribbon
configuration is achieved by adding a BeanPostProcessor to do the
ServerList wrapping, instead of doing it for every single ribbon
client.
See gh-172
