Skip to content
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

default User-Agent header to map to spring.application.name #17041

Closed
ckoutsouridis opened this issue Jun 1, 2019 · 5 comments
Closed

default User-Agent header to map to spring.application.name #17041

ckoutsouridis opened this issue Jun 1, 2019 · 5 comments
Labels
status: declined A suggestion or change that we don't feel we should currently apply

Comments

@ckoutsouridis
Copy link

ckoutsouridis commented Jun 1, 2019

Whether using RestTemplate or WebClientBuilder, would it make sense to use as default User-Agent header the value of spring.application.name?

At the moment i am using a "custom" RestTemplateCustomizer that is injecting this header. for RestTemplate and defaultHeaders method for WebClientBuilder, but i think it makes sense for the User-Agent to be set to spring.application.name by default.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jun 1, 2019
@knoobie
Copy link

knoobie commented Jun 1, 2019

That sounds more like a feature, you don't want to have enabled as default. (Information disclosure)

@ckoutsouridis
Copy link
Author

i can understand the information disclosure argument, but it's not that it's empty currently. Depending on the actual http client used, it can be either the JRE version or something like "apache-http-components" which in my opinion is worse than the application name.

If not by default, It would be nice to be able to set/enable via a property.

@wilkinsona
Copy link
Member

Thanks for the suggestion.

I don't think we should set the User-Agent header in HTTP requests to the value of spring.application.name by default. While information disclosure is less of a concern for a client, I don't think there's really any good default for User-Agent. For example, GitHub encourages you to use your GitHub user id or name of the application as registered with GitHub so that they have a means of contacting you should they identify a problem. Neither of those is likely to have the same value as spring.application.name.

I'm less sure about providing a property to enable the behaviour. However, I'm leaning towards it not being worth it as I doubt it would be all that widely used. Furthermore, WebClient already provides a nice API for setting default headers via its Builder and its defaultHeader or defaultHeaders. Things aren't quite so straightforward with RestTemplate. That could perhaps by tackled via our RestTemplateBuilder if we thought it would be of sufficient value.

Let's see what the rest of the team thinks.

@wilkinsona wilkinsona added the for: team-attention An issue we'd like other members of the team to review label Jun 3, 2019
@snicoll
Copy link
Member

snicoll commented Jun 3, 2019

WebClient.Builder has a defaultHeader method and adding a similar feature to RestTemplateBuilder could be interesting indeed. I don't think we should have a property for this either.

@philwebb philwebb added type: enhancement A general enhancement and removed for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement labels Jun 5, 2019
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jun 5, 2019
@philwebb
Copy link
Member

philwebb commented Jun 5, 2019

After some discussion we feel like using spring.application.name or offering a dedicated property isn't the right approach. Instead, we've opened #17072 to look at adding convenience to RestTemplateBuilder.

@philwebb philwebb closed this as completed Jun 5, 2019
@philwebb philwebb added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged labels Jun 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

6 participants