-
Notifications
You must be signed in to change notification settings - Fork 879
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
Updates to http.server_name #5369
Conversation
return ((ServiceRequestContext) ctx).config().virtualHost().hostnamePattern(); | ||
return ((ServiceRequestContext) ctx).config().virtualHost().defaultHostname(); |
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.
@anuraaga can you ack this change?
return accessor.getRequestServerName(requestContext.request()); | ||
public String serverName(ServletRequestContext<REQUEST> requestContext) { | ||
return null; |
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.
^^ the servlet change
return request.serverName().toString(); | ||
public String serverName(Request request) { | ||
return null; |
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.
^^ the tomcat change
currently we don't set |
ya, probably, opened #5375 to discuss/track |
* Updates to http.server_name * Tests * fix * armeria * fix * fix * codenarc
from the spec,
http.server_name
is:The servlet and tomcat instrumentation currently capture
http.server_name
based on HTTP Host (e.g. https://docs.oracle.com/javaee/7/api/javax/servlet/ServletRequest.html#getServerName--), so this PR removes the capturing ofhttp.server_name
for those two instrumentations.The only other instrumentation that captures
http.server_name
is armeria, which does appear to be capturing a configuration-based value.I'm not sure if the one instrumentation justifies keeping
serverName()
inHttpServerAttributesGetter
?For this PR though, at least it seems the
RESPONSE
parameter is not needed forserverName()
(and based on the spec definition it doesn't seem like this should be something that we need to wait for theRESPONSE
for), so I have removed theRESPONSE
parameter from theserverName()
method.