Bug: Enabling drop qstring at edge breaks origins with explicit ports

[MattMills]

When drop qstring is enabled in TO, this regex remap config is put onto the DS:

[root@[snip] trafficserver]# cat drop_qstring.config
# DO NOT EDIT - Generated for [snip] by Traffic Ops (https://[snip]/) on Tue Oct 10 14:20:58 UTC 2017
/([^?]+) $s://$t/$1

Per ATS docs:

$t     - The host as used in the "to" portion of the remap rule
$p     - The original port number
$s     - The scheme (e.g. http) of the request

This regex remap will strip port on any origin that is configured with an explicit port (IE, http://127.0.0.1:81)

[smalenfant]

@MattMills We use the following in our drop_qstring.config: /([^?]+) $s://$t:$p/$1

[MattMills]

@smalenfant That looks like it'd put the pre-remap (incoming) port number into the remap, rather than the post-remap "to" side port... does it work as intended?

[smalenfant]

@MattMills That's what I thought too. But somehow there must be a bug and it doesn't. I'm using this in production today.

[zrhoffman]

@MattMills @rob05c Is this issue still relevant?

[MattMills]

@zrhoffman I don't work on traffic control anymore, so the easiest way to find out would likely to try a regex remap in a test environment.

[rob05c]

I'm not sure either, I'd have to test. It's been a long time since I ran ATC with non-standard ports. But we should definitely support that, it's perfectly reasonable to want to do.

It should be possible to test by configuring origins with non-80/443 ports, with drop_qstring set, and seeing if it works