Traffic Portal should allow directories in Origin Base Server URL field

[dneuman64]

Traffic Portal will not allow a directory in the origin URL.

For example: http://myorigin works but http://myorigin/myfolder does not.

[dneuman64]

We should probably just check to ensure the URL starts with http(s) and if it ends with / then we should trim it.

[mitchell852]

The real validation should exist in the API imo. Not sure what is being validated there. I'm OK with the UI validation being a little looser (i.e. just ensure it starts with http(s)) if the API validation ensures a bad fqdn doesn't get into the db. And if any trimming needs to be done, I feel like that should happen in the API.

[dneuman64]

+1, I think the API is where the validation should happen as well.

[rawlinp]

There cannot be a path in the orgServerFqdn field; it's just a scheme, fqdn, and optional port. Why do you need to specify a path?

[dneuman64]

ah, right. Ok, I'll close. Thanks Rawlin!

[smalenfant]

@rawlinp @dneuman64 Traffic Ops let you use a path. It's actually helpful if you don't need to expose anything else and make it work like chroot.

I'm actually using this feature today in the lab. Haven't been using in production yet although it came up today in a discussion. I guess it worked, but maybe not by design. You might find this is a feature offered by other CDNs (And I recall one we were using before that let us do that.

Here's a masked example of a line in my lab:

map     http://edge.test.x.coxlab.net/     http://origin.rd.at.cox.net/path/ @plugin=header_rewrite.so @pparam=dscp/set_dscp_0.config

Not too sure about the intention there. The documentation does state the following:

The Origin Server’s base URL which includes the protocol (http or https). Example: http://movies.origin.com Must be a domain only, no directories or IP addresses

This is fully allowed by Traffic Server: https://docs.trafficserver.apache.org/en/6.1.x/admin-guide/files/remap.config.en.html

[rawlinp]

@smalenfant what version of TO were you able to add the path in the orgServerFqdn field? That's not currently allowed in the API or the TO UI, but I don't know exactly when that was prohibited. This kind of goes back to the whole duplicate origin FQDN problem, however, which IMO we should really prohibit everywhere currently since the ATS config generation can't distinguish between shared origins in different DSes that cache or handle the mid tier differently.

However, I think allowing paths in the orgServerFqdn field would allow us to differentiate parent hierarchies between shared origins in different DSes, but I think hosting.config only allows domains/hostnames, so we'd still be unable to differentiate the caching medium for shared origins with different paths.