[GitHub] [trafficcontrol] ocket8888 commented on issue #3552: Draft: TO/TR Consistent Hash with Query Parameters

[GitBox <gi...@apache.org>]

ocket8888 commented on issue #3552: Draft: TO/TR Consistent Hash with Query Parameters
URL: https://github.com/apache/trafficcontrol/pull/3552#issuecomment-493456472
 
 
   Idk why it doesn't show me the snippet you're commenting on, so imma just do this:
   
   > _"TR still performs consistent hashing for DNS-routed delivery services to determine which caches to return in the DNS response, it's just not at the "request path" level."_
   
   Thanks, I was very unsure about that.
   
   > _"why was this marked http only? I think this primarily applies to DNS delivery services"_
   
   Not sure. I did a lot of copy/pasting those huge DS descriptions around (now that there's a dedicated overview page I probably wanna go through and clean that up to just describe the type and link to the dedicated section - time permitting) and I wrote that before I knew it was possible to name footnotes in reST.
   
   > _"I'm not entirely positive that this regex isn't used for matching the name in a DNS request (e.g. `.*\.myds\..*` would match a `dig foo.myds.mycdn.example.com A` DNS request). I think it applies to both types."_
   
   You're not? I am! I'm positive that they *are* used for matching the name in a DNS request. Those footnotes need to get shifted down one - they should apply to `HEADER` and `PATH`, not `HOST` and `HEADER`. Not sure how/when that happened...
   
   > _"Is there any way we can _not_ duplicate this same information across multiple files? For any deliveryservice endpoint, this information should be the same. Can we have one shared common file with all this information that can then be `#include` in the various places that need it?"_
   
   Yeah I sort of mentioned that above. These should (probably) all just be links to the dedicated section, now that it exists. It's outside the scope of this PR, but it's on my radar - and it's why I chose the DS section of the "Using Traffic Ops" page to pull out first, instead of just going top-down. I really hate the way that was all copy/pasted sloppily around, and very nearly wrote them into a macro instead. But at the time getting api routes accurately, consistently, and thoroughly documented took precedence over best practices.
   
   tl;dr I was lazy, will fix.
   
   > _"it would be good to include some more context around the error here, like the delivery service xml_id, so that it could be more easily tracked down to a bad delivery service config or client (ditto for L627)"_
   
   Does Java do 'reprs'? can I just log the object or will that log a pointer value or something and I need to pick an identifying property like the xmlid?

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services