-
Notifications
You must be signed in to change notification settings - Fork 125
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
Enhancement Proposal: *Context.cacheControl() #1291
Comments
I'd agree that is pretty clumsy. There could be a reason, but why weren't the method calls simply changed to use that long form instead of deprecating the methods? The |
I don't know the actual reason why deprecating Nevertheless, I think programmers would be more happy about Regarding RFC 9111 I think we should separate adding syntactic sugar (this PR) from supporting newer RFCs (separate OR). |
Kindly asking for more opinions. If nobody vetos |
@mkarg Could you link the PR that deprecated the |
|
There had been not upfront vetos, so I assume everybody is fine with adopting this enhancement. If not, please clearly tell me NOW. Thanks. |
Recently we deprecated
CacheControl.valueOf(String)
, but the replacement is a rather clumsy code line:RuntimeDelegate.getInstance().createHeaderDelegate(CacheControl.class).fromString(value)
. This is very annoying e. g. when migrating filters from 2.x to 3.x.To make the programmer's life easier, I like to propose that we add support for some syntactic sugar:
cacheControl()
on Client/Server Request/Response Context returning a modifiable instance ofCacheControl
initialized by the content of theCache-Control
header.The text was updated successfully, but these errors were encountered: