Traffic Ops Range Request Handling Slice Option Breaks With Range-Related Raw Remaps #4755
Description
I'm submitting a ...
- bug report
Traffic Control components affected ...
- Traffic Ops
- Traffic Ops ORT
Current behavior:
The new Delivery Service Range Request Handling option for "Slice" added in #4455 breaks with DS Raw Remaps which need to come before it.
For example, we have a Raw Remap which manipulates the Range header, which needs to come before the Slicer. But the new feature is always hard-coded inserted into the remap.config, with Raw Remaps (which always come last) later. This breaks the DS.
This is a major issue for us, and fundamentally breaks the DS Slicer feature for our primary use cases.
Expected / new behavior:
We need a way to insert the Slicer after Raw Remaps. But Raw Remaps need to be last, and will break most existing services if they don't.
There are several possible solutions, most of which involve a great deal of complexity and operational footgunishness.
I suggest adding a __SLICER__ directive to the Raw Remap config generation, which if it exists will insert the slicer config into the remap line there; and if it doesn't exist, it's inserted right before the Raw Remap (like it is in master now).
That seems like the quickest, safest solution. It's easy to develop and maintain. It's a little "footgunish," but it makes the footgun the exception, instead of the default. All the other options I see make the unintuitive/footgun the default, and most are considerably more work to develop and maintain.
Minimal reproduction of the problem with instructions:
Use the Range Request Handling Slicer option with a Delivery Service which manipulates the Range. Observe catastrophic failure.