[
https://issues.apache.org/jira/browse/HTTPCLIENT-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901821#action_12901821
]
Vianney Carel commented on HTTPCLIENT-982:
------------------------------------------
I didn't integrate the latest snapshot (i'm still on alpha-2), so I cannot see
the Age & Via headers. I'm afraid anyway that it's not enough to know if the
response has been cached or not [by the client]. Because those headers could
come from the back-end server without beeing overwritten by the client, if it
doesn't cache the response. Right ?
About adding other headers to the response, I wouldn't recommand it. Actually,
there wouldn't be the RFC, I wouldn't recommand adding headers at all, because
one of the basics thing I expect from a cache is to keep data unchanged.
Besides, it would be very confusing if a server would produce the same headers
that the caching client uses.
Therefore I believe that cache-related information would better be in the
request's HttpContext rather than in the response's headers.
What do you think ?
NB: having the same kind of headers as Squid produces would be perfect for my
use... but not in the response ;-)
> Could we get a way to know if the response has been served from the cache or
> not ?
> ----------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-982
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-982
> Project: HttpComponents HttpClient
> Issue Type: New Feature
> Components: Cache
> Affects Versions: 4.1 Alpha2
> Reporter: Vianney Carel
> Priority: Trivial
>
> Is there a way to know if the response has been served from the cache or not ?
> That's an information which might be useful for monitoring the activity of
> the cache.
> If there's no current way, maybe a flag could be added in the request context
> whenever the response comes from the cache ... ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
