I think that with the proxy protocol returning the IP from
ServletRequest.getRemoteAddr() is all that is really necessary. I
think the main purpose of this protocol is to make the proxy
transparent to the application, and if the application has to use a
different API for then then it has failed to be transparent.
Stuart
On Wed, Sep 21, 2016 at 11:07 AM, Greg Wilkins <gregw_at_webtide.com> wrote:
> Note also that in this conversation, we should at least mention the proxy
> protocol as used by haproxy, AWS load balancer and supported by several
> servers.
>
> It does not use headers, so is transparent to the servlet application. I
> guess the question being that if we provided a better API to provide better
> information about the real vs proxy IPs/ports, should it include support for
> this protocol?
>
>
>
>
> On 17 September 2016 at 10:12, Greg Wilkins <gregw_at_webtide.com> wrote:
>>
>>
>>
>> On 17 September 2016 at 00:02, Mark Thomas <markt_at_apache.org> wrote:
>>>
>>> I don't recall a single request for RFC 7239 support from the Tomcat
>>> community. We have plenty of requests (and support) for X-Forwarded-For
>>> and friends.
>>
>>
>> Yep - demand for it has been low in Jetty also and we only just recently
>> added support for it. However it's semantics is sufficiently similar to
>> the defacto standards that I think any support we give for RFC7239 can
>> easily be extended to X-Forwarded as a transparent extension.
>>
>> I think correctly implementing these headers is important for both
>> functionality and security reasons, more over the RFC version is not exactly
>> trivial to implement because it does allow for fully parametrized, quoted,
>> comma separated values. I assume the defacto standard could also support
>> such values, but as there is no spec implementations get away with assuming
>> simple values.
>>
>> If adoption of the RFC is to increase, it would be good for the container
>> spec to be out front for once and actually provide a service that would make
>> the transition from defacto standard to standard easy and secure.
>>
>>
>> --
>> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
>
>
>
>
> --
> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com