[jira] [Commented] (TS-1976) Invalid httpport argument passed from traffic_manager to traffic_server

["James Peach (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13694054#comment-13694054 ] 

James Peach commented on TS-1976:
---------------------------------

Hmm, Vec seems to support "sparse" arrays (Vec::count doesn't count false entries). I agree that it might be risky to change Vec::append(Vec), but I wonder if it's a bug that the other append implementation works for this case.
                
> Invalid httpport argument passed from traffic_manager to traffic_server
> -----------------------------------------------------------------------
>
>                 Key: TS-1976
>                 URL: https://issues.apache.org/jira/browse/TS-1976
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Configuration, Management, Security
>            Reporter: Thach Tran
>
> I'm seeing a weird issue with invalid {{httpport}} option being passed from {{traffic_manager}} to {{traffic_server}} process. My ps output look a bit like this (I'm only running {{traffic_manager}} and not {{traffic_cop}})
> {noformat}
> ats      27565  0.0  0.2 374712 16176 pts/0    Sl   14:32   0:00 /trafficserver/bin/traffic_manager
> ats      27574  1.7  0.8 569440 52036 pts/0    Sl   14:32   0:03 /trafficserver/bin/traffic_server -M --httpport ip-in=[10.50.156.251]:443:fd=15:ssl,8443:fd=16:ssl?ݻ?
> {noformat}
> Notice some garbage characters at the end of {{traffic_server}}'s {{httpport}} arg. That also reflects in the log as follows.
> {noformat}
> WARNING: Invalid option 'ssl�ݻ' in port configuration '8443:fd=16:ssl�ݻ'
> {noformat}
> My server_ports in records.config is as follows.
> {noformat}
> CONFIG proxy.config.http.server_ports STRING ssl:443:ip-in=[10.50.156.251],ssl:8443
> {noformat}
> After spending some time looking at the code in {{LocalManager::startProxy}} ({{LocalManager.cc:1037}}), I believe the char {{Vec}} namely {{real_proxy_options}} is not being null-terminated despite the attempt of doing so in line 1037.
> {code}
>     // NUL-terminate for the benefit of strtok and printf.
>     real_proxy_options.append('\0');
> {code}
> This is, I think, because of the {{Vec}}'s implementation of appending from another {{Vec}} which explicitly check for if an element is 0 then don't append that element (line 352 in {{lib/ts/Vec.h}}).
> {code}
> template <class C, class A, int S> inline void
> Vec<C,A,S>::append(const Vec<C> &vv)  {
>   for (C *c = vv.v; c < vv.v + vv.n; c++)
>     if (*c != 0)
>       add(*c);
> }
> {code}
> I have no idea why the implementation of {{Vec}} is that way but I would think it's probably safer not messing around with a container class that has been used in many other places. So, my suggestion would be something like this in {{LocalManager}}.
> {code}
>     // NUL-terminate for the benefit of strtok and printf.
>     real_proxy_options.append("", 1);
> {code}
> Any thought would be very welcome.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira