ezelkow1 opened a new issue #3890: Change query handling and cachekey usage
URL: https://github.com/apache/trafficcontrol/issues/3890
   ************ STOP!! ************
   If this issue identifies a security vulnerability, DO NOT submit it! 
Instead, contact
   the Apache Software Foundation Security Team at 
secur...@trafficcontrol.apache.org and follow the
   guidelines at https://www.apache.org/security/ regarding vulnerability 
   - For *SUPPORT QUESTIONS*, use the
   [Traffic Control slack channels](https://traffic-control-cdn.slack.com) or 
[Traffic Control mailing 
   - Before submitting, please **SEARCH GITHUB** for a similar issue or PR. -->
   ## I'm submitting a ...
   <!-- (check all that apply with "[x]") -->
   <!--- security vulnerability (STOP!! - see above)-->
   - [ ] bug report
   - [ ] new feature / enhancement request
   - [ ] improvement request (usability, performance, tech debt, etc.)
   - [ ] other <!--(Please do not submit support requests here - see above)-->
   ## Traffic Control components affected ...
   <!-- (check all that apply with "[x]") -->
   - [ ] CDN in a Box
   - [ ] Documentation
   - [ ] Grove
   - [ ] Traffic Control Client
   - [ ] Traffic Monitor
   - [ ] Traffic Ops
   - [ ] Traffic Ops ORT
   - [ ] Traffic Portal
   - [ ] Traffic Router
   - [ ] Traffic Stats
   - [ ] Traffic Vault
   - [ ] unknown
   ## Current behavior:
   <!-- Describe how the bug manifests / how the current features are 
insufficient. -->
   Currently it is possible to have a conflicting generated remap with cachekey 
usage. The qstring option "1" hardcodes in a cachekey plugin usage which will 
drop query strings.
   However if a user then also adds a custom cachekey via a DS profile, this 
will then override the qstring dropping. The cachekey plugin itself will always 
pull the original remapped URI to determine the new key on each instance, it is 
not passed from plugin call to plugin call.
   ## Expected / new behavior:
   <!-- Describe what the behavior would be without the bug / how the feature 
would improve Traffic Control -->
   Have one single way to change cachekeys. One idea would be a drop down like 
we currently have with common options and then a final custom option that shows 
a text entry box. That way a user only has an option of either automatic 
qstring removal, or they must do it within the new cachekey.
   ## Minimal reproduction of the problem with instructions:
   If the current behavior is a bug or you can illustrate your feature request 
better with an example,
   please provide the *STEPS TO REPRODUCE* and include the applicable TC 
   Turn on qstring option 1, this will insert a cachekey instance in to a remap 
to remove query strings.
   Then assign a cachekey to the DS profile for that DS as well (a simple one 
would be adding a --static-prefix=http://somedomainhere.com)
   If you do a curl with a query string you should see that query exist in the 
cachekey that was used
   ## Anything else:
   <!-- e.g. stacktraces, related issues, suggestions how to fix -->
   Licensed to the Apache Software Foundation (ASF) under one
   or more contributor license agreements.  See the NOTICE file
   distributed with this work for additional information
   regarding copyright ownership.  The ASF licenses this file
   to you under the Apache License, Version 2.0 (the
   "License"); you may not use this file except in compliance
   with the License.  You may obtain a copy of the License at
   Unless required by applicable law or agreed to in writing,
   software distributed under the License is distributed on an
   KIND, either express or implied.  See the License for the
   specific language governing permissions and limitations
   under the License.

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

Reply via email to