Return-Path: X-Original-To: apmail-trafficserver-users-archive@www.apache.org Delivered-To: apmail-trafficserver-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C43CE107DC for ; Fri, 6 Jun 2014 02:31:25 +0000 (UTC) Received: (qmail 29742 invoked by uid 500); 6 Jun 2014 02:31:25 -0000 Delivered-To: apmail-trafficserver-users-archive@trafficserver.apache.org Received: (qmail 29654 invoked by uid 500); 6 Jun 2014 02:31:25 -0000 Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@trafficserver.apache.org Delivered-To: mailing list users@trafficserver.apache.org Received: (qmail 29645 invoked by uid 99); 6 Jun 2014 02:31:25 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jun 2014 02:31:25 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ming.zym@gmail.com designates 209.85.160.54 as permitted sender) Received: from [209.85.160.54] (HELO mail-pb0-f54.google.com) (209.85.160.54) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Jun 2014 02:31:22 +0000 Received: by mail-pb0-f54.google.com with SMTP id jt11so1963501pbb.41 for ; Thu, 05 Jun 2014 19:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=C35KiHtPFYToOo7IY0VRxwN64vVK4cOdJy4/3tJ0IV8=; b=Fz8XQlVxLerQfZUcJEL33HEWsO8E9X4WfPknvTR5PRFEnEZgTPLcIa2jhvSuie7yIN vJlLx52o/7pO3lK/Tq4Pk2zMtqhSnzvGrNXkL3b+h4PyNfNOGuvwR5DDuW5TuVNKcR7e tpAWwOnCD4/CeZOmHEB2IYYMrO0algI7j+EvzRvnGPSGJaVBYj0vDAGAb+9NSxP8tL4D CNk/EOaTKgYZrWMHSTQsx4CvAYUfbMFdUbKUAYgXYBb3qlIj9/dad7vRTnekFRULACiy zGq2COGzpHepS/8bXAVoc8csjb3WHaslU3Eur6ENiMSp9NipmqoadwVYNHcvRv8KUBB7 +KvQ== X-Received: by 10.68.201.97 with SMTP id jz1mr3495657pbc.26.1402021857423; Thu, 05 Jun 2014 19:30:57 -0700 (PDT) Received: from [192.168.88.218] ([111.193.165.28]) by mx.google.com with ESMTPSA id au4sm29212118pbc.10.2014.06.05.19.30.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 19:30:56 -0700 (PDT) From: Yongming Zhao Content-Type: multipart/signed; boundary="Apple-Mail=_00D6F510-B924-4A48-81C6-0654E814F7DE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: Cache Inspection Tool And Cache Stored GET URL Date: Fri, 6 Jun 2014 10:30:50 +0800 References: To: users@trafficserver.apache.org In-Reply-To: X-Mailer: Apple Mail (2.1878.2) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_00D6F510-B924-4A48-81C6-0654E814F7DE Content-Type: multipart/alternative; boundary="Apple-Mail=_A411941B-D595-41BA-9927-7F0D510F22B1" --Apple-Mail=_A411941B-D595-41BA-9927-7F0D510F22B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 yeah, this is a common issue when deal with complex remapping rules and = remapping plugins, the root cause is that the remapped URL may change in = the cache, where we use the remapped URL for the key indexing. in your case, you choose to use = =A1=AEproxy.config.url_remap.pristine_host_hdr=3D1=A1=AF to force a = remapped URL =3D UA side URL for the key, that is causing some mess. in our dealing with plugins that make complex remapping, we find that = case is a common case, and forced us to rethink that we should consider = to make some change. at last we changed the remapping in the API, to add = another API to get the remapped URL. that is not a good solution, but we = can get all those mess into one single point of view. and cache inspector is another entry to the caching details, it will be = affected by the same situation, my suggestion is we should do the same = remap conversion in all those entries. - Yongming Zhao =D5=D4=D3=C0=C3=F7 =D4=DA 2014=C4=EA6=D4=C26=C8=D5=A3=AC=C9=CF=CE=E75:56=A3=ACScott Harris = =D0=B4=B5=C0=A3=BA > I logged an issue about this last year >=20 > https://issues.apache.org/jira/browse/TS-1767 >=20 > On 06/06/2014 4:09 AM, "Jason Strongman" = wrote: >=20 > I have a remap rule of the below. >=20 > map /www.abc.com http://www.xyz.com @plugin=3Dconf_remap.so = @pparam=3Dproxy.config.url_remap.pristine_host_hdr=3D1 >=20 >=20 > When the cache inspection tool generates a URL list, the list = comprises of the re-mapped URL.=20 > When I click on a URL to view details, cache inspection tool errors = that the URL can't be found.=20 > I have to modify the URL in the lookup_url URL to match the md5 that = is stored in the cache key. >=20 > To generate the URL list, I believe the cache inspection tool is = simply dumping the cache db, then generating a list based on the value = of the stored 'GET URL' >=20 > In this case the GET URL stored is: >=20 >=20 > http://www.xyz.com/file.txt >=20 > When the end users request: >=20 > http://www.abc.com/file.txt >=20 > Keep in mind the cache key is correct - = md5sum(http://www.abc.com/file.txt). It's just the corresponding 'GET' = url stored in the cache entry is wrong. >=20 > How do I get the traffic server to store the end user URL into the = cache db? Not the re-mapped URL. >=20 >=20 --Apple-Mail=_A411941B-D595-41BA-9927-7F0D510F22B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312
yeah, this is a common issue when deal with = complex remapping rules and remapping plugins, the root cause is that = the remapped URL may change in the cache, where we use the remapped URL = for the key indexing.

