Remove SingleInflight support from Client #1454
Conversation
Callers should instead implement their own in flight query caching.
client.go
Outdated
| // time. | ||
| // | ||
| // Deprecated: This is a no-op. Callers should implement their own in flight | ||
| // query caching. |
There was a problem hiding this comment.
maybe link to the issue for some more background on why?
There was a problem hiding this comment.
Will go doc properly linkify it in the form I've added? Do you know?
There was a problem hiding this comment.
lol, we have both forms already:
reverse.go: // Preserve previous NOTIMP typo, see github.com/miekg/dns/issues/733.
dns_test.go: tkey.Hdr.Class = ClassINET // https://github.com/miekg/dns/issues/577
except these are not part of the public docs.
I thought you can make pkg.go.dev look at a specific commit but my go gets fail with unknown revision, either way, folks can find the issue regardless of this being linkified
If we want to use a custom mechanism of obtaining a Conn that doesn't match the net.Dialer type, but retain the timeout behaviour from ExchangeContext, there was previously no way to accomplish this. This PR makes the underlying ExchangeWithConnContext function public, which allows this behaviour. Now that miekg#1454 is merged, there is no longer any interaction between the context provided and the singleflight behaviour, so I removed the comment from ExchangeWithConn. Signed-off-by: Andrew Dunham <andrew@du.nham.ca>
If we want to use a custom mechanism of obtaining a Conn that doesn't match the net.Dialer type, but retain the timeout behaviour from ExchangeContext, there was previously no way to accomplish this. This PR makes the underlying ExchangeWithConnContext function public, which allows this behaviour. Now that #1454 is merged, there is no longer any interaction between the context provided and the singleflight behaviour, so I removed the comment from ExchangeWithConn. Signed-off-by: Andrew Dunham <andrew@du.nham.ca>
|
It's worth noting that if someone was relying on this for birthday attack prevention (https://datatracker.ietf.org/doc/html/rfc5452#section-5), they will no longer be protected, starting from v1.1.54, unless they implement their own protection. Probably instead of "Callers should implement their own in flight query caching if needed" the comment should warn about birthday attacks and encourage callers more strongly to implement their own. |
Callers should instead implement their own in flight query caching.
Closes #1449