[jira] [Assigned] (TS-2610) Add client_req_proto_type, %cqpt field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang reassigned TS-2610:
Assignee: Yunkai Zhang
Add client_req_proto_type, %cqpt field into LogFormat
-
Key: TS-2610
URL: https://issues.apache.org/jira/browse/TS-2610
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Attachments:
0001-TS-2610-Indroduce-TSHttpConnectWithProtoType-API.patch,
0002-TS-2610-Add-client_req_proto_type-cqpt-field-into-Lo.patch
This ticket was split from SPDY ticket(TS-2431).
Add %cqpt field into LogFormat, so that we can distinguish the protocol
type of each log record, it can help us to to do some analysis and statistic.
Here are the available values of %cqpt:
{code}
HTTP -- HTTP protocol
HTTP_SSL -- HTTP with SSL protocol
HTTP_SPDY -- HTTP with SPDY protocol
HTTP_SPDY_SSL -- HTTP with SPDY with SSL protocol
{code}
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoType(struct sockaddr const* addr,
TSNetProtoType proto_type);
{code}
After introducing TSHttpConnectWithProtoType() API, TSHttpConnect() API would
be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoType(addr, TS_NET_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2611) AddS3 Auth plugin
[ https://issues.apache.org/jira/browse/TS-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2611: - Assignee: Leif Hedstrom AddS3 Auth plugin - Key: TS-2611 URL: https://issues.apache.org/jira/browse/TS-2611 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 This adds some basic v2 S3 Auth features, we can extend later with more features. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2611) AddS3 Auth plugin
Leif Hedstrom created TS-2611: - Summary: AddS3 Auth plugin Key: TS-2611 URL: https://issues.apache.org/jira/browse/TS-2611 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom This adds some basic v2 S3 Auth features, we can extend later with more features. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2611) AddS3 Auth plugin
[ https://issues.apache.org/jira/browse/TS-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2611: -- Fix Version/s: 5.0.0 AddS3 Auth plugin - Key: TS-2611 URL: https://issues.apache.org/jira/browse/TS-2611 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Fix For: 5.0.0 This adds some basic v2 S3 Auth features, we can extend later with more features. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2522) Rewrite header_rewrite hook management
[ https://issues.apache.org/jira/browse/TS-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919126#comment-13919126 ] ASF subversion and git services commented on TS-2522: - Commit 4f0b0b447ed76244287ae5385719fc56b3385a24 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4f0b0b4 ] TS-2522 Update the docs with new default conf dir Rewrite header_rewrite hook management -- Key: TS-2522 URL: https://issues.apache.org/jira/browse/TS-2522 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 Right now, we use a transaction slot to pass information from remap state over to one of the normal hooks. Because of the way this plugin works, I think this can be optimized away. What we should do is to have one global continuation for each remap rule, and schedule it from the remap plugin. This avoids having all the global hooks checking the transaction state (slot) every time. It's also very cheap to schedule a transaction hook, it's O(1) simply appending it to a linked list of hooks. If the hook doesn't get invoked, it's mostly a no-op. Finally, this avoids consuming one of the limited transaction hooks, and at the same time reduces overhead by only executing hooks when necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2522) Rewrite header_rewrite hook management
[ https://issues.apache.org/jira/browse/TS-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919125#comment-13919125 ] ASF subversion and git services commented on TS-2522: - Commit 31792d2aae9519e0feb66ab9e80b1a9d5d51d7de in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=31792d2 ] TS-2522 Better hook management, and cleanup This also does - Add support for system wide config directory as default - Better debug messages (textual hook names etc.) - Less overhead on creating TXN hooks Rewrite header_rewrite hook management -- Key: TS-2522 URL: https://issues.apache.org/jira/browse/TS-2522 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 Right now, we use a transaction slot to pass information from remap state over to one of the normal hooks. Because of the way this plugin works, I think this can be optimized away. What we should do is to have one global continuation for each remap rule, and schedule it from the remap plugin. This avoids having all the global hooks checking the transaction state (slot) every time. It's also very cheap to schedule a transaction hook, it's O(1) simply appending it to a linked list of hooks. If the hook doesn't get invoked, it's mostly a no-op. Finally, this avoids consuming one of the limited transaction hooks, and at the same time reduces overhead by only executing hooks when necessary. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2611) AddS3 Auth plugin
[ https://issues.apache.org/jira/browse/TS-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919137#comment-13919137 ] ASF subversion and git services commented on TS-2611: - Commit 1c948c38045f41dd69ca2e1356b96dc0135f4f00 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1c948c3 ] TS-2611 Add a new S3 auth plugin, experimental/s3_auth AddS3 Auth plugin - Key: TS-2611 URL: https://issues.apache.org/jira/browse/TS-2611 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 This adds some basic v2 S3 Auth features, we can extend later with more features. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2610) Add client_req_proto_type, %cqpt field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919139#comment-13919139
]
Leif Hedstrom commented on TS-2610:
---
This feels a little weird, is this tied to some (yet to be committed) SPDY
features of the core? What I'm saying is, it feels the log tag values should
not be hardcoded like this, but should come from the ALPN / NPN negotiation.
Otherwise, how do we intend for this to work generically, and particularly, for
HTTP/2 once we support that ?
Add client_req_proto_type, %cqpt field into LogFormat
-
Key: TS-2610
URL: https://issues.apache.org/jira/browse/TS-2610
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Attachments:
0001-TS-2610-Indroduce-TSHttpConnectWithProtoType-API.patch,
0002-TS-2610-Add-client_req_proto_type-cqpt-field-into-Lo.patch
This ticket was split from SPDY ticket(TS-2431).
Add %cqpt field into LogFormat, so that we can distinguish the protocol
type of each log record, it can help us to to do some analysis and statistic.
Here are the available values of %cqpt:
{code}
HTTP -- HTTP protocol
HTTP_SSL -- HTTP with SSL protocol
HTTP_SPDY -- HTTP with SPDY protocol
HTTP_SPDY_SSL -- HTTP with SPDY with SSL protocol
{code}
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoType(struct sockaddr const* addr,
TSNetProtoType proto_type);
{code}
After introducing TSHttpConnectWithProtoType() API, TSHttpConnect() API would
be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoType(addr, TS_NET_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2610) Add client_req_proto_type, %cqpt field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2610:
--
Fix Version/s: 5.0.0
Add client_req_proto_type, %cqpt field into LogFormat
-
Key: TS-2610
URL: https://issues.apache.org/jira/browse/TS-2610
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0001-TS-2610-Indroduce-TSHttpConnectWithProtoType-API.patch,
0002-TS-2610-Add-client_req_proto_type-cqpt-field-into-Lo.patch
This ticket was split from SPDY ticket(TS-2431).
Add %cqpt field into LogFormat, so that we can distinguish the protocol
type of each log record, it can help us to to do some analysis and statistic.
Here are the available values of %cqpt:
{code}
HTTP -- HTTP protocol
HTTP_SSL -- HTTP with SSL protocol
HTTP_SPDY -- HTTP with SPDY protocol
HTTP_SPDY_SSL -- HTTP with SPDY with SSL protocol
{code}
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoType(struct sockaddr const* addr,
TSNetProtoType proto_type);
{code}
After introducing TSHttpConnectWithProtoType() API, TSHttpConnect() API would
be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoType(addr, TS_NET_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2610) Add client_req_proto_type, %cqpt field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919142#comment-13919142
]
Leif Hedstrom commented on TS-2610:
---
Alright, I now see that the 0001 patch provides some special cases used for
these log tags. At a minimum, I feel these two commits should be on two
different Jira tickets, since they are different issues. One can be linked to
the other though.
I still feel that the log values ought to be tied to the ALPN negotiation
though, which perhaps also affects both of these patches ? I guess I have to
defer to [~jamespeach] here, he's the SSL guru.
Add client_req_proto_type, %cqpt field into LogFormat
-
Key: TS-2610
URL: https://issues.apache.org/jira/browse/TS-2610
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0001-TS-2610-Indroduce-TSHttpConnectWithProtoType-API.patch,
0002-TS-2610-Add-client_req_proto_type-cqpt-field-into-Lo.patch
This ticket was split from SPDY ticket(TS-2431).
Add %cqpt field into LogFormat, so that we can distinguish the protocol
type of each log record, it can help us to to do some analysis and statistic.
Here are the available values of %cqpt:
{code}
HTTP -- HTTP protocol
HTTP_SSL -- HTTP with SSL protocol
HTTP_SPDY -- HTTP with SPDY protocol
HTTP_SPDY_SSL -- HTTP with SPDY with SSL protocol
{code}
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoType(struct sockaddr const* addr,
TSNetProtoType proto_type);
{code}
After introducing TSHttpConnectWithProtoType() API, TSHttpConnect() API would
be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoType(addr, TS_NET_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2609) Header rewrite plugin TOHOST condition
[ https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2609: -- Fix Version/s: 5.0.0 Header rewrite plugin TOHOST condition -- Key: TS-2609 URL: https://issues.apache.org/jira/browse/TS-2609 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Anil Kumar Myla Priority: Minor Fix For: 5.0.0 Enhance header rewrite plugin to support TOHOST condition. Header rewrites conditioned on the final origin server will be supported. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2610) Add client_req_proto_type, %cqpt field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919146#comment-13919146
]
Yunkai Zhang commented on TS-2610:
--
For SSL, we can make the log values to be tied to the ALPN negotiation.
But for SPDY + HTTP without SSL, there is not negotiation:(
If you have any good idea, I'm ok to change these log values.
Add client_req_proto_type, %cqpt field into LogFormat
-
Key: TS-2610
URL: https://issues.apache.org/jira/browse/TS-2610
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0001-TS-2610-Indroduce-TSHttpConnectWithProtoType-API.patch,
0002-TS-2610-Add-client_req_proto_type-cqpt-field-into-Lo.patch
This ticket was split from SPDY ticket(TS-2431).
Add %cqpt field into LogFormat, so that we can distinguish the protocol
type of each log record, it can help us to to do some analysis and statistic.
Here are the available values of %cqpt:
{code}
HTTP -- HTTP protocol
HTTP_SSL -- HTTP with SSL protocol
HTTP_SPDY -- HTTP with SPDY protocol
HTTP_SPDY_SSL -- HTTP with SPDY with SSL protocol
{code}
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoType(struct sockaddr const* addr,
TSNetProtoType proto_type);
{code}
After introducing TSHttpConnectWithProtoType() API, TSHttpConnect() API would
be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoType(addr, TS_NET_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2609) Header rewrite plugin TOHOST condition
[
https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919156#comment-13919156
]
Leif Hedstrom commented on TS-2609:
---
I'm not against this patch, but I do have a question. Is this fundamental
different than doing e.g.
{code}
cond %{CLIENT-HEADER:Host} =www.ogre.com
{code}
My preference is probably to not have more than one way to achieve the same
thing (*cough* Perl *cough*), but if there are good reasons to add the TOHOST
directive, I'd be ok with that. Fwiw, I feel it ought to be named TO-HOST or
CLIENT-HOST or even just HOST if we go this path :).
Also, if you look at how we have an adaptive HEADER condition, a
functionality like %{HOST} would similarly adapt to the hook it's in, whereas
CLIENT-HOST would be anchored to the client request header.
What do you think?
Header rewrite plugin TOHOST condition
--
Key: TS-2609
URL: https://issues.apache.org/jira/browse/TS-2609
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Anil Kumar Myla
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 5.0.0
Enhance header rewrite plugin to support TOHOST condition. Header rewrites
conditioned on the final origin server will be supported.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2609) Header rewrite plugin TOHOST condition
[
https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919156#comment-13919156
]
Leif Hedstrom edited comment on TS-2609 at 3/4/14 9:03 AM:
---
I'm not against this patch, but I do have a question. Is this fundamentally
different than doing e.g.
{code}
cond %{CLIENT-HEADER:Host} =www.ogre.com
{code}
My preference is probably to not have more than one way to achieve the same
thing (*cough* Perl *cough*), but if there are good reasons to add the TOHOST
directive, I'd be ok with that. Fwiw, I feel it ought to be named TO-HOST or
CLIENT-HOST or even just HOST if we go this path :).
Also, if you look at how we have an adaptive HEADER condition, a
functionality like %{HOST} would similarly adapt to the hook it's in, whereas
CLIENT-HOST would be anchored to the client request header.
What do you think?
was (Author: zwoop):
I'm not against this patch, but I do have a question. Is this fundamental
different than doing e.g.
{code}
cond %{CLIENT-HEADER:Host} =www.ogre.com
{code}
My preference is probably to not have more than one way to achieve the same
thing (*cough* Perl *cough*), but if there are good reasons to add the TOHOST
directive, I'd be ok with that. Fwiw, I feel it ought to be named TO-HOST or
CLIENT-HOST or even just HOST if we go this path :).
Also, if you look at how we have an adaptive HEADER condition, a
functionality like %{HOST} would similarly adapt to the hook it's in, whereas
CLIENT-HOST would be anchored to the client request header.
What do you think?
Header rewrite plugin TOHOST condition
--
Key: TS-2609
URL: https://issues.apache.org/jira/browse/TS-2609
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Anil Kumar Myla
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 5.0.0
Enhance header rewrite plugin to support TOHOST condition. Header rewrites
conditioned on the final origin server will be supported.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2609) Header rewrite plugin TOHOST condition
[ https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919164#comment-13919164 ] Anil Kumar Myla commented on TS-2609: - It is indeed different from CLIENT-HEADER:Host Let's say we have this remap rule which preserves the Host header to the origin server map x.y.com origin.x.y.com @pristine_host_hdr=1 . header_rewrite plugin Then CLIENT-HEADER:Host = x.y.com TOHOST = origin.x.y.com Let me know if I'm wrong in my understanding Header rewrite plugin TOHOST condition -- Key: TS-2609 URL: https://issues.apache.org/jira/browse/TS-2609 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Anil Kumar Myla Assignee: Leif Hedstrom Priority: Minor Fix For: 5.0.0 Enhance header rewrite plugin to support TOHOST condition. Header rewrites conditioned on the final origin server will be supported. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2609) Header rewrite plugin TOHOST condition
[ https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919162#comment-13919162 ] Leif Hedstrom commented on TS-2609: --- [~bcall] pointed out that the TOHOST is already documented, but not implemented. I claim ignorance, but I suspect when we first wrote this, we intended to implement TOHOST, but then realized HEADER / CLIENT-HEADER would suffice ? Header rewrite plugin TOHOST condition -- Key: TS-2609 URL: https://issues.apache.org/jira/browse/TS-2609 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Anil Kumar Myla Assignee: Leif Hedstrom Priority: Minor Fix For: 5.0.0 Enhance header rewrite plugin to support TOHOST condition. Header rewrites conditioned on the final origin server will be supported. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2611) AddS3 Auth plugin
[ https://issues.apache.org/jira/browse/TS-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919166#comment-13919166 ] ASF subversion and git services commented on TS-2611: - Commit 6dfc1312399df84df8d83c97913e04bc901a5732 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6dfc131 ] TS-2611 Fix build bustage, thanks Jenkins for being my best friend AddS3 Auth plugin - Key: TS-2611 URL: https://issues.apache.org/jira/browse/TS-2611 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 This adds some basic v2 S3 Auth features, we can extend later with more features. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2608) API to introspect metric semantics
[
https://issues.apache.org/jira/browse/TS-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2608:
--
Fix Version/s: 5.0.0
API to introspect metric semantics
--
Key: TS-2608
URL: https://issues.apache.org/jira/browse/TS-2608
Project: Traffic Server
Issue Type: New Feature
Components: Management API, Stats
Reporter: James Peach
Labels: api-addition, api-change
Fix For: 5.0.0
We ought to have an API that apps can use to query the semantics of a metric.
For example, there's no way to know whether a metric is a counter or an
instantaneous value. {{traffic_top}} hard-codes a number of these, and I've
taken the same approach for my [epic|https://code.google.com/p/epicnms/]
plugin.
As an extension, it would also be helpful to know the units (e.g., bytes,
seconds, count).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2608) API to introspect metric semantics
[
https://issues.apache.org/jira/browse/TS-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2608:
--
Labels: api-addition api-change (was: )
API to introspect metric semantics
--
Key: TS-2608
URL: https://issues.apache.org/jira/browse/TS-2608
Project: Traffic Server
Issue Type: New Feature
Components: Management API, Stats
Reporter: James Peach
Labels: api-addition, api-change
Fix For: 5.0.0
We ought to have an API that apps can use to query the semantics of a metric.
For example, there's no way to know whether a metric is a counter or an
instantaneous value. {{traffic_top}} hard-codes a number of these, and I've
taken the same approach for my [epic|https://code.google.com/p/epicnms/]
plugin.
As an extension, it would also be helpful to know the units (e.g., bytes,
seconds, count).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2608) API to introspect metric semantics
[
https://issues.apache.org/jira/browse/TS-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919182#comment-13919182
]
Leif Hedstrom commented on TS-2608:
---
Isn't this really a fundamentally missing piece in librecords? It feels that
we ought to add something to RecordsConfig.cc, which then could get passed
along into various APIs etc.
One easy thing could be to update this:
enum RecAccessT
{
RECA_NULL,
RECA_NO_ACCESS,
RECA_READ_ONLY
};
Although the overlay of semantics there could be wonky. But, e.g.
enum RecAccessT
{
RECA_NULL,
RECA_NO_ACCESS,
RECA_READ_ONLY,
RECA_READ_ONLY_GAUGE,
};
Alternatively, we add another member to struct RecordElement, but that means
changing a lot of APIs such that the GAUGE vs not-Gauge info is passed in and
out properly.
API to introspect metric semantics
--
Key: TS-2608
URL: https://issues.apache.org/jira/browse/TS-2608
Project: Traffic Server
Issue Type: New Feature
Components: Management API, Stats
Reporter: James Peach
Labels: api-addition, api-change
Fix For: 5.0.0
We ought to have an API that apps can use to query the semantics of a metric.
For example, there's no way to know whether a metric is a counter or an
instantaneous value. {{traffic_top}} hard-codes a number of these, and I've
taken the same approach for my [epic|https://code.google.com/p/epicnms/]
plugin.
As an extension, it would also be helpful to know the units (e.g., bytes,
seconds, count).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2606) Clarify ssl_multicert.config parameters
[ https://issues.apache.org/jira/browse/TS-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919183#comment-13919183 ] Leif Hedstrom commented on TS-2606: --- Ask: We'll be stoked to get a diff on these docs updates! :-). Clarify ssl_multicert.config parameters --- Key: TS-2606 URL: https://issues.apache.org/jira/browse/TS-2606 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Ask Bjørn Hansen Fix For: Docs It'd be nice if the ssl_multicert.config documentation included a SNI-only example (no dest_ip=...). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2606) Clarify ssl_multicert.config parameters
[ https://issues.apache.org/jira/browse/TS-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2606: -- Fix Version/s: Docs Clarify ssl_multicert.config parameters --- Key: TS-2606 URL: https://issues.apache.org/jira/browse/TS-2606 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Ask Bjørn Hansen Fix For: Docs It'd be nice if the ssl_multicert.config documentation included a SNI-only example (no dest_ip=...). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2604) Collapsed connection plugin
[ https://issues.apache.org/jira/browse/TS-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2604: -- Assignee: Bryan Call Collapsed connection plugin --- Key: TS-2604 URL: https://issues.apache.org/jira/browse/TS-2604 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Ethan Lai Assignee: Bryan Call Fix For: 5.0.0 This plugin collapses connections with identical CacheUrl/EffectiveUrl. Please find more detail from README and state.png (State Diagram) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2604) Collapsed connection plugin
[ https://issues.apache.org/jira/browse/TS-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2604: -- Fix Version/s: 5.0.0 Collapsed connection plugin --- Key: TS-2604 URL: https://issues.apache.org/jira/browse/TS-2604 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Ethan Lai Fix For: 5.0.0 This plugin collapses connections with identical CacheUrl/EffectiveUrl. Please find more detail from README and state.png (State Diagram) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2598) Expose HttpDebugNames to public plugin APIs
[
https://issues.apache.org/jira/browse/TS-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2598:
--
Labels: api-addition (was: )
Expose HttpDebugNames to public plugin APIs
---
Key: TS-2598
URL: https://issues.apache.org/jira/browse/TS-2598
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Leif Hedstrom
Labels: api-addition
Fix For: 5.0.0
It'd be really useful to expose all the HttpDebugNames:: functions into one
(or several?) API calls.
Either
{code}
const char* TSGetDebugName(type, ID);
{code}
where type would be a new enum of e.g.
typedef enum
{
TS_DEBUG_STATE_NAME,
TS_DEBUG_METHOD_NAME,
TS_DEBUG_EVENT_NAME,
...
} TSDebugNameID;
or perhaps
{code}
const char* TSGetDebugStateName(id);
const char* TSGetDebugMethodName(id);
...
{code}
I personally favor the former, it's more easily extended with future
additions.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2598) Expose HttpDebugNames to public plugin APIs
[
https://issues.apache.org/jira/browse/TS-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2598:
--
Fix Version/s: 5.0.0
Expose HttpDebugNames to public plugin APIs
---
Key: TS-2598
URL: https://issues.apache.org/jira/browse/TS-2598
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Leif Hedstrom
Labels: api-addition
Fix For: 5.0.0
It'd be really useful to expose all the HttpDebugNames:: functions into one
(or several?) API calls.
Either
{code}
const char* TSGetDebugName(type, ID);
{code}
where type would be a new enum of e.g.
typedef enum
{
TS_DEBUG_STATE_NAME,
TS_DEBUG_METHOD_NAME,
TS_DEBUG_EVENT_NAME,
...
} TSDebugNameID;
or perhaps
{code}
const char* TSGetDebugStateName(id);
const char* TSGetDebugMethodName(id);
...
{code}
I personally favor the former, it's more easily extended with future
additions.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2598) Expose HttpDebugNames to public plugin APIs
[
https://issues.apache.org/jira/browse/TS-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2598:
-
Assignee: Leif Hedstrom
Expose HttpDebugNames to public plugin APIs
---
Key: TS-2598
URL: https://issues.apache.org/jira/browse/TS-2598
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Labels: api-addition
Fix For: 5.0.0
It'd be really useful to expose all the HttpDebugNames:: functions into one
(or several?) API calls.
Either
{code}
const char* TSGetDebugName(type, ID);
{code}
where type would be a new enum of e.g.
typedef enum
{
TS_DEBUG_STATE_NAME,
TS_DEBUG_METHOD_NAME,
TS_DEBUG_EVENT_NAME,
...
} TSDebugNameID;
or perhaps
{code}
const char* TSGetDebugStateName(id);
const char* TSGetDebugMethodName(id);
...
{code}
I personally favor the former, it's more easily extended with future
additions.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2565) ALPN: configure protocol selection
[ https://issues.apache.org/jira/browse/TS-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2565: -- Fix Version/s: sometime ALPN: configure protocol selection -- Key: TS-2565 URL: https://issues.apache.org/jira/browse/TS-2565 Project: Traffic Server Issue Type: New Feature Components: Configuration, SSL Reporter: James Peach Fix For: sometime Once there is a meaningful set of protocols that uses ALPN, we should have a way for operators to configure the ALP protocol selection. For example, some sites might want to prefer HTTP1 to HTTP2, some sites might want the reverse. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2603) Do not update hostdb if intercept exists
[ https://issues.apache.org/jira/browse/TS-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2603: -- Fix Version/s: 5.0.0 Do not update hostdb if intercept exists Key: TS-2603 URL: https://issues.apache.org/jira/browse/TS-2603 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 5.0.0 Reporter: portl4t Labels: Review Fix For: 5.0.0 Attachments: 0001-TS-2603-Do-not-update-hostdb-if-intercept-exists.patch We should not update hostdb if a HttpSM was intercepted, as the HttpSM did not really connect to the origin server. Otherwise we may set the hostdb address to zero if timeout occurs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2588) Parent proxy to self fails to loop detect
[ https://issues.apache.org/jira/browse/TS-2588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2588: -- Fix Version/s: sometime Parent proxy to self fails to loop detect --- Key: TS-2588 URL: https://issues.apache.org/jira/browse/TS-2588 Project: Traffic Server Issue Type: Improvement Components: Configuration, HTTP Reporter: Leif Hedstrom Fix For: sometime As a safety measure, I think it'd be a good idea to not proxy to self in a parent proxy setup. If such a loop is detected, it should instead go to origin directly (bypass parent). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2600) HTTPS statistics
[ https://issues.apache.org/jira/browse/TS-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919229#comment-13919229 ] Bryan Call edited comment on TS-2600 at 3/4/14 10:35 AM: - What is the issue with the HTTPS metrics? I didn't see the discussion on the IRC. was (Author: bcall): What is the issue with the HTTPS metrics. I didn't see the discussion on the IRC. HTTPS statistics Key: TS-2600 URL: https://issues.apache.org/jira/browse/TS-2600 Project: Traffic Server Issue Type: Improvement Components: SSL, Stats Reporter: David Carlin Assignee: Ron Barber Labels: Review Fix For: 5.2.0 It would be swell if there were some traffic_line SSL statistic variables. For instance, number of SSL connections and SSL bytes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2600) HTTPS statistics
[ https://issues.apache.org/jira/browse/TS-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919229#comment-13919229 ] Bryan Call commented on TS-2600: What is the issue with the HTTPS metrics. I didn't see the discussion on the IRC. HTTPS statistics Key: TS-2600 URL: https://issues.apache.org/jira/browse/TS-2600 Project: Traffic Server Issue Type: Improvement Components: SSL, Stats Reporter: David Carlin Assignee: Ron Barber Labels: Review Fix For: 5.2.0 It would be swell if there were some traffic_line SSL statistic variables. For instance, number of SSL connections and SSL bytes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[ https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13917889#comment-13917889 ] Bryan Call edited comment on TS-2344 at 3/4/14 10:37 AM: - [~yzlai] Is there are reason you are copying the url string out of the url object and having to deal with memory allocation yourself? Why do you delay setting the location header until the build_error_response()? Can you please describe the logic with the changes? Thank you... was (Author: bcall): Is there are reason you are copying the url string out of the url object and having to deal with memory allocation yourself? Why do you delay setting the location header until the build_error_response()? Can you please describe the logic with the changes? Thank you... 404 error was logged while url redirect request was processed corrctly -- Key: TS-2344 URL: https://issues.apache.org/jira/browse/TS-2344 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Eddie Assignee: Bryan Call Labels: Review Fix For: 5.2.0 I am seeing a lot of entries in the error log for my url redirect request. The request was processed correctly and I could see the expected response in log as below: 2013-11-08 18:23:37 IP 301 FIN http://yahoo.com http://www.yahoo.com/ But log messages like following were printed in the error log too, which generates a lot of error logs (log rotation configured) and filling up disk space pretty fast. 20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on Accelerator) for 'http:///' 20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect) for 'http:///' I watched my tcpdump log and did not see that the 404 error was sent out at all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in the error log for my url redirect request. The request was processed correctly I could see the expected response in log as well: 2013-11-08 18:23:37 IP 301 FIN http://yahoo.com http://www.yahoo.com/ But log messages like following were printed too: 20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on Accelerator) for 'http:///' 20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect) for 'http:///' I watched my tcpdump log and did not see that the 404 error was sent out at all. I am using ATS/3.2.4 and following is the log configuration. CONFIG proxy.config.log.logging_enabled INT 3 CONFIG proxy.config.log.max_secs_per_buffer INT 1 CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 CONFIG proxy.config.log.max_space_mb_headroom INT 1000 CONFIG proxy.config.log.hostname STRING localhost CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- CONFIG proxy.config.log.custom_logs_enabled INT 1 CONFIG proxy.config.log.squid_log_enabled INT 0 CONFIG proxy.config.log.squid_log_is_ascii INT 0 CONFIG proxy.config.log.squid_log_name STRING squid CONFIG proxy.config.log.squid_log_header STRING NULL CONFIG proxy.config.log.common_log_enabled INT 0 CONFIG proxy.config.log.common_log_is_ascii INT 1 CONFIG proxy.config.log.common_log_name STRING common CONFIG proxy.config.log.common_log_header STRING NULL CONFIG proxy.config.log.extended_log_enabled INT 0 CONFIG proxy.config.log.extended_log_is_ascii INT 0 CONFIG proxy.config.log.extended_log_name STRING extended CONFIG proxy.config.log.extended_log_header STRING NULL CONFIG proxy.config.log.extended2_log_enabled INT 0 CONFIG proxy.config.log.extended2_log_is_ascii INT 1 CONFIG proxy.config.log.extended2_log_name STRING extended2 CONFIG proxy.config.log.extended2_log_header STRING NULL CONFIG proxy.config.log.separate_icp_logs INT 0 CONFIG proxy.config.log.separate_host_logs INT 0 Is this a bug or is this a misconfiguration? Does anyone have any idea?) and following is the log configuration. CONFIG proxy.config.log.logging_enabled INT 3 CONFIG proxy.config.log.max_secs_per_buffer INT 1 CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 CONFIG proxy.config.log.max_space_mb_headroom INT 1000 CONFIG proxy.config.log.hostname STRING localhost CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- CONFIG proxy.config.log.custom_logs_enabled INT 1 CONFIG proxy.config.log.squid_log_enabled INT 0 CONFIG proxy.config.log.squid_log_is_ascii INT 0 CONFIG proxy.config.log.squid_log_name STRING squid CONFIG proxy.config.log.squid_log_header STRING NULL
[jira] [Commented] (TS-2609) Header rewrite plugin TOHOST condition
[
https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919230#comment-13919230
]
Leif Hedstrom commented on TS-2609:
---
Hmmm, I see what you are getting at. However, the patch does not do that I'm
pretty sure:
{code}
+ const char *to_host = TSUrlHostGet(res._rri-requestBufp,
res._rri-requestUrl, to_host_len);
{code}
In your case, with pristine host headers, the requestUrl's Host would still be
x.y.com. To do what you are saying, I believe you would have to change this
code to _rri-mapToUrl. Now, we also have the URL and CLIENT-URL directives,
that might overlap here ? E.g.
{code}
%{URL:Host}
{code}
However, looking at the code, it seems the URL conditions are not implemented
at all. We'll happy take patches here too! :-).
Also, as the patch is written, the TOHOST condition would only work as a remap
rule. That is fine, but would need to be properly documented. And if possible,
we should make conditions and operators generic. But, the more I look at this,
maybe the answer is to finish the URL / CLIENT-URL (and perhaps TO-URL and
FROM-URL ?) conditions ?
What do you think?
Header rewrite plugin TOHOST condition
--
Key: TS-2609
URL: https://issues.apache.org/jira/browse/TS-2609
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Anil Kumar Myla
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 5.0.0
Enhance header rewrite plugin to support TOHOST condition. Header rewrites
conditioned on the final origin server will be supported.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2612) Indroduce TSHttpConnectWithProtoType() API
Yunkai Zhang created TS-2612:
Summary: Indroduce TSHttpConnectWithProtoType() API
Key: TS-2612
URL: https://issues.apache.org/jira/browse/TS-2612
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Yunkai Zhang
This ticket was split from SPDY ticket(TS-2431).
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoType(struct sockaddr const* addr,
TSNetProtoType proto_type);
{code}
After introducing TSHttpConnectWithProtoType() API, TSHttpConnect() API would
be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoType(addr, TS_NET_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2610) Add client_req_proto_type, %cqpt field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2610:
-
Description:
This ticket was split from SPDY ticket(TS-2431).
Add %cqpt field into LogFormat, so that we can distinguish the protocol type
of each log record, it can help us to to do some analysis and statistic.
Here are the available values of %cqpt:
{code}
HTTP -- HTTP protocol
HTTP_SSL -- HTTP with SSL protocol
HTTP_SPDY -- HTTP with SPDY protocol
HTTP_SPDY_SSL -- HTTP with SPDY with SSL protocol
{code}
was:
This ticket was split from SPDY ticket(TS-2431).
Add %cqpt field into LogFormat, so that we can distinguish the protocol type
of each log record, it can help us to to do some analysis and statistic.
Here are the available values of %cqpt:
{code}
HTTP -- HTTP protocol
HTTP_SSL -- HTTP with SSL protocol
HTTP_SPDY -- HTTP with SPDY protocol
HTTP_SPDY_SSL -- HTTP with SPDY with SSL protocol
{code}
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoType(struct sockaddr const* addr,
TSNetProtoType proto_type);
{code}
After introducing TSHttpConnectWithProtoType() API, TSHttpConnect() API would
be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoType(addr, TS_NET_PROTO_HTTP);
}
{code}
Add client_req_proto_type, %cqpt field into LogFormat
-
Key: TS-2610
URL: https://issues.apache.org/jira/browse/TS-2610
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0001-TS-2610-Indroduce-TSHttpConnectWithProtoType-API.patch,
0002-TS-2610-Add-client_req_proto_type-cqpt-field-into-Lo.patch
This ticket was split from SPDY ticket(TS-2431).
Add %cqpt field into LogFormat, so that we can distinguish the protocol
type of each log record, it can help us to to do some analysis and statistic.
Here are the available values of %cqpt:
{code}
HTTP -- HTTP protocol
HTTP_SSL -- HTTP with SSL protocol
HTTP_SPDY -- HTTP with SPDY protocol
HTTP_SPDY_SSL -- HTTP with SPDY with SSL protocol
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Indroduce TSHttpConnectWithProtoType() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Attachment: 0001-TS-2612-Indroduce-TSHttpConnectWithProtoType-API.patch
Indroduce TSHttpConnectWithProtoType() API
--
Key: TS-2612
URL: https://issues.apache.org/jira/browse/TS-2612
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Yunkai Zhang
Attachments:
0001-TS-2612-Indroduce-TSHttpConnectWithProtoType-API.patch
This ticket was split from SPDY ticket(TS-2431).
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoType(struct sockaddr const* addr,
TSNetProtoType proto_type);
{code}
After introducing TSHttpConnectWithProtoType() API, TSHttpConnect() API would
be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoType(addr, TS_NET_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2610) Add client_req_proto_type, %cqpt field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2610:
-
Attachment: (was:
0001-TS-2610-Indroduce-TSHttpConnectWithProtoType-API.patch)
Add client_req_proto_type, %cqpt field into LogFormat
-
Key: TS-2610
URL: https://issues.apache.org/jira/browse/TS-2610
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0002-TS-2610-Add-client_req_proto_type-cqpt-field-into-Lo.patch
This ticket was split from SPDY ticket(TS-2431), and it relys on the patch of
TS-2612.
Add %cqpt field into LogFormat, so that we can distinguish the protocol
type of each log record, it can help us to to do some analysis and statistic.
Here are the available values of %cqpt:
{code}
HTTP -- HTTP protocol
HTTP_SSL -- HTTP with SSL protocol
HTTP_SPDY -- HTTP with SPDY protocol
HTTP_SPDY_SSL -- HTTP with SPDY with SSL protocol
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2613) Can't turn on attach server session to client from records.config
Bryan Call created TS-2613: -- Summary: Can't turn on attach server session to client from records.config Key: TS-2613 URL: https://issues.apache.org/jira/browse/TS-2613 Project: Traffic Server Issue Type: Bug Reporter: Bryan Call the proxy.config.http.attach_server_session_to_client value is not set in the http config -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2613) Can't turn on attach server session to client from records.config
[ https://issues.apache.org/jira/browse/TS-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-2613. Resolution: Fixed Assignee: Bryan Call Added code to set the value in http config from the config setting. Added a debug message to see that it is attaching the server setting to the client session (debug tag: http). Can't turn on attach server session to client from records.config - Key: TS-2613 URL: https://issues.apache.org/jira/browse/TS-2613 Project: Traffic Server Issue Type: Bug Reporter: Bryan Call Assignee: Bryan Call the proxy.config.http.attach_server_session_to_client value is not set in the http config -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2612) Indroduce TSHttpConnectWithProtoType() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2612:
--
Fix Version/s: 5.0.0
Indroduce TSHttpConnectWithProtoType() API
--
Key: TS-2612
URL: https://issues.apache.org/jira/browse/TS-2612
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Yunkai Zhang
Labels: api-addition, review
Fix For: 5.0.0
Attachments:
0001-TS-2612-Indroduce-TSHttpConnectWithProtoType-API.patch
This ticket was split from SPDY ticket(TS-2431).
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoType(struct sockaddr const* addr,
TSNetProtoType proto_type);
{code}
After introducing TSHttpConnectWithProtoType() API, TSHttpConnect() API would
be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoType(addr, TS_NET_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Indroduce TSHttpConnectWithProtoType() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2612:
--
Labels: api-addition review (was: review)
Indroduce TSHttpConnectWithProtoType() API
--
Key: TS-2612
URL: https://issues.apache.org/jira/browse/TS-2612
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Yunkai Zhang
Labels: api-addition, review
Fix For: 5.0.0
Attachments:
0001-TS-2612-Indroduce-TSHttpConnectWithProtoType-API.patch
This ticket was split from SPDY ticket(TS-2431).
For some plugins that using TSHttpConnect() API to do request, the Logging
module can't know which protocol type is used, so I add a new API:
{code}
tsapi TSVConn TSHttpConnectWithProtoType(struct sockaddr const* addr,
TSNetProtoType proto_type);
{code}
After introducing TSHttpConnectWithProtoType() API, TSHttpConnect() API would
be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoType(addr, TS_NET_PROTO_HTTP);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (TS-2605) delete unused code
[
https://issues.apache.org/jira/browse/TS-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2605:
-
Assignee: Leif Hedstrom
delete unused code
--
Key: TS-2605
URL: https://issues.apache.org/jira/browse/TS-2605
Project: Traffic Server
Issue Type: Improvement
Components: Core, TProxy
Reporter: sherlockhua
Assignee: Leif Hedstrom
Fix For: 5.0.0
Attachments: 0001-TS-2605-delete-unused-code-from-proxy-Main.cc.patch
I'm newer to the traffic server project, when I read the source code, I found
this code snippets have not used. in proxy/Main.cc, 1350 line. the code
sippnets is like follow:
1347 // This call is required for win_9xMe
1348 //without this this_ethread() is failing when
1349 //start_HttpProxyServer is called from main thread
1350 Thread *main_thread = NEW(new EThread);
1351 main_thread-set_specific();
but I found when eventProcessor.start(num_of_net_threads, stacksize) is
execute, in function start of eventProcessor will overwrite the thread
specific data which set above, here is the code snippets:
130 EventProcessor::start(int n_event_threads, size_t stacksize)
131 {
132 char thr_name[MAX_THREAD_NAME_LENGTH];
133 int i;
134
135 // do some sanity checking.
136 static int started = 0;
137 ink_release_assert(!started);
138 ink_release_assert(n_event_threads 0 n_event_threads =
MAX_EVENT_THREADS);
139 started = 1;
140
141 n_ethreads = n_event_threads;
142 n_thread_groups = 1;
143
144 int first_thread = 1;
145
146 for (i = 0; i n_event_threads; i++) {
147 EThread *t = NEW(new EThread(REGULAR, i));
148 if (first_thread !i) {
149 ink_thread_setspecific(Thread::thread_data_key, t); //overwrite
150 global_mutex = t-mutex;
151 t-cur_time = ink_get_based_hrtime_internal();
152 }
153 all_ethreads[i] = t;
154
155 eventthread[ET_CALL][i] = t;
156 t-set_event_type((EventType) ET_CALL);
157 }
so I think the main_thread should discarded, and make code more clear to
read, thank you.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-1521) Enable compression for binary log format
[ https://issues.apache.org/jira/browse/TS-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bettydramit updated TS-1521: Attachment: logcompress.patch compress ascii log Enable compression for binary log format Key: TS-1521 URL: https://issues.apache.org/jira/browse/TS-1521 Project: Traffic Server Issue Type: New Feature Components: Logging Environment: RHEL 6+ Reporter: Lans Carstensen Assignee: Yunkai Zhang Fix For: 6.0.0 Attachments: logcompress.patch As noted by in a discussion on #traffic-server, gzip can result in 90%+ compression on the binary access logs. By adding a reasonable streaming compression algorithm to the binary format you could significantly reduce logging-related IOPS. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1521) Enable compression for binary log format
[ https://issues.apache.org/jira/browse/TS-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919388#comment-13919388 ] Zhao Yongming commented on TS-1521: --- [~bettydreamit] submit thire gzipping patch for the ascii loging, please consider accept this feature too. Enable compression for binary log format Key: TS-1521 URL: https://issues.apache.org/jira/browse/TS-1521 Project: Traffic Server Issue Type: New Feature Components: Logging Environment: RHEL 6+ Reporter: Lans Carstensen Assignee: Yunkai Zhang Fix For: 6.0.0 Attachments: logcompress.patch As noted by in a discussion on #traffic-server, gzip can result in 90%+ compression on the binary access logs. By adding a reasonable streaming compression algorithm to the binary format you could significantly reduce logging-related IOPS. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[
https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919467#comment-13919467
]
Ethan Lai commented on TS-2344:
---
[~bcall]
1. Class URL(redirect_url) is not holding a NULL terminated string, just get
its reference might cause thereafter MIME_FIELD_LOCATION length,
strlen(s-remap_redirect), mis-counted.
2. s-hdr_info.client_response is not built till build_response() call, #8111,
inside build_error_response(). If set MIME_FIELD_LOCATION before calling
build_error_response(), it causes segfault.
3.
Current implementation will lookup with no mappings and build Not Found on
Accelerator(#915) error response first, then call handleIfRedirect(). This is
why there are 2 error logs which 404 first and 30x followed.
My patch will call handleIfRedirect() right after !s-url_remap_success. If
this is a redirect request, the Not Found case will not be reached. This
prevents producing 404 error log. Furthermore, since the error logs were
produced inside build_error_response(), I thought redirect responses were not
errors and error logs are not needed.
About the MIME_FIELD_LOCATION setting, this MIME field must be set before
calling body_factory-fabricate_with_old_api(), #8176. Or the %{Location}psh
field in response body will be empty. This is another reason I move setting
the location header into build_error_response().
Thanks,
-Ethan
404 error was logged while url redirect request was processed corrctly
--
Key: TS-2344
URL: https://issues.apache.org/jira/browse/TS-2344
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Eddie
Assignee: Bryan Call
Labels: Review
Fix For: 5.2.0
I am seeing a lot of entries in the error log for my url redirect request.
The request was processed correctly and I could see the expected response in
log as below:
2013-11-08 18:23:37 IP 301 FIN http://yahoo.com
http://www.yahoo.com/
But log messages like following were printed in the error log too, which
generates a lot of error logs (log rotation configured) and filling up disk
space pretty fast.
20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on
Accelerator) for 'http:///'
20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect)
for 'http:///'
I watched my tcpdump log and did not see that the 404 error was sent out at
all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in
the error log for my url redirect request. The request was processed correctly
I could see the expected response in log as well:
2013-11-08 18:23:37 IP 301 FIN http://yahoo.com
http://www.yahoo.com/
But log messages like following were printed too:
20131108.18h23m37s RESPONSE: sent IP status 404 (Not Found on
Accelerator) for 'http:///'
20131108.18h23m37s RESPONSE: sent IP status 301 (Redirect)
for 'http:///'
I watched my tcpdump log and did not see that the 404 error was sent out at
all. I am using ATS/3.2.4 and following
is the log configuration.
CONFIG proxy.config.log.logging_enabled INT 3
CONFIG proxy.config.log.max_secs_per_buffer INT 1
CONFIG proxy.config.log.max_space_mb_for_logs INT 25000
CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25
CONFIG proxy.config.log.max_space_mb_headroom INT 1000
CONFIG proxy.config.log.hostname STRING localhost
CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver
CONFIG proxy.config.log.logfile_perm STRING rw-r--r--
CONFIG proxy.config.log.custom_logs_enabled INT 1
CONFIG proxy.config.log.squid_log_enabled INT 0
CONFIG proxy.config.log.squid_log_is_ascii INT 0
CONFIG proxy.config.log.squid_log_name STRING squid
CONFIG proxy.config.log.squid_log_header STRING NULL
CONFIG proxy.config.log.common_log_enabled INT 0
CONFIG proxy.config.log.common_log_is_ascii INT 1
CONFIG proxy.config.log.common_log_name STRING common
CONFIG proxy.config.log.common_log_header STRING NULL
CONFIG proxy.config.log.extended_log_enabled INT 0
CONFIG proxy.config.log.extended_log_is_ascii INT 0
CONFIG proxy.config.log.extended_log_name STRING extended
CONFIG proxy.config.log.extended_log_header STRING NULL
CONFIG proxy.config.log.extended2_log_enabled INT 0
CONFIG proxy.config.log.extended2_log_is_ascii INT 1
CONFIG proxy.config.log.extended2_log_name STRING extended2
CONFIG proxy.config.log.extended2_log_header STRING NULL
CONFIG proxy.config.log.separate_icp_logs INT 0
CONFIG proxy.config.log.separate_host_logs INT 0
Is this a bug or is this a misconfiguration? Does anyone have any idea?) and
following is the log configuration.
CONFIG proxy.config.log.logging_enabled INT 3
CONFIG
[jira] [Commented] (TS-2169) SSL statistics
[
https://issues.apache.org/jira/browse/TS-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919509#comment-13919509
]
Ron Barber commented on TS-2169:
I assume you are referring to the loop below? This get executed by, what I
will call, a stats collector thread so I guess stats collection could get
delayed..if this turns out to be an issue we may want to add an option to
provide the ability to granularly disable portions of ssl stats collection.
+for (size_t i = 0; i ctxCount; i++) {
+ SSL_CTX * ctx = certLookup-get(i);
+
+ sessions += SSL_CTX_sess_accept_good(ctx);
+ hits += SSL_CTX_sess_hits(ctx);
+ misses += SSL_CTX_sess_misses(ctx);
+ timeouts += SSL_CTX_sess_timeouts(ctx);
+}
SSL statistics
--
Key: TS-2169
URL: https://issues.apache.org/jira/browse/TS-2169
Project: Traffic Server
Issue Type: Improvement
Components: SSL, Stats
Reporter: David Carlin
Assignee: James Peach
Labels: Review
Fix For: 5.2.0
It would be swell if there were some traffic_line SSL statistic variables.
For instance, number of SSL connections and SSL bytes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2600) HTTPS statistics
[ https://issues.apache.org/jira/browse/TS-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919526#comment-13919526 ] Ron Barber commented on TS-2600: James summarized the issue as follows: The discussion around the HTTPS stats needs to address whether HTTPS requests should increment both the HTTP and the HTTPS metric, and how the HTTPS-ness of a session is tracked. The latter is very similar to Yunkai Zhang's NetProtoType patches over in TS-2431. 1. In order to not impact existing stats, I think the current http metrics should stay the same (e.g. they count *every* http (and https) request). Based on that we would essentially double count https requests (once for http and again for https) 2. Yunkai Zhang's patch adds a NetProtoType as a data member for connections and my change also add a type, although not as granular as TS-2431. We should probably take TS-2431 first, then SSL stats can use the NetProtoType as necessary. HTTPS statistics Key: TS-2600 URL: https://issues.apache.org/jira/browse/TS-2600 Project: Traffic Server Issue Type: Improvement Components: SSL, Stats Reporter: David Carlin Assignee: Ron Barber Labels: Review Fix For: 5.2.0 It would be swell if there were some traffic_line SSL statistic variables. For instance, number of SSL connections and SSL bytes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1521) Enable compression for binary log format
[ https://issues.apache.org/jira/browse/TS-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919547#comment-13919547 ] Leif Hedstrom commented on TS-1521: --- Couple of thoughts: 1. This needs to be configurable, per log object. 2. Is this for ascii logs only? If so, why ? 3. There's a delete[] added in the patch, why is that ? Presumably there's another delete[] then that's superfluous ?? 4. The code uses tab's. Don't do that :). 5. Who is reggie ? Enable compression for binary log format Key: TS-1521 URL: https://issues.apache.org/jira/browse/TS-1521 Project: Traffic Server Issue Type: New Feature Components: Logging Environment: RHEL 6+ Reporter: Lans Carstensen Assignee: Yunkai Zhang Fix For: 6.0.0 Attachments: logcompress.patch As noted by in a discussion on #traffic-server, gzip can result in 90%+ compression on the binary access logs. By adding a reasonable streaming compression algorithm to the binary format you could significantly reduce logging-related IOPS. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2609) Header rewrite plugin TOHOST condition
[
https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919558#comment-13919558
]
Anil Kumar Myla commented on TS-2609:
-
When we have plugin chaining mapToUrl can be different from requestUrl. Let's
say we have a regex plugin before the header rewrite plugin, and the regex
plugin rewrites it to regex.x.y.com instead of the origin.x.y.com
map x.y.com origin.x.y.com regex plugin header rewrite plugin
_rri-mapToUrl = origin.x.y.com/request_url
_rri-requestUrl = regex.x.y.com/regex_modified_url
You are right, these would ideally be
%{URL:Host}
%{CLIENT-URL:Host}
But from the plugin documentation, I'm thinking the URL/CLIENT-URL conditions
have already been broken down into SCHEME (unimplemented), HOST, PORT
(unimplemented), PATH ,QUERY conditions. Do we really need the URL/CLIENT-URL
conditions ? :)
Let me know what you think.
Header rewrite plugin TOHOST condition
--
Key: TS-2609
URL: https://issues.apache.org/jira/browse/TS-2609
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Anil Kumar Myla
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 5.0.0
Enhance header rewrite plugin to support TOHOST condition. Header rewrites
conditioned on the final origin server will be supported.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2609) Header rewrite plugin TOHOST condition
[ https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919588#comment-13919588 ] Anil Kumar Myla commented on TS-2609: - To add to your comments, in a remap rule, URL:Host is pretty much equal to HEADER:Host (let me know if you think otherwise) while the CLIENT-URL:Host can be the origin server. But we need to justify implementing URL/CLIENT-URL conditions because of the following replacements that we can use (in the context of a remap rule) URL:Scheme == SCHEME (unimplemented) URL:Host == HEADER:Host (?correct?) URL:Port == PORT (unimplemented) URL:Path == PATH URL:Query== QUERY CLIENT-URL:Scheme == SCHEME (unimplemented) CLIENT-URL:Host == ? (unimplemented) -- TOHOST (patch) CLIENT-URL:Port == PORT (unimplemented) CLIENT-URL:Path == URL:Path == PATH CLIENT-URL:Query== URL:Query == QUERY We need to implement SCHEME or PORT (add CLIENT-SCHEME / CLIENT-PORT for remap rules) for this to be complete. Header rewrite plugin TOHOST condition -- Key: TS-2609 URL: https://issues.apache.org/jira/browse/TS-2609 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Anil Kumar Myla Assignee: Leif Hedstrom Priority: Minor Fix For: 5.0.0 Enhance header rewrite plugin to support TOHOST condition. Header rewrites conditioned on the final origin server will be supported. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2609) Header rewrite plugin TOHOST condition
[
https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919680#comment-13919680
]
Leif Hedstrom commented on TS-2609:
---
Right, significant portions of the URL / CLIENT-URL features are not
implemented.
Also, looking at the docs, it seems the intent was to implement these three:
{code}
header_rewrite.en.rst: cond %{HOST} operand
[condition_flags]
header_rewrite.en.rst: cond %{FROMHOST} operand [condition_flags]
header_rewrite.en.rst: cond %{TOHOST} operand
[condition_flags]
{code}
I'm pretty sure each of those would correlate (in remap plugins) to each of
these from the RRI struct:
{code}
TSMLoc requestUrl;
TSMLoc mapFromUrl;
TSMLoc mapToUrl;
{code}
So, your original patch, the condition would be named HOST I think? Also, I
feel that to be consistent, the three conditions ought to be be named
{code}
HOST
FROM-HOST
TO-HOST
{code}
That seems more in line with how we do this for e.g. HEADER / CLIENT-HEADER and
URL / CLIENT-URL.
Finally, the intent probably also was (just as with URL / CLIENT-URL) that we'd
have one class implementing HOST, and have it use a flag to indicate which
type of HOST it would use.
Wdyt ?
Oh, and thanks for all the input, this is a good discussion!
Header rewrite plugin TOHOST condition
--
Key: TS-2609
URL: https://issues.apache.org/jira/browse/TS-2609
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Anil Kumar Myla
Assignee: Leif Hedstrom
Priority: Minor
Fix For: 5.0.0
Enhance header rewrite plugin to support TOHOST condition. Header rewrites
conditioned on the final origin server will be supported.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2169) SSL statistics
[
https://issues.apache.org/jira/browse/TS-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919509#comment-13919509
]
Ron Barber edited comment on TS-2169 at 3/4/14 6:14 PM:
I assume you are referring to the loop below? This get executed by, what I
will call, a stats collector thread so I guess stats collection could get
delayed..if this turns out to be an issue we may want to add an option to
provide the ability to granularly disable portions of ssl stats collection.
{code}
+for (size_t i = 0; i ctxCount; i++) {
+ SSL_CTX * ctx = certLookup-get(i);
+
+ sessions += SSL_CTX_sess_accept_good(ctx);
+ hits += SSL_CTX_sess_hits(ctx);
+ misses += SSL_CTX_sess_misses(ctx);
+ timeouts += SSL_CTX_sess_timeouts(ctx);
+}
{code}
was (Author: rwbarber2):
I assume you are referring to the loop below? This get executed by, what I
will call, a stats collector thread so I guess stats collection could get
delayed..if this turns out to be an issue we may want to add an option to
provide the ability to granularly disable portions of ssl stats collection.
+for (size_t i = 0; i ctxCount; i++) {
+ SSL_CTX * ctx = certLookup-get(i);
+
+ sessions += SSL_CTX_sess_accept_good(ctx);
+ hits += SSL_CTX_sess_hits(ctx);
+ misses += SSL_CTX_sess_misses(ctx);
+ timeouts += SSL_CTX_sess_timeouts(ctx);
+}
SSL statistics
--
Key: TS-2169
URL: https://issues.apache.org/jira/browse/TS-2169
Project: Traffic Server
Issue Type: Improvement
Components: SSL, Stats
Reporter: David Carlin
Assignee: James Peach
Labels: Review
Fix For: 5.2.0
It would be swell if there were some traffic_line SSL statistic variables.
For instance, number of SSL connections and SSL bytes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2604) Collapsed connection plugin
[ https://issues.apache.org/jira/browse/TS-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13919734#comment-13919734 ] Leif Hedstrom commented on TS-2604: --- [~yzlai] Curious, how is this different than the existing read-while-writer feature? I'm not arguing against the value of this plugin, but would like to understand where they differ, and why? https://trafficserver.readthedocs.org/en/latest/admin/http-proxy-caching.en.html#reducing-origin-server-requests-avoiding-the-thundering-herd Collapsed connection plugin --- Key: TS-2604 URL: https://issues.apache.org/jira/browse/TS-2604 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Ethan Lai Assignee: Bryan Call Fix For: 5.0.0 This plugin collapses connections with identical CacheUrl/EffectiveUrl. Please find more detail from README and state.png (State Diagram) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2614) Response to invalid Content-Length for POST should be a 400 error
Ron Barber created TS-2614: -- Summary: Response to invalid Content-Length for POST should be a 400 error Key: TS-2614 URL: https://issues.apache.org/jira/browse/TS-2614 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Ron Barber We have some users attempting to POST where the content length is -1. POST /services/rest HTTP/1.1\r\n Host: api.flickr.com\r\n Accept: */*\r\n Content-Length: -1\r\n Content-Type: application/x-www-form-urlencoded\r\n Expect: 100-continue\r\n ATS goes ahead with this request and connects to the origin and passes the invalid content length. Preferable, and consistent with the spec, ATS should immediately respond to the client with an error. RFC-2616 Section 14.13 says 'Any Content-Length greater than or equal to zero is a valid value.' I interpret that as a negative content length value is invalid. I propose that ATS respond with a '400 Invalid Request' for PUT/POST/PUSH requests when the user provided content-length is less than 0. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2609) Header rewrite plugin TOHOST condition
[ https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920232#comment-13920232 ] Leif Hedstrom edited comment on TS-2609 at 3/4/14 11:49 PM: Sounds good. We should do something similar for URL too I think: TO-URL, FROM-URL and ORIGIN-URL. If we do that, do we still want the HOST shortcuts? I'm fine with that, since it makes it easier, but there would be some potential overlap. was (Author: zwoop): Sounds good. Header rewrite plugin TOHOST condition -- Key: TS-2609 URL: https://issues.apache.org/jira/browse/TS-2609 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Anil Kumar Myla Assignee: Leif Hedstrom Priority: Minor Fix For: 5.0.0 Enhance header rewrite plugin to support TOHOST condition. Header rewrites conditioned on the final origin server will be supported. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2609) Header rewrite plugin TOHOST condition
[ https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920284#comment-13920284 ] Anil Kumar Myla commented on TS-2609: - TO-URL FROM-URL and ORIGIN-URL are too generic in the sense, that they can be broken down into respective components like scheme, host, port, path, query as I explained before. Does it make sense to get rid of the URL condition since it is not implemented yet? Header rewrite plugin TOHOST condition -- Key: TS-2609 URL: https://issues.apache.org/jira/browse/TS-2609 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Anil Kumar Myla Assignee: Leif Hedstrom Priority: Minor Fix For: 5.0.0 Enhance header rewrite plugin to support TOHOST condition. Header rewrites conditioned on the final origin server will be supported. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2604) Collapsed connection plugin
[ https://issues.apache.org/jira/browse/TS-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920310#comment-13920310 ] Ethan Lai commented on TS-2604: --- [~zwoop] As the doc mentioned, ATS could not start serving other clients until it get the complete response header. Think about a request case with long response time, the read-while-writer feature would not collapse further requests with same cacheUrl before receiving the complete response header of 1st request. That means if origin server takes N secs before sending response header, other concurrent requests within the first N sec will also do connect to origin server. Collapsed connection plugin --- Key: TS-2604 URL: https://issues.apache.org/jira/browse/TS-2604 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Ethan Lai Assignee: Bryan Call Fix For: 5.0.0 This plugin collapses connections with identical CacheUrl/EffectiveUrl. Please find more detail from README and state.png (State Diagram) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2609) Header rewrite plugin ORIGIN-HOST condition
[ https://issues.apache.org/jira/browse/TS-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anil Kumar Myla updated TS-2609: Description: Enhance header rewrite plugin to support ORIGIN-HOST condition. Header rewrites conditioned on the final origin server will be supported. (was: Enhance header rewrite plugin to support TOHOST condition. Header rewrites conditioned on the final origin server will be supported.) Header rewrite plugin ORIGIN-HOST condition --- Key: TS-2609 URL: https://issues.apache.org/jira/browse/TS-2609 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Anil Kumar Myla Assignee: Leif Hedstrom Priority: Minor Fix For: 5.0.0 Enhance header rewrite plugin to support ORIGIN-HOST condition. Header rewrites conditioned on the final origin server will be supported. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2610) Add client_req_proto_type, %cqpt field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920481#comment-13920481
]
James Peach commented on TS-2610:
-
This is also related to TS-2600. [~rwbarber2]'s patch over there introduces a
similar mechanism to track statistics for requests made over HTTPS.
Add client_req_proto_type, %cqpt field into LogFormat
-
Key: TS-2610
URL: https://issues.apache.org/jira/browse/TS-2610
Project: Traffic Server
Issue Type: New Feature
Components: Logging
Reporter: Yunkai Zhang
Assignee: Yunkai Zhang
Fix For: 5.0.0
Attachments:
0002-TS-2610-Add-client_req_proto_type-cqpt-field-into-Lo.patch
This ticket was split from SPDY ticket(TS-2431), and it relys on the patch of
TS-2612.
Add %cqpt field into LogFormat, so that we can distinguish the protocol
type of each log record, it can help us to to do some analysis and statistic.
Here are the available values of %cqpt:
{code}
HTTP -- HTTP protocol
HTTP_SSL -- HTTP with SSL protocol
HTTP_SPDY -- HTTP with SPDY protocol
HTTP_SPDY_SSL -- HTTP with SPDY with SSL protocol
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2615) better logging for SSL client misconfiguration
James Peach created TS-2615: --- Summary: better logging for SSL client misconfiguration Key: TS-2615 URL: https://issues.apache.org/jira/browse/TS-2615 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach From TS-346, we should not crash when the SSL client is not configured correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2615) better logging for SSL client misconfiguration
[ https://issues.apache.org/jira/browse/TS-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920502#comment-13920502 ] ASF subversion and git services commented on TS-2615: - Commit 705a1d80002de0406e4da59892f36d05a11eb849 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=705a1d8 ] TS-2615: handle errors in creating a SSL client session better logging for SSL client misconfiguration -- Key: TS-2615 URL: https://issues.apache.org/jira/browse/TS-2615 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach Fix For: 5.0.0 From TS-346, we should not crash when the SSL client is not configured correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2615) better logging for SSL client misconfiguration
[ https://issues.apache.org/jira/browse/TS-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-2615. - Resolution: Fixed Fix Version/s: 5.0.0 Assignee: James Peach better logging for SSL client misconfiguration -- Key: TS-2615 URL: https://issues.apache.org/jira/browse/TS-2615 Project: Traffic Server Issue Type: Bug Components: SSL Reporter: James Peach Assignee: James Peach Fix For: 5.0.0 From TS-346, we should not crash when the SSL client is not configured correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2611) AddS3 Auth plugin
[ https://issues.apache.org/jira/browse/TS-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920549#comment-13920549 ] ASF subversion and git services commented on TS-2611: - Commit 15e2bbd2810b8cad9984c1a588ce14cdb025ce40 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=15e2bbd ] TS-2611 Fix getopt usage for OmniOS AddS3 Auth plugin - Key: TS-2611 URL: https://issues.apache.org/jira/browse/TS-2611 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 5.0.0 This adds some basic v2 S3 Auth features, we can extend later with more features. -- This message was sent by Atlassian JIRA (v6.2#6252)
