trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Carroll <solidwallofc...@yahoo-inc.com>
Subject Re: Problems with caching / retrieving from cache from a particular origin
Date Tue, 01 Mar 2016 20:25:08 GMT
Yes. Based on that logging, the first request is cached and it is found on the second request.
But once found ATS decides that authentication is needed and so doesn't use the cached data.
You can see the code that does this in HttpTransact::need_to_revalidate. Ultimate what happens
is ATS looks for a WWw-Authenticate header in the reply and, not finding it, refuses to serve
it.

A few things to look at -

* You can turn this authentication checking off. You can do it globally or, using a plugin
or potentially the existing conf-remap plugin, turn it off for just that origin.
* You can have the origin return a "Cache-Control: public" in addition to the no-cache.
* You could use a plugin (or potentially header_write) to insert the Cache-Control: public
yourself.
* Alternatively, strip the authentication from the client request because, based on the response
from the origin server, it is being ignored already.

But ultimately, as you noted, the authentication is the issue.


-------------




On Tuesday, March 1, 2016 12:33 PM, jhasle <jhancke@de.ibm.com> wrote:
Ok this is a bit much, but it should cover the logs of two requests to the
problematic source. First a request directly after server restart, so of
course it is not in the cache. The second is directly afterwards, so it
could be retrieved from cache. Sorry I had to anynomize data the urls, its
etc.:


I think the problem is here. Probably an authentication issue:


[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:2433
(CallOSDNSLookup)> (http_trans) Next action SM_ACTION_DNS_LOOKUP;
OSDNSLookup
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpSM.cc:6920
(call_transact_and_set_next_state)> (http) [2] State Transition:
SM_ACTION_API_CACHE_LOOKUP_COMPLETE -> SM_ACTION_DNS_LOOKUP
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpSM.cc:3997
(do_hostdb_lookup)> (http_seq) [HttpSM::do_hostdb_lookup] Doing DNS Lookup
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:8344
(ink_cluster_time)> (http_trans) [ink_cluster_time] local: 1456858970,
highest_delta: 0, cluster: 1456858970
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:1634
(OSDNSLookup)> (http_trans) [HttpTransact::OSDNSLookup] This was attempt 1
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:1697
(OSDNSLookup)> (http_seq) [HttpTransact::OSDNSLookup] DNS Lookup successful
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:1731
(OSDNSLookup)> (http_trans) [OSDNSLookup] DNS lookup for O.S. successful IP:
xxxHostIPxxx
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:1799
(OSDNSLookup)> (http_trans) Next action SM_ACTION_API_OS_DNS;
HandleCacheOpenReadHit
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpSM.cc:6920
(call_transact_and_set_next_state)> (http) [2] State Transition:
SM_ACTION_DNS_LOOKUP -> SM_ACTION_API_OS_DNS
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:2572
(HandleCacheOpenReadHit)> (http_seq) [HttpTransact::HandleCacheOpenReadHit]
Authentication needed
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:3059
(HandleCacheOpenReadMiss)> (http_trans) [HandleCacheOpenReadMiss] --- MISS
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:3061
(HandleCacheOpenReadMiss)> (http_seq)
[HttpTransact::HandleCacheOpenReadMiss] Miss in cache
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:5183
(add_client_ip_to_outgoing_request)> (http_trans) client_ip_set = 0
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:5187
(add_client_ip_to_outgoing_request)> (http_trans) inserted request header
'Client-ip: 192.168.99.1'
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:5209
(add_client_ip_to_outgoing_request)> (http_trans)
[add_client_ip_to_outgoing_request] Appended connecting client's
(192.168.99.1) to the X-Forwards header
[Mar  1 19:02:50.664] Server {0x2b4950510440} DEBUG: <HttpTransact.cc:7789
(build_request)> (http_trans) [build_request] removing host name from url

Mime
View raw message