in your case, you choose = to use =A1=AEproxy.config.url_remap.pristine_host_hdr=3D1=A1=AF to force = a remapped URL  =3D UA side URL for the key, that is causing some = mess.

in our dealing with plugins that make = complex remapping, we find that case is a common case, and forced us to = rethink that we should consider to make some change. at last we changed = the remapping in the API, to add another API to get the remapped URL. = that is not a good solution, but we can get all those mess into one = single point of view.

and cache inspector is = another entry to the caching details, it will be affected by the same = situation, my suggestion is we should do the same remap conversion in = all those entries.



- = Yongming Zhao =D5=D4=D3=C0=C3=F7

=D4=DA 2014=C4=EA6=D4=C26=C8=D5=A3=AC=C9=CF=CE=E75:56=A3=ACS= cott Harris <scott@harrisnet.id.au> = =D0=B4=B5=C0=A3=BA

I logged an issue about this last year

https://issues.apac= he.org/jira/browse/TS-1767

On 06/06/2014 4:09 AM, "Jason Strongman" = <jasonstrongman2016@gmail.com<= /a>> wrote:

I have a remap = rule of the below.

map /www.abc.com http://www.xyz.com @plugin=3Dconf_remap.so = @pparam=3Dproxy.config.url_remap.pristine_host_hdr=3D1


When the cache inspection tool generates a URL list, = the list comprises of the re-mapped URL.
When I click on a URL = to view details, cache inspection tool errors that the URL can't be = found.
I have to modify the URL in the lookup_url URL to match the md5 that is = stored in the cache key.

To generate the URL list, I = believe the cache inspection tool is simply dumping the cache db, then = generating a list based on the value of the stored 'GET URL'

In this case the GET URL stored is:


When = the end users request:

http://www.abc.com/file.txt

Keep in mind the cache key is correct - md5sum(http://www.abc.com/file.txt). It's just the = corresponding 'GET' url stored in the cache entry is wrong.

How do I get the traffic server to store the end user URL = into the cache db? Not the re-mapped URL.



= --Apple-Mail=_A411941B-D595-41BA-9927-7F0D510F22B1-- --Apple-Mail=_00D6F510-B924-4A48-81C6-0654E814F7DE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJTkSfaAAoJEETwKOcePlbGIh0P/idqaGShQu5FZyBKk3NbzVCZ Rtz9zs6+evcKwf3+bnxsL2ymJm/8g3bhvzdFHpBEhNvWAhBkD8XzppzTYAOpzUfo aNiytliRj048LAn3Xt62q4XxkndUNCkDeTMB+eIv0TP1A+iquHzoXC81e6EP6pFL OXkbxnD/8VjnJZVzW9mzkZbsESzYwy91RX1KhfTSaj8HUuwujxEZ/75frfv7Ji8N 1GZtEUFtroHl2Ke/PBrmUAL6WTfnqyOrlTc8gYh762XTrHLYNFaj52DL1FfQC9Ge EqQeRERJ289e3d2QRnOUAxhVwoAl/cOGf3ix+cgVk5vqu07t+Z+QPiUaY/KkDgbT EFyqgcJpZbB4fZBCCOhw4UGLwON9vxXoiikq8UqSgExqYehg9lRvofKxLMLq+E4p RobPmqLSiJJsw8An81c39sxBbzKmb3W+JxvSHIgSqnCIbNf9CEhNrwgoR+KPnxNa JVkfFuL/G630x04a7Edx3Fr2g+QZFvNMuU/T3eCWgwJAyAsnCcWMo0rcnt/iWWDL jnokMwFUea+QJVbM1MP9tJbVpWI+D/cePa0WyYRe9kxwmsD2FaVMxq6+WVOi/EvC vJWwgGD9bB6MnWCO/irU/YmukZBQW1iTEl7AvnN88qqzMnwoTbsDVlTfnEv7gTTO 8MVstjZJhdX/xCUam9FW =LtM7 -----END PGP SIGNATURE----- --Apple-Mail=_00D6F510-B924-4A48-81C6-0654E814F7DE--