[jira] [Closed] (TS-1045) PATCH: add new TSFetchHdrGet API
[ https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach closed TS-1045. --- > PATCH: add new TSFetchHdrGet API > > > Key: TS-1045 > URL: https://issues.apache.org/jira/browse/TS-1045 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Fix For: 3.1.2 > > Attachments: 0001-Add-new-public-API-TSFetchHdrGet.patch, > 0007-Add-new-public-API-TSFetchHdrGet.patch, TS-1045-formatting.diff > > > TSFetchUrl does not provide any way to get the headers from the result. This > patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet() > and returns the headers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1082) configure always clobbers optimiser flags
[ https://issues.apache.org/jira/browse/TS-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach closed TS-1082. --- Resolution: Fixed Assignee: James Peach (was: Igor Galić) Committed r1236043 > configure always clobbers optimiser flags > - > > Key: TS-1082 > URL: https://issues.apache.org/jira/browse/TS-1082 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Fix For: 3.1.2 > > Attachments: 0001-TS-1082-Fix-optimizer-flags-detection.patch > > > If the builder specifies optimizer flags, don't flip the default to -O3. > Current behaviour is to always use -O3, since the check to disable this > doesn't work. I believe the intention if for the builder to be able to do > "CXXFLAGS=-O1 ./configure" and have the build use -O1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1082) configure always clobbers optimiser flags
[ https://issues.apache.org/jira/browse/TS-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1082: Fix Version/s: 3.1.2 > configure always clobbers optimiser flags > - > > Key: TS-1082 > URL: https://issues.apache.org/jira/browse/TS-1082 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: Igor Galić >Priority: Minor > Fix For: 3.1.2 > > Attachments: 0001-TS-1082-Fix-optimizer-flags-detection.patch > > > If the builder specifies optimizer flags, don't flip the default to -O3. > Current behaviour is to always use -O3, since the check to disable this > doesn't work. I believe the intention if for the builder to be able to do > "CXXFLAGS=-O1 ./configure" and have the build use -O1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1077) HTTP ports cannot be configured for IPv6 and transparency.
[ https://issues.apache.org/jira/browse/TS-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1077: Attachment: ts-1077.diff > HTTP ports cannot be configured for IPv6 and transparency. > -- > > Key: TS-1077 > URL: https://issues.apache.org/jira/browse/TS-1077 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.1.1 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Labels: configuration, http, ipv6, ports > Fix For: 3.1.2 > > Attachments: ts-1077.diff, ts-1077.txt > > > The syntax of records.config has IPv6 and transparency as mutually exclusive > options. This should be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1077) HTTP ports cannot be configured for IPv6 and transparency.
[ https://issues.apache.org/jira/browse/TS-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1077: Attachment: ts-1077.txt > HTTP ports cannot be configured for IPv6 and transparency. > -- > > Key: TS-1077 > URL: https://issues.apache.org/jira/browse/TS-1077 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.1.1 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Labels: configuration, http, ipv6, ports > Fix For: 3.1.2 > > Attachments: ts-1077.diff, ts-1077.txt > > > The syntax of records.config has IPv6 and transparency as mutually exclusive > options. This should be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1077) HTTP ports cannot be configured for IPv6 and transparency.
[ https://issues.apache.org/jira/browse/TS-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1077: Attachment: (was: ts-1077.diff) > HTTP ports cannot be configured for IPv6 and transparency. > -- > > Key: TS-1077 > URL: https://issues.apache.org/jira/browse/TS-1077 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.1.1 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Labels: configuration, http, ipv6, ports > Fix For: 3.1.2 > > > The syntax of records.config has IPv6 and transparency as mutually exclusive > options. This should be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-448) Provide the ability to bind to more than one interface
[ https://issues.apache.org/jira/browse/TS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-448. -- Resolution: Duplicate Marking as duplicate of TS-1077. > Provide the ability to bind to more than one interface > -- > > Key: TS-448 > URL: https://issues.apache.org/jira/browse/TS-448 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 2.1.0 >Reporter: Shaun McGinnity >Priority: Minor > > If I am running Traffic Server on a machine with multiple interfaces I would > like to able to bind to a subset of those interfaces. > > I can bind to all or one using "proxy.local.incoming_ip_to_bind" but can't > bind to more than one, but not all. > It would also be useful to be able to specify different listening ports per > interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-448) Provide the ability to bind to more than one interface
[ https://issues.apache.org/jira/browse/TS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-448: - Fix Version/s: (was: 3.1.3) > Provide the ability to bind to more than one interface > -- > > Key: TS-448 > URL: https://issues.apache.org/jira/browse/TS-448 > Project: Traffic Server > Issue Type: Improvement > Components: Network >Affects Versions: 2.1.0 >Reporter: Shaun McGinnity >Priority: Minor > > If I am running Traffic Server on a machine with multiple interfaces I would > like to able to bind to a subset of those interfaces. > > I can bind to all or one using "proxy.local.incoming_ip_to_bind" but can't > bind to more than one, but not all. > It would also be useful to be able to specify different listening ports per > interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-767) Make the cluster interface configurable
[ https://issues.apache.org/jira/browse/TS-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193463#comment-13193463 ] Leif Hedstrom commented on TS-767: -- We should look into this in relation to the changes being made for TS-1077. > Make the cluster interface configurable > --- > > Key: TS-767 > URL: https://issues.apache.org/jira/browse/TS-767 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration, Network >Affects Versions: 2.1.8 >Reporter: Arno Toell >Priority: Minor > Fix For: 3.1.3 > > > I consider the way how Traffic Server opens listening ports dangerous, or at > least more risky than necessary. Currently ATS allows to configure port > numbers for the related services, but not the listening interface. Instead it > binds to 0.0.0.0. Therefore I'd like to suggest > * -Allow the user to specify a listening interface, don't assume 0.0.0.0 > suits for all setups.- > * -Disable the "autoconfiguration port" (i.e. 8083 by default) unless > proxy.local.cluster.type is set to enable clustering (!= 3). I think > _traffic_shell_ and eventually _traffic_line_ use this port to configure ATS > locally. If so it should be bound to the loop back at least or using Unix > Domain Sockets or whatever local socket method you prefer.- > * Disable the "reliable service port" (i.e. 8088 by default) unless > proxy.local.cluster.type enables clustering. Similar to the > "autoconfiguration port". If _traffic_cop_ (or something else on the local > machine) is using this port, the same suggestions apply as above. > * -The "internal communication port" (8084) should not open a public socket > at all. Instead use Unix Domain Sockets or something similar.- > n.b. striked through issues are obsolete or tracked in TS-765. For the > remaining issue is worth to be added the comment from TS-765: > 8088 is no problem anymore until clustering is enabled, so there is only the > TS-766 improvement left there. However if enabled, I think it is still fairly > useful to allow the user to bind to a specific IP. Say, you run a public > facing proxy in cluster mode where you want to communicate in between on > private IPs between cluster peers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-523) [GSoC2011] Allow the use of multiple SSL ports
[ https://issues.apache.org/jira/browse/TS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-523. -- Resolution: Duplicate Duplicated of TS-1077 > [GSoC2011] Allow the use of multiple SSL ports > -- > > Key: TS-523 > URL: https://issues.apache.org/jira/browse/TS-523 > Project: Traffic Server > Issue Type: New Feature > Components: Configuration, SSL >Affects Versions: 2.1.3 >Reporter: Marcus Clyne >Priority: Minor > Labels: gsoc2011, ssl > > Currently proxy.config.ssl.server_port allows only one SSL port to be > specified, and it appears that it is not possible to specify multiple ports > for SSL like proxy.config.http.server_other_ports. > It would make sense to have a single directive as a string for all SSL ports, > rather than have two config options like HTTP ports (a separate ticket has > been posted for that - see https://issues.apache.org/jira/browse/TS-524). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-523) [GSoC2011] Allow the use of multiple SSL ports
[ https://issues.apache.org/jira/browse/TS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-523: - Fix Version/s: (was: 3.1.3) > [GSoC2011] Allow the use of multiple SSL ports > -- > > Key: TS-523 > URL: https://issues.apache.org/jira/browse/TS-523 > Project: Traffic Server > Issue Type: New Feature > Components: Configuration, SSL >Affects Versions: 2.1.3 >Reporter: Marcus Clyne >Priority: Minor > Labels: gsoc2011, ssl > > Currently proxy.config.ssl.server_port allows only one SSL port to be > specified, and it appears that it is not possible to specify multiple ports > for SSL like proxy.config.http.server_other_ports. > It would make sense to have a single directive as a string for all SSL ports, > rather than have two config options like HTTP ports (a separate ticket has > been posted for that - see https://issues.apache.org/jira/browse/TS-524). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-524) Have a single directive for HTTP ports
[ https://issues.apache.org/jira/browse/TS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-524. -- Resolution: Fixed Duplicate of TS-1077. > Have a single directive for HTTP ports > -- > > Key: TS-524 > URL: https://issues.apache.org/jira/browse/TS-524 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Affects Versions: 3.0.0 > Environment: Any >Reporter: Marcus Clyne >Priority: Trivial > > Why have both > proxy.config.http.server_port > and > proxy.config.http.server_other_ports > as config options? Unless there is a good reason to have to options, it > would probably be better to have a single config option. > See also https://issues.apache.org/jira/browse/TS-523 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-524) Have a single directive for HTTP ports
[ https://issues.apache.org/jira/browse/TS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-524: - Fix Version/s: (was: 3.1.4) > Have a single directive for HTTP ports > -- > > Key: TS-524 > URL: https://issues.apache.org/jira/browse/TS-524 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Affects Versions: 3.0.0 > Environment: Any >Reporter: Marcus Clyne >Priority: Trivial > > Why have both > proxy.config.http.server_port > and > proxy.config.http.server_other_ports > as config options? Unless there is a good reason to have to options, it > would probably be better to have a single config option. > See also https://issues.apache.org/jira/browse/TS-523 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1084) enable compile-time format string checking
[ https://issues.apache.org/jira/browse/TS-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1084: - Assignee: James Peach (was: Leif Hedstrom) > enable compile-time format string checking > -- > > Key: TS-1084 > URL: https://issues.apache.org/jira/browse/TS-1084 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Attachments: 0001-TS-1084-Add-format-string-checking.patch > > > Add format string checking. > > Add format string checking to internal and external APIs that take > a printf(3) format string. No functional changes. > > Fix all the resulting warnings > - time_t is formatted as long long for portability > - size_t became %zu > - pointers all became %p -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1083) initial SSL next protocol negotiation support
[ https://issues.apache.org/jira/browse/TS-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1083: - Assignee: James Peach (was: Leif Hedstrom) > initial SSL next protocol negotiation support > - > > Key: TS-1083 > URL: https://issues.apache.org/jira/browse/TS-1083 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Attachments: > 0001-Compile-time-detection-of-NextProtocolNegotiation-su.patch, > 0002-Initial-NPN-plumbing.patch > > > Initial autoconf support for detecting OpenSSL Next Protocol Negotiation > APIs. Advertise that we support HTTP/1.0 and HTTP/1.1. Because we do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1024) remap_required 0 not functioning in revproxy mode
[ https://issues.apache.org/jira/browse/TS-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1024: - Assignee: (was: Leif Hedstrom) > remap_required 0 not functioning in revproxy mode > - > > Key: TS-1024 > URL: https://issues.apache.org/jira/browse/TS-1024 > Project: Traffic Server > Issue Type: Bug > Components: Remap API >Affects Versions: 3.0.2 >Reporter: Greg Dallavalle >Priority: Minor > Labels: parent, remap_required > Fix For: sometime > > > with > [records.config] > proxy.config.url_remap.remap_required INT 0 > proxy.config.http.parent_proxy_routing_enable INT 1 > proxy.config.http.no_dns_just_forward_to_parent INT 1 > ATS still requires a remap URL to be used. The way I worked around this was > to have remapped URLs to themselves: > [remap.config] > map http://example.com http://example.com > map http://sub.example.com http://sub.example.com > With those settings all requests are passed through to my origin, or "parent > cache" servers. The pass to the parent cache did not work in 3.0.1. I had > to build from the 3.0.x branch for this to function. > [parent.config] > dest_domain=. parent="1.2.3.4:80; 4.5.6.7:80" round_robin=strict > I think this is convoluted given my fairly common setup of two reverse > proxies caching/load balancing round robin to a few origin servers. I guess > the only "bug" here is that the remap_required parameter is not functioning > as well as it could be. I hope for improvement in the way this setup is > handled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1024) remap_required 0 not functioning in revproxy mode
[
https://issues.apache.org/jira/browse/TS-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1024:
--
Fix Version/s: (was: 3.1.3)
sometime
Moving this out to to "later" for now.
So, the "issue" here is that enabling "reverse proxy" sort of interferes with
the parent proxy behavior here. If you disable reverse proxy (non-intuitive),
and make sure that all requests are proxied to a parent proxy, I think it
should work. The thing is, enabling "reverse proxy" currently implies that some
sort of "mapping" should be done. So, in a pure parent proxy setup, you want
{code}
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
CONFIG proxy.config.reverse_proxy.enabled INT 0
CONFIG proxy.config.url_remap.remap_required INT 0
{code}
And then, you shouldn't need anything at all in remap.config (it's never
consulted since reverse_proxy is disabled).
You have to be pretty careful in this setup, and assure that you parent proxy
every request (otherwise, since remap isn't required, you could become an open
proxy). We have sort of overloaded too much semantics into these two
configuration options, hence, we might want to revisit it later (and redo it
completely). The way I tend to see it is that requiring (and configuring) remap
also acts as a "whitelist" of what requests should be proxied.
Let me know what you think.
> remap_required 0 not functioning in revproxy mode
> -
>
> Key: TS-1024
> URL: https://issues.apache.org/jira/browse/TS-1024
> Project: Traffic Server
> Issue Type: Bug
> Components: Remap API
>Affects Versions: 3.0.2
>Reporter: Greg Dallavalle
>Assignee: Leif Hedstrom
>Priority: Minor
> Labels: parent, remap_required
> Fix For: sometime
>
>
> with
> [records.config]
> proxy.config.url_remap.remap_required INT 0
> proxy.config.http.parent_proxy_routing_enable INT 1
> proxy.config.http.no_dns_just_forward_to_parent INT 1
> ATS still requires a remap URL to be used. The way I worked around this was
> to have remapped URLs to themselves:
> [remap.config]
> map http://example.com http://example.com
> map http://sub.example.com http://sub.example.com
> With those settings all requests are passed through to my origin, or "parent
> cache" servers. The pass to the parent cache did not work in 3.0.1. I had
> to build from the 3.0.x branch for this to function.
> [parent.config]
> dest_domain=. parent="1.2.3.4:80; 4.5.6.7:80" round_robin=strict
> I think this is convoluted given my fairly common setup of two reverse
> proxies caching/load balancing round robin to a few origin servers. I guess
> the only "bug" here is that the remap_required parameter is not functioning
> as well as it could be. I hope for improvement in the way this setup is
> handled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-876) forward map based on request receive port
[ https://issues.apache.org/jira/browse/TS-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-876: Assignee: Brian Geffon (was: Leif Hedstrom) > forward map based on request receive port > - > > Key: TS-876 > URL: https://issues.apache.org/jira/browse/TS-876 > Project: Traffic Server > Issue Type: New Feature > Components: Remap API >Reporter: Manjesh Nilange >Assignee: Brian Geffon > Fix For: 3.1.0 > > Attachments: map_with_recv_port.patch > > > Currently the port in the "from" fields of all remap rules are compared > against the port in the request (explicitly in the request or implicitly > deduced from the protocol). TS supports listening on multiple ports, so there > is a use case for a remap rule that uses the TS port at which the request is > received instead of the "request port". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1004) transformation plugins cause connection close when content length is not known ahead
[ https://issues.apache.org/jira/browse/TS-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1004: - Assignee: Brian Geffon (was: Leif Hedstrom) > transformation plugins cause connection close when content length is not > known ahead > > > Key: TS-1004 > URL: https://issues.apache.org/jira/browse/TS-1004 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, Plugins >Affects Versions: 3.0.1 >Reporter: Otto van der Schaaf >Assignee: Brian Geffon > Fix For: 3.1.1 > > Attachments: chunk_transform_response.diff > > > whenever the null transform plugin (or gzip) is executed, ATS will force the > ua connection closed. > when the user agent supports it, sending a chunked response w/ keepalive > enabled would be preferred i guess > i'll add a patch for review. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.
[ https://issues.apache.org/jira/browse/TS-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1074: - Assignee: Brian Geffon (was: Leif Hedstrom) > PluginVC should schedule to the local queue instead of the external queue. > -- > > Key: TS-1074 > URL: https://issues.apache.org/jira/browse/TS-1074 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.0.1 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.1.2 > > Attachments: PluginVC.patch > > > In TS-867 a patch was introduced to resolve a crash that was appearing w/ > TSFetchURL, the patch would schedule events on the same thread if it is a net > thread, if not it will only then schedule with the event processor. If you're > scheduling on the same thread, wouldn't it be more efficient to place the > event directly on the local queue? It turns out that going to the > ExternalQueue under low load it would cause the event to become delayed. > Patch Attached. > To best see the symptoms see complaints in (TS-912 and TS-1043). > I have verified that this patch fixes the 10ms symptom seen in TS-912 and > TS-1043. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TS-1004) transformation plugins cause connection close when content length is not known ahead
[ https://issues.apache.org/jira/browse/TS-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reopened TS-1004: -- Backport to Version: 3.0.3 Have been using this patch for a while in 3.0.2 and it should be considered for backport to 3.0.3. > transformation plugins cause connection close when content length is not > known ahead > > > Key: TS-1004 > URL: https://issues.apache.org/jira/browse/TS-1004 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, Plugins >Affects Versions: 3.0.1 >Reporter: Otto van der Schaaf >Assignee: Leif Hedstrom > Fix For: 3.1.1 > > Attachments: chunk_transform_response.diff > > > whenever the null transform plugin (or gzip) is executed, ATS will force the > ua connection closed. > when the user agent supports it, sending a chunked response w/ keepalive > enabled would be preferred i guess > i'll add a patch for review. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TS-876) forward map based on request receive port
[ https://issues.apache.org/jira/browse/TS-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reopened TS-876: - Backport to Version: 3.0.3 Assignee: Leif Hedstrom (was: vijaya bhaskar mamidi) This applies cleanly to 3.0.2 for me and should be considered for 3.0.3 > forward map based on request receive port > - > > Key: TS-876 > URL: https://issues.apache.org/jira/browse/TS-876 > Project: Traffic Server > Issue Type: New Feature > Components: Remap API >Reporter: Manjesh Nilange >Assignee: Leif Hedstrom > Fix For: 3.1.0 > > Attachments: map_with_recv_port.patch > > > Currently the port in the "from" fields of all remap rules are compared > against the port in the request (explicitly in the request or implicitly > deduced from the protocol). TS supports listening on multiple ports, so there > is a use case for a remap rule that uses the TS port at which the request is > received instead of the "request port". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TS-1074) PluginVC should schedule to the local queue instead of the external queue.
[ https://issues.apache.org/jira/browse/TS-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reopened TS-1074: -- Backport to Version: 3.0.3 This should be considered for backporting to 3.0.3. > PluginVC should schedule to the local queue instead of the external queue. > -- > > Key: TS-1074 > URL: https://issues.apache.org/jira/browse/TS-1074 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.0.1 >Reporter: Brian Geffon >Assignee: Leif Hedstrom > Fix For: 3.1.2 > > Attachments: PluginVC.patch > > > In TS-867 a patch was introduced to resolve a crash that was appearing w/ > TSFetchURL, the patch would schedule events on the same thread if it is a net > thread, if not it will only then schedule with the event processor. If you're > scheduling on the same thread, wouldn't it be more efficient to place the > event directly on the local queue? It turns out that going to the > ExternalQueue under low load it would cause the event to become delayed. > Patch Attached. > To best see the symptoms see complaints in (TS-912 and TS-1043). > I have verified that this patch fixes the 10ms symptom seen in TS-912 and > TS-1043. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1077) HTTP ports cannot be configured for IPv6 and transparency.
[ https://issues.apache.org/jira/browse/TS-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1077: Attachment: ts-1077.diff Default proxy port regression test related failures fixed. Fixed missing TsBuffer.h file. > HTTP ports cannot be configured for IPv6 and transparency. > -- > > Key: TS-1077 > URL: https://issues.apache.org/jira/browse/TS-1077 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.1.1 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Labels: configuration, http, ipv6, ports > Fix For: 3.1.2 > > Attachments: ts-1077.diff > > > The syntax of records.config has IPv6 and transparency as mutually exclusive > options. This should be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1077) HTTP ports cannot be configured for IPv6 and transparency.
[ https://issues.apache.org/jira/browse/TS-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1077: Attachment: (was: ts-1077.diff) > HTTP ports cannot be configured for IPv6 and transparency. > -- > > Key: TS-1077 > URL: https://issues.apache.org/jira/browse/TS-1077 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.1.1 >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Labels: configuration, http, ipv6, ports > Fix For: 3.1.2 > > Attachments: ts-1077.diff > > > The syntax of records.config has IPv6 and transparency as mutually exclusive > options. This should be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1083) initial SSL next protocol negotiation support
[ https://issues.apache.org/jira/browse/TS-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193110#comment-13193110 ] James Peach commented on TS-1083: - Let's just leave the patch as it. It's overkill but harmless overkill. > initial SSL next protocol negotiation support > - > > Key: TS-1083 > URL: https://issues.apache.org/jira/browse/TS-1083 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: James Peach >Assignee: Leif Hedstrom >Priority: Minor > Attachments: > 0001-Compile-time-detection-of-NextProtocolNegotiation-su.patch, > 0002-Initial-NPN-plumbing.patch > > > Initial autoconf support for detecting OpenSSL Next Protocol Negotiation > APIs. Advertise that we support HTTP/1.0 and HTTP/1.1. Because we do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1091.
---
Resolution: Fixed
> `./configure CFLAGS=-w` causes configure script to wrongly guess style of
> `gethostbyname_r` on OS X (and probably other BSDs)
> -
>
> Key: TS-1091
> URL: https://issues.apache.org/jira/browse/TS-1091
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.0.2
> Environment: OS X 10.6.8
>Reporter: Marc Abramowitz
>Assignee: Leif Hedstrom
>Priority: Minor
> Labels: autoconf, build, configure
> Fix For: 3.1.2
>
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> {code}
> marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
> | grep 'System Version'
> System Version: Mac OS X 10.6.8 (10K549)
> marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
> ...
> checking style of gethostbyname_r routine... glibc2
> checking 3rd argument to the gethostbyname_r routines... hostent_data
> configure: Build using CC=gcc
> configure: Build using CXX=g++
> configure: Build using CPP=gcc -E
> configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
> -feliminate-unused-debug-symbols -fno-strict-aliasing
> ...
> marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
> gethostbyname_r_glibc2 = 1
> gethostbyname_r_hostent_data = 1
> marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
> ...
> ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
> ink_gethostbyaddr_r_data*)':
> ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7'
> to 'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int,
> int*)'
> make[3]: *** [ink_inet.lo] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all-recursive] Error 1
> {code}
> Arguably, people should never run configure with CFLAGS=-w and this might
> seem stupid and something that should never happen, but it turns out that
> Homebrew (http://mxcl.github.com/homebrew/) does this by default
> (https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
> writing a Homebrew formula for Traffic Server
> (https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
> causing problems, I modified my formula to tell Homebrew not to do this and
> all is well, but I thought it would be interesting to make Traffic Server
> resistant to this as well.
> I first tried to enable warnings by trying to find a gcc #pragma that could
> go in the conftest.c code
> (http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html looked promising
> but I could not find one that worked), but I could not find any #pragma that
> seemed to do this.
> I ended up making a small change to `build/common.m4` that strips -w out of
> CFLAGS using `sed`.
> {code}
> --- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
> +++ build/common.m4 2012-01-22 22:48:14.0 -0800
> @@ -177,6 +177,7 @@
> if test "$ac_cv_prog_gcc" = "yes"; then
> CFLAGS="$CFLAGS -Werror"
> fi
> + CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e
> 's/ -w / /')
> AC_COMPILE_IFELSE([AC_LANG_SOURCE([
>[#include "confdefs.h"
>]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1035) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults
[ https://issues.apache.org/jira/browse/TS-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192951#comment-13192951 ] Brian Geffon commented on TS-1035: -- So I have an issue here, I wanted to make MAX_EVENT_THREADS and MAX_THREADS_IN_EACH_TYPE records.configurable and what I realized is that EventProcessor is statically constructed so I won't have access to records.config when the event processor is constructed. Any suggestions? i'm thinking at this point it might just make more sense to set the limits high since the memory overhead is negligible (it's an array of MAX_EVENT_THREAD pointers) rather than making it configurable, thoughts? > EventProcessor::spawn_thread doesn't check that there is enough event threads > and segfaults > --- > > Key: TS-1035 > URL: https://issues.apache.org/jira/browse/TS-1035 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 3.0.1 >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.1.3 > > Attachments: LargeNumberOfPorts.patch, UnixEventProcessor.patch > > > The easiest way to see this bug is to use several hundred ports with accept > threads turned on. The bug exists because in I_EventProcessor.h there is a > hard coded limit of 512 event threads and there is no check in spawn_thread > that you haven't exceeded that limit so it will result in a segfault if > you're creating too many threads. From what I can tell the best solution is > an assertion that you haven't exceeded MAX_EVENT_THREADS. > Patch is included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
