- add zuul.add-host-header property to add Host header
- add port to X-Forwarded-Host as defined in RFC 7239
- extract PreDecorationFilter.filterOrder() into a public constant
fixes gh-1108
Add a check to current context as contentLength is already in the context
Get content length from Headers when RibbonCommandContext is built + add tests
Use request content length RibbonRoutingFilter
Add documentation for new zuul.ribbonIsolationStrategy property
fixes gh-339
The FormBodyWrapperFilter handles the application/x-www-form-urlencoded. In the case of requests received by curl or javascript, the FormHttpMessageConverter will reencode the parameters differently (for example, '(' will be encoded while it's not with the javascript encodeURIComponent method).
While this doesn't create any problem, the content length was not properly set in AbstractRibbonCommand. This causes the form params being stripped or the backend server would wait a long time for additional bytes depending on if the content length header was bigger/smaller than the actual data.
Since revision 7b270c4b46, Zuul add support of `X-Forwarded-Prefix` for route with `stripPrefix=true`.
However it supposes that Zuul context-path is equals to `/`. By using a custom context-path on Zuul we can expect that `zuul.add-proxy-headers=true` will compute a prefix regarding that context-path.
Indeed with following architecture:
- Zuul with context-path equals to `/foo`
- A random service (*bar-service*) without context-path
Zuul configurations:
```
zuul:
add-proxy-headers: true
routes:
bar-service: /bar/**
```
We expect that *bar-service* when targeting `http://blabla.com/foo/bar/1` will produce endpoint url equals to `http://blabla.com/foo/bar` and not only `http://blabla.com/bar` (that will not be resolvable).
Furthermore context-path influence not only `stripPrefix=true` routes because with following configuration
```
zuul:
add-proxy-headers: true
routes:
bar-service:
path: /bar/**
strip-prefix: false
```
We expect that *bar-service* when targeting `http://blabla.com/foo/bar/1` will also prodcues endpoint url equals to `http://blabla.com/foo/bar`...
---
Moreover since *Spring 4.3* and new [`ForwardedHeaderFilter`](http://docs.spring.io/spring-framework/docs/4.3.0.BUILD-SNAPSHOT/javadoc-api/org/springframework/web/filter/ForwardedHeaderFilter.html) to handle `X-Forwarded-*` headers, when filter catches `X-Forwarded-Prefix` header it will override request context-path by `X-Forwarded-Prefix` header value and then **removes headers from request**. Thus the fact to support context-path will allow to use that filter with Zuul!
---
Attention there is only one edge case, when `X-Forwarded-Prefix` header is present as same as custom `context-path`! In that case context-path will be ignored in favor to `X-Forwarded-Prefix` as same does `ForwardedHeaderFilter`
This allows developers to customize the request builders for zuul requests to inject headers or modify the request in general. Each zuul request type (RestClient, Apache HttpClient and OkHttp) is supported.
fixes gh-1141
Previously ProxyRequestHelper contained a TraceRepository field. This caused zuul apps to fail with a class not found exception if they excluded actuator. This splits TraceRepository functionality into a new TraceProxyRequestHelper that extends ProxyRequestHelper. Auto configuration creates the appropriate ProxyRequestHelper based on the existence or not of actuator classes.
fixes gh-1135
