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

Add response headers to FeignException #1277

Closed
wants to merge 1 commit into from
Closed

Add response headers to FeignException #1277

wants to merge 1 commit into from

Conversation

pzapasni
Copy link

Implementation of #1268

This PR adds the ability to retrieve the response headers from a FeignException.

- Add response headers to FeignException and its subclasses
Copy link
Member

@kdavisk6 kdavisk6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pzapasni

Thank you for taking the time to put this together. I have two small concurrency notes. Address these and this PR is good to merge.

super(message, cause);
this.status = status;
this.responseBody = responseBody;
this.responseHeaders = responseHeaders;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Despite the fact that Strings are immutable, the Map is not. Can you change this to create a copy of the map? Some examples are Map.of(responseHeaders) or new LinkedHashMap<>(responseHeaders)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do. I'm just wondering if wrapping the map itself is enough? The values of this map are of type Collection<String>, so although wrapping the map would make it immutable, the values would still be mutable. To make this "truly" immutable, we would need to wrap the values as well. Or do you think that's an overkill?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strings are immutable by nature, so to ensure immutability, you must lock down the map.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True that but having an immutable map still gives you the option of responseHeaders().get("Something").clear() unless Collection<String> isn't also wrapped in an Collections.unmodifiableCollection() at some point before.

Copy link
Collaborator

@vitalijr2 vitalijr2 Jul 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Response has the method caseInsensitiveCopyOf. I think it should be moved to Utll and reused here.

* @see Response#headers()
*/
public Map<String, Collection<String>> responseHeaders() {
return this.responseHeaders;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also wrap this as an immutable collection. Can we wrap with Collections.unmodifiableMap?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but if we wrap the response headers as an immutable collection inside the constructor, shouldn't that be sufficient?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should be, but we don't advertise that to the consumers. It's also good practice to return a copy of the internal collection just in case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd argue that it's better to do the copy on construction (and optionally wrap it in Collections.unmodifiableMap()) instead of returning a new copy each time.

@kdavisk6 kdavisk6 added the feedback provided Feedback has been provided to the author label Sep 24, 2020
@kdavisk6
Copy link
Member

kdavisk6 commented Nov 3, 2020

@pzapasni Apologies for the late replies.

@virtual-machinist
Copy link
Contributor

virtual-machinist commented Dec 3, 2020

Any chance this gets released for X-mas? 🎅

EDIT: There are a few places I'd also want some headers as an end-user. For example DecodeException is what may get thrown due to incorrect/unexpected input. To my knowledge every place it gets thrown already knows about Response, so this change should be trivial to implement.

@nakker
Copy link

nakker commented Mar 11, 2021

Love this change. +1 for sorting out the remaining issues.

@vitalijr2
Copy link
Collaborator

vitalijr2 commented Jul 6, 2021

As far as I understand the source repository is no longer exists.

Could I re-create PR as new one?

Update: new PR #1452 was created.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feedback provided Feedback has been provided to the author
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants