-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Immutable local/remote SocketAddress within a ConnectionMetaData #10867
Immutable local/remote SocketAddress within a ConnectionMetaData #10867
Conversation
The local/remote SocketAddress is cached within the ConnectionMetaData or Connection instance, so that any changes are not visible during the request lifetime. Ensure that all server Connection types respect HttpConfiguration#getLocalAddress
@joakime Can you remind me why Could we change the implementation so that if a non null address is set on the HttpConfiguration, then that is equivalent to adding a customizer that will force the address. |
The local/remote SocketAddress is cached within the ConnectionMetaData or Connection instance, so that any changes are not visible during the request lifetime. Ensure that all server Connection types respect HttpConfiguration#getLocalAddress
…0.x/immutableAddressesInConnectionMetaData
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just questions about the returning of null and storing of null in final fields.
And seemingly missing handling of HttpConfiguration.(local)Address.
jetty-core/jetty-io/src/main/java/org/eclipse/jetty/io/SelectableChannelEndPoint.java
Show resolved
Hide resolved
jetty-core/jetty-io/src/main/java/org/eclipse/jetty/io/DatagramChannelEndPoint.java
Show resolved
Hide resolved
...ttp2-server/src/main/java/org/eclipse/jetty/http2/server/internal/HTTP2ServerConnection.java
Show resolved
Hide resolved
The local/remote SocketAddress is cached within the ConnectionMetaData or Connection instance, so that any changes are not visible during the request lifetime. Ensure that all server Connection types respect HttpConfiguration#getLocalAddress and that it is not implemented only in servlet layer Avoid DNS resolution.
@joakime I've pushed a few more commits dealing with HttpConfiguration.getLocalAddress(). We were dealing with that in servlet land... which was fine when we didn't have a core request. Now that it is dealt with at the connection level, we can remove all that handling from the servlet implementation(s). |
jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/AbstractMetaDataConnection.java
Outdated
Show resolved
Hide resolved
@@ -46,6 +46,21 @@ public DatagramChannel getChannel() | |||
return (DatagramChannel)super.getChannel(); | |||
} | |||
|
|||
@Override | |||
public SocketAddress getRemoteSocketAddress() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be moved to SelectableChannelEndPoint
where getLocalSocketAddress()
is.
And be removed also from SocketChannelEndPoint
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can't as the getRemoteAddress
on a DatagramChannel
is a different method than the one on SocketChannel
and does not exist in NetworkChannel
.
There is a reason it is as it is.
The local/remote SocketAddress is cached within the ConnectionMetaData or Connection instance, so that any changes are not visible during the request lifetime. Ensure that all server Connection types respect HttpConfiguration#getLocalAddress and that it is not implemented only in servlet layer Avoid DNS resolution.
The local/remote SocketAddress is cached within the ConnectionMetaData or Connection instance, so that any changes are not visible during the request lifetime.
Ensure that all server Connection types respect HttpConfiguration#getLocalAddress
This is an alternate to both #10861 and #10815 to fix #10806
Co-authored-by: Joakim Erdfelt [email protected]