[jira] [Created] (TS-2630) Create ts/types.h used to place types shared between API and core
Yunkai Zhang created TS-2630: Summary: Create ts/types.h used to place types shared between API and core Key: TS-2630 URL: https://issues.apache.org/jira/browse/TS-2630 Project: Traffic Server Issue Type: Improvement Components: Core, TS API Reporter: Yunkai Zhang -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2626) Problem with Authorization: Negotiate header ( Forward Mode )
[ https://issues.apache.org/jira/browse/TS-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2626: -- Fix Version/s: (was: 5.0.0) > Problem with Authorization: Negotiate header ( Forward Mode ) > - > > Key: TS-2626 > URL: https://issues.apache.org/jira/browse/TS-2626 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Tommy Lee > Attachments: ATS-3.2.2-working.txt, ATS-5.0.0-broken.txt > > > We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some > websites that uses Authorization Header. > We always get 401 ( Unauthorized ) response. > I'm attaching two debug files. One with ATS-3.2.2 that's working and one with > ATS-5.0.0 that's broken. > Almost the same records.config for both tests. > I'm looking for changes in source code too. I'll update the issue if I find > an answer. > To devs: Could the question mark after the "exchange" can cause that ? This > is the only modification between these two versions. > ATS-3.2.2 GET - GET http://webmail.candidomendes.edu.br/exchange? > ATS-5.0.0 GET - GET http://webmail.candidomendes.edu.br/exchange > Thanks. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-1062) Introduce extended FetchSM API
[ https://issues.apache.org/jira/browse/TS-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-1062: - Fix Version/s: (was: sometime) 5.0.0 > Introduce extended FetchSM API > -- > > Key: TS-1062 > URL: https://issues.apache.org/jira/browse/TS-1062 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: James Peach >Assignee: Yunkai Zhang > Fix For: 5.0.0 > > Attachments: 0001-TS-1062-Extends-and-optimizes-FetchSM.patch, > 0002-TS-1062-Implement-dechunk-supporting-for-extended-Fe.patch, > 0003-TS-1062-Make-TSFetchUrl-handle-chunked-encoding-auto.patch > > > 1) Introduce extended FetchSM APIs, which will be used by SPDY. > 2) Make TSFetchUrl() dechunk encoding automatically: > If you use TSFetchUrl() to fetch a resource and the response comes back with > chunked encoding, you are basically hosed. The caller never gets the SUCCESS > event because FetchSM does not know how to decode the body. There's no > content-length header and the origin server doesn't drop the TCP connection, > so we just sit there waiting for the response to finish forever (well until > the origin server drops the connection 10s later). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1062) Introduce extended FetchSM API
[ https://issues.apache.org/jira/browse/TS-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931339#comment-13931339 ] ASF subversion and git services commented on TS-1062: - Commit 45f6553290a62aa9e77d42e32e7809b89c41ace2 in trafficserver's branch refs/heads/master from [~yunkai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=45f6553 ] TS-1062: Extends and optimizes FetchSM * Optimize FetchSM to support stream IO. * Reduce memory copy in FetchSM. * Expose some plugin APIs in 'ts/experimental.h'. This patch will borrow some ideas from @Quehan's fetcher library, which has not been open-sourced yet. Signed-off-by: Yunkai Zhang > Introduce extended FetchSM API > -- > > Key: TS-1062 > URL: https://issues.apache.org/jira/browse/TS-1062 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: James Peach >Assignee: Yunkai Zhang > Fix For: sometime > > Attachments: 0001-TS-1062-Extends-and-optimizes-FetchSM.patch, > 0002-TS-1062-Implement-dechunk-supporting-for-extended-Fe.patch, > 0003-TS-1062-Make-TSFetchUrl-handle-chunked-encoding-auto.patch > > > 1) Introduce extended FetchSM APIs, which will be used by SPDY. > 2) Make TSFetchUrl() dechunk encoding automatically: > If you use TSFetchUrl() to fetch a resource and the response comes back with > chunked encoding, you are basically hosed. The caller never gets the SUCCESS > event because FetchSM does not know how to decode the body. There's no > content-length header and the origin server doesn't drop the TCP connection, > so we just sit there waiting for the response to finish forever (well until > the origin server drops the connection 10s later). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2610) Add "client_protocol_stack", % field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931343#comment-13931343
]
ASF subversion and git services commented on TS-2610:
-
Commit f914a62fc3fc1f3d552b48dd7d6ca1283fb8c776 in trafficserver's branch
refs/heads/master from [~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f914a62 ]
TS-2610: Add "client_protocol_stack"(%) field into LogFormat
The output of % field would be the conjunction of protocol names
in client protocol stack spliced with '+', such as "TLS+SPDY".
Signed-off-by: Yunkai Zhang
> Add "client_protocol_stack", % 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
> Labels: review
> Fix For: 5.0.0
>
> Attachments:
> 0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it relys on the patch of
> TS-2612.
> Add "client_protocol_stack"(%) field into LogFormat.
> The *Client Protocol Stack* is usually composed by *transport protocol*(UDP,
> TCP, TLS, ...) and *application protocol*(HTTP, SPDY, RTMP, WebSocket, ...).
>
> The output of % field would be the conjunction of protocol names in
> client protocol stack spliced with '+', such as
> {code}
> "HTTP" // "TCP" is the defualt transport protocol, would be omitted
> by default.
> "TLS+SPDY"
> "TLS+HTTP"
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931342#comment-13931342
]
ASF subversion and git services commented on TS-2612:
-
Commit 2f8f43439c890811b1b9776e485d5a5d3349 in trafficserver's branch
refs/heads/master from [~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2f8 ]
TS-2612: Indroduce TSHttpConnectWithProtoStack() API
1) Firstly, add a bitmask, *proto_stack*, in NetVConnection/HttpSM,
and set it properly.
2) For some plugins that using TSHttpConnect() API to do request,
the Logging module can't know what protocol stack is used, so I
add a new API:
TSHttpConnectWithProtoStack(struct sockaddr const* addr,
TSClientProtoStack proto_stack);
After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
would be a special case of it:
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoStack(addr, (1u << TS_PROTO_HTTP));
}
Signed-off-by: Yunkai Zhang
> Introduce TSHttpConnectWithProtoStack() 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
>Assignee: Yunkai Zhang
> Labels: api-addition, review
> Fix For: 5.0.0
>
> Attachments:
> 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it based on extended
> FetchSM ticket(TS-1062);
> 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 and
> relatived tyeps:
> {code}
> /**
> TSClientProtoStack represents what protocols are used by
> the client. It may be composed by several TSProtoType.
> The value of TSProtoType indicates bit-offset that can
> be mapped to TSClientProtoStack by bit shifting.
> For example, TLS+SPDY can be mapped to protocol stack:
> proto_stack = (1u << TS_PROTO_TLS) | (1u << TS_PROTO_SPDY)
> For the sake of brevity, TS_PROTO_TCP is usually omitted in
> protocol stack.
>*/
> typedef enum {
> /* Transport protocols (0~11) */
> TS_PROTO_UDP = 0,
> TS_PROTO_TCP = 1,
> TS_PROTO_TLS = 2, /* TLS/SSL */
>
> /* Application protocols (12~31) */
> TS_PROTO_HTTP = 12,
> TS_PROTO_SPDY = 13,
> TS_PROTO_RTMP = 14,
> TS_PROTO_WBSK = 15, /* WebSocket */
> } TSProtoType;
> typedef uint32_t TSClientProtoStack;
> tsapi TSVConn TSHttpConnectWithProtoStack(struct sockaddr const* addr,
> TSClientProtoStack proto_stack);
> {code}
> After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
> would be a special case of it:
> {code}
> TSVConn
> TSHttpConnect(sockaddr const* addr)
> {
> return TSHttpConnectWithProtoStack(addr, (1u << TS_PROTO_HTTP));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-1062) Introduce extended FetchSM API
[ https://issues.apache.org/jira/browse/TS-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931341#comment-13931341 ] ASF subversion and git services commented on TS-1062: - Commit 6a5f55abd2088e02e615639b182b757fbdc0590e in trafficserver's branch refs/heads/master from [~yunkai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6a5f55a ] TS-1062: Make TSFetchUrl handle chunked encoding automatically Signed-off-by: Yunkai Zhang > Introduce extended FetchSM API > -- > > Key: TS-1062 > URL: https://issues.apache.org/jira/browse/TS-1062 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: James Peach >Assignee: Yunkai Zhang > Fix For: sometime > > Attachments: 0001-TS-1062-Extends-and-optimizes-FetchSM.patch, > 0002-TS-1062-Implement-dechunk-supporting-for-extended-Fe.patch, > 0003-TS-1062-Make-TSFetchUrl-handle-chunked-encoding-auto.patch > > > 1) Introduce extended FetchSM APIs, which will be used by SPDY. > 2) Make TSFetchUrl() dechunk encoding automatically: > If you use TSFetchUrl() to fetch a resource and the response comes back with > chunked encoding, you are basically hosed. The caller never gets the SUCCESS > event because FetchSM does not know how to decode the body. There's no > content-length header and the origin server doesn't drop the TCP connection, > so we just sit there waiting for the response to finish forever (well until > the origin server drops the connection 10s later). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1062) Introduce extended FetchSM API
[ https://issues.apache.org/jira/browse/TS-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931340#comment-13931340 ] ASF subversion and git services commented on TS-1062: - Commit 8a0bee4e2b4e897c8e9b089bdbc40338bdd2 in trafficserver's branch refs/heads/master from [~yunkai] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8a0bee4 ] TS-1062: Implement dechunk supporting for extended FetchSM With this patch, we can let FetchSM to dechunk body content automatically by passing 'TS_FETCH_FLAGS_DECHUNK' option to TSFetchCreate(); Signed-off-by: Yunkai Zhang > Introduce extended FetchSM API > -- > > Key: TS-1062 > URL: https://issues.apache.org/jira/browse/TS-1062 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: James Peach >Assignee: Yunkai Zhang > Fix For: sometime > > Attachments: 0001-TS-1062-Extends-and-optimizes-FetchSM.patch, > 0002-TS-1062-Implement-dechunk-supporting-for-extended-Fe.patch, > 0003-TS-1062-Make-TSFetchUrl-handle-chunked-encoding-auto.patch > > > 1) Introduce extended FetchSM APIs, which will be used by SPDY. > 2) Make TSFetchUrl() dechunk encoding automatically: > If you use TSFetchUrl() to fetch a resource and the response comes back with > chunked encoding, you are basically hosed. The caller never gets the SUCCESS > event because FetchSM does not know how to decode the body. There's no > content-length header and the origin server doesn't drop the TCP connection, > so we just sit there waiting for the response to finish forever (well until > the origin server drops the connection 10s later). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2610) Add "client_protocol_stack", % field into LogFormat
[
https://issues.apache.org/jira/browse/TS-2610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931326#comment-13931326
]
Yunkai Zhang commented on TS-2610:
--
Let's land it, so that I can move forward to SPDY patches.
> Add "client_protocol_stack", % 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
> Labels: review
> Fix For: 5.0.0
>
> Attachments:
> 0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it relys on the patch of
> TS-2612.
> Add "client_protocol_stack"(%) field into LogFormat.
> The *Client Protocol Stack* is usually composed by *transport protocol*(UDP,
> TCP, TLS, ...) and *application protocol*(HTTP, SPDY, RTMP, WebSocket, ...).
>
> The output of % field would be the conjunction of protocol names in
> client protocol stack spliced with '+', such as
> {code}
> "HTTP" // "TCP" is the defualt transport protocol, would be omitted
> by default.
> "TLS+SPDY"
> "TLS+HTTP"
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931325#comment-13931325
]
Yunkai Zhang commented on TS-2612:
--
Let's land it, so that I can move forward to SPDY patches.
> Introduce TSHttpConnectWithProtoStack() 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
>Assignee: Yunkai Zhang
> Labels: api-addition, review
> Fix For: 5.0.0
>
> Attachments:
> 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it based on extended
> FetchSM ticket(TS-1062);
> 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 and
> relatived tyeps:
> {code}
> /**
> TSClientProtoStack represents what protocols are used by
> the client. It may be composed by several TSProtoType.
> The value of TSProtoType indicates bit-offset that can
> be mapped to TSClientProtoStack by bit shifting.
> For example, TLS+SPDY can be mapped to protocol stack:
> proto_stack = (1u << TS_PROTO_TLS) | (1u << TS_PROTO_SPDY)
> For the sake of brevity, TS_PROTO_TCP is usually omitted in
> protocol stack.
>*/
> typedef enum {
> /* Transport protocols (0~11) */
> TS_PROTO_UDP = 0,
> TS_PROTO_TCP = 1,
> TS_PROTO_TLS = 2, /* TLS/SSL */
>
> /* Application protocols (12~31) */
> TS_PROTO_HTTP = 12,
> TS_PROTO_SPDY = 13,
> TS_PROTO_RTMP = 14,
> TS_PROTO_WBSK = 15, /* WebSocket */
> } TSProtoType;
> typedef uint32_t TSClientProtoStack;
> tsapi TSVConn TSHttpConnectWithProtoStack(struct sockaddr const* addr,
> TSClientProtoStack proto_stack);
> {code}
> After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
> would be a special case of it:
> {code}
> TSVConn
> TSHttpConnect(sockaddr const* addr)
> {
> return TSHttpConnectWithProtoStack(addr, (1u << TS_PROTO_HTTP));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-1062) Introduce extended FetchSM API
[ https://issues.apache.org/jira/browse/TS-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931324#comment-13931324 ] Yunkai Zhang commented on TS-1062: -- Let's land it, so that I can move forward to SPDY patches. > Introduce extended FetchSM API > -- > > Key: TS-1062 > URL: https://issues.apache.org/jira/browse/TS-1062 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: James Peach >Assignee: Yunkai Zhang > Fix For: sometime > > Attachments: 0001-TS-1062-Extends-and-optimizes-FetchSM.patch, > 0002-TS-1062-Implement-dechunk-supporting-for-extended-Fe.patch, > 0003-TS-1062-Make-TSFetchUrl-handle-chunked-encoding-auto.patch > > > 1) Introduce extended FetchSM APIs, which will be used by SPDY. > 2) Make TSFetchUrl() dechunk encoding automatically: > If you use TSFetchUrl() to fetch a resource and the response comes back with > chunked encoding, you are basically hosed. The caller never gets the SUCCESS > event because FetchSM does not know how to decode the body. There's no > content-length header and the origin server doesn't drop the TCP connection, > so we just sit there waiting for the response to finish forever (well until > the origin server drops the connection 10s later). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2623) CacheURL Rules Limit
[ https://issues.apache.org/jira/browse/TS-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931264#comment-13931264 ] ASF subversion and git services commented on TS-2623: - Commit 558345f212bedcc467f7934da530b544e6a60c0a in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=558345f ] TS-2623 Also fix the indentation to follow our coding standards. > CacheURL Rules Limit > - > > Key: TS-2623 > URL: https://issues.apache.org/jira/browse/TS-2623 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Plugins >Reporter: Faysal Banna >Assignee: James Peach > Fix For: 5.0.0 > > > Hi Guys. > While working with cacheurl plugin is good yet its far too limited for only > 32 Rules only. > this is not good for such a good software. maybe its a configuration field > but who knows ? > may someone try to fix it ? > tested on ATS 5.0.0 > much regards > Faysal Banna -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2623) CacheURL Rules Limit
[ https://issues.apache.org/jira/browse/TS-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-2623. - Resolution: Fixed Fix Version/s: 5.0.0 Assignee: James Peach > CacheURL Rules Limit > - > > Key: TS-2623 > URL: https://issues.apache.org/jira/browse/TS-2623 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Plugins >Reporter: Faysal Banna >Assignee: James Peach > Fix For: 5.0.0 > > > Hi Guys. > While working with cacheurl plugin is good yet its far too limited for only > 32 Rules only. > this is not good for such a good software. maybe its a configuration field > but who knows ? > may someone try to fix it ? > tested on ATS 5.0.0 > much regards > Faysal Banna -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2626) Problem with Authorization: Negotiate header ( Forward Mode )
[ https://issues.apache.org/jira/browse/TS-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-2626. - Resolution: Not A Problem OK, I'm marking this as resolved for now. If you find anything to implicate Traffic Server, please re-open. thanks > Problem with Authorization: Negotiate header ( Forward Mode ) > - > > Key: TS-2626 > URL: https://issues.apache.org/jira/browse/TS-2626 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Tommy Lee > Fix For: 5.0.0 > > Attachments: ATS-3.2.2-working.txt, ATS-5.0.0-broken.txt > > > We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some > websites that uses Authorization Header. > We always get 401 ( Unauthorized ) response. > I'm attaching two debug files. One with ATS-3.2.2 that's working and one with > ATS-5.0.0 that's broken. > Almost the same records.config for both tests. > I'm looking for changes in source code too. I'll update the issue if I find > an answer. > To devs: Could the question mark after the "exchange" can cause that ? This > is the only modification between these two versions. > ATS-3.2.2 GET - GET http://webmail.candidomendes.edu.br/exchange? > ATS-5.0.0 GET - GET http://webmail.candidomendes.edu.br/exchange > Thanks. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2623) CacheURL Rules Limit
[ https://issues.apache.org/jira/browse/TS-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931135#comment-13931135 ] ASF subversion and git services commented on TS-2623: - Commit 44a826fe01b64a0dd81e1e77cfab957a7085922c in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=44a826f ] TS-2623: unsigned comparison build fix > CacheURL Rules Limit > - > > Key: TS-2623 > URL: https://issues.apache.org/jira/browse/TS-2623 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Plugins >Reporter: Faysal Banna > > Hi Guys. > While working with cacheurl plugin is good yet its far too limited for only > 32 Rules only. > this is not good for such a good software. maybe its a configuration field > but who knows ? > may someone try to fix it ? > tested on ATS 5.0.0 > much regards > Faysal Banna -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2623) CacheURL Rules Limit
[ https://issues.apache.org/jira/browse/TS-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931112#comment-13931112 ] ASF subversion and git services commented on TS-2623: - Commit f8619248d37b8da5f363dd75300d5fc672379ae2 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f861924 ] TS-2623: remove the limit on the number of cachurl regular expressions - compile the cacheurl plugin as C++ so we can ust standard containers. - remove regex limit from cacheurl plugin - load the cacheurl config file relative to config directory > CacheURL Rules Limit > - > > Key: TS-2623 > URL: https://issues.apache.org/jira/browse/TS-2623 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Plugins >Reporter: Faysal Banna > > Hi Guys. > While working with cacheurl plugin is good yet its far too limited for only > 32 Rules only. > this is not good for such a good software. maybe its a configuration field > but who knows ? > may someone try to fix it ? > tested on ATS 5.0.0 > much regards > Faysal Banna -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2626) Problem with Authorization: Negotiate header ( Forward Mode )
[ https://issues.apache.org/jira/browse/TS-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13931106#comment-13931106 ] Tommy Lee commented on TS-2626: --- James, Probably this is the reason. I'll investigate why is it happening, because the configuration in records.config is really simple and is almost the same between two versions. If anyone has a clue about the ticket, please let us know. > Problem with Authorization: Negotiate header ( Forward Mode ) > - > > Key: TS-2626 > URL: https://issues.apache.org/jira/browse/TS-2626 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Tommy Lee > Fix For: 5.0.0 > > Attachments: ATS-3.2.2-working.txt, ATS-5.0.0-broken.txt > > > We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some > websites that uses Authorization Header. > We always get 401 ( Unauthorized ) response. > I'm attaching two debug files. One with ATS-3.2.2 that's working and one with > ATS-5.0.0 that's broken. > Almost the same records.config for both tests. > I'm looking for changes in source code too. I'll update the issue if I find > an answer. > To devs: Could the question mark after the "exchange" can cause that ? This > is the only modification between these two versions. > ATS-3.2.2 GET - GET http://webmail.candidomendes.edu.br/exchange? > ATS-5.0.0 GET - GET http://webmail.candidomendes.edu.br/exchange > Thanks. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2629) Orphan log size (proxy.config.log.max_space_mb_for_orphan_logs) not honored
Leif Hedstrom created TS-2629:
-
Summary: Orphan log size
(proxy.config.log.max_space_mb_for_orphan_logs) not honored
Key: TS-2629
URL: https://issues.apache.org/jira/browse/TS-2629
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
It seems even with the default configuration:
{code}
CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25
{code}
ATS can create much larger orphaned logs, e.g.
{code}
$ du -h log/trafficserver/ogre.log_syslog.ogre.com-6789.orphan
442Mlog/trafficserver/ogre.log_syslog.ogre.com-6789.orphan
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (TS-2628) traffic_line should tell you when a reload is needed
[
https://issues.apache.org/jira/browse/TS-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reopened TS-2628:
---
I'm reopening this, but I'm ok with a new bug too. But I think we should not
show this message, since it's not true:
{code}
root@loki 270/0 # ./bin/traffic_line -s proxy.config.url_remap.remap_required
-v 0
Set proxy.config.url_remap.remap_required, reconfiguration required
{code}
> traffic_line should tell you when a reload is needed
>
>
> Key: TS-2628
> URL: https://issues.apache.org/jira/browse/TS-2628
> Project: Traffic Server
> Issue Type: Improvement
> Components: Management
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> The management API that {{traffic_line}} uses to make configuration changes
> reports back whether a configuration reload or a restart is needed. We should
> print this to the console so that operators know what action to take next.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2079) Replace ink_cluster_time() with just "localtime"
[ https://issues.apache.org/jira/browse/TS-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-2079. --- Resolution: Duplicate Fix Version/s: (was: 5.0.0) > Replace ink_cluster_time() with just "localtime" > > > Key: TS-2079 > URL: https://issues.apache.org/jira/browse/TS-2079 > Project: Traffic Server > Issue Type: Improvement > Components: Clustering, Core >Reporter: Leif Hedstrom > > I think this shared "adjustment" of a time concept across a cluster is > generally pointless these days. What it does it to take a negative approach, > and use the largest skew as an offset on each box. This is to e.g. allow for > cluster cache object to live at a duration based on the fastest clock. > It's possible this was a useful feature in the past, but honestly, with NTP > being ubiquitous, I think we should just assume that the clocks are within > reasonable skew inside the cluster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2626) Problem with Authorization: Negotiate header ( Forward Mode )
[ https://issues.apache.org/jira/browse/TS-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2626: -- Fix Version/s: 5.0.0 > Problem with Authorization: Negotiate header ( Forward Mode ) > - > > Key: TS-2626 > URL: https://issues.apache.org/jira/browse/TS-2626 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Tommy Lee > Fix For: 5.0.0 > > Attachments: ATS-3.2.2-working.txt, ATS-5.0.0-broken.txt > > > We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some > websites that uses Authorization Header. > We always get 401 ( Unauthorized ) response. > I'm attaching two debug files. One with ATS-3.2.2 that's working and one with > ATS-5.0.0 that's broken. > Almost the same records.config for both tests. > I'm looking for changes in source code too. I'll update the issue if I find > an answer. > To devs: Could the question mark after the "exchange" can cause that ? This > is the only modification between these two versions. > ATS-3.2.2 GET - GET http://webmail.candidomendes.edu.br/exchange? > ATS-5.0.0 GET - GET http://webmail.candidomendes.edu.br/exchange > Thanks. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2626) Problem with Authorization: Negotiate header ( Forward Mode )
[
https://issues.apache.org/jira/browse/TS-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13930885#comment-13930885
]
James Peach commented on TS-2626:
-
In the ATS 5.0 case, the client request does not contain a {{Referrer}} header.
In that case, it looks like the origin replies with a 401 rather than a 302.
> Problem with Authorization: Negotiate header ( Forward Mode )
> -
>
> Key: TS-2626
> URL: https://issues.apache.org/jira/browse/TS-2626
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Tommy Lee
> Attachments: ATS-3.2.2-working.txt, ATS-5.0.0-broken.txt
>
>
> We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some
> websites that uses Authorization Header.
> We always get 401 ( Unauthorized ) response.
> I'm attaching two debug files. One with ATS-3.2.2 that's working and one with
> ATS-5.0.0 that's broken.
> Almost the same records.config for both tests.
> I'm looking for changes in source code too. I'll update the issue if I find
> an answer.
> To devs: Could the question mark after the "exchange" can cause that ? This
> is the only modification between these two versions.
> ATS-3.2.2 GET - GET http://webmail.candidomendes.edu.br/exchange?
> ATS-5.0.0 GET - GET http://webmail.candidomendes.edu.br/exchange
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2628) traffic_line should tell you when a reload is needed
[
https://issues.apache.org/jira/browse/TS-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13930858#comment-13930858
]
ASF subversion and git services commented on TS-2628:
-
Commit 07720dc20cb00de31b3e3f0e8fbe6209809253a0 in trafficserver's branch
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=07720dc ]
TS-2628: traffic_line: print restart status after setting a value
The API that sets configuration values reports whether Traffic
Server needs to be restarted or reconfigured. Print this information
to the user so that it is clearer what the next step should be.
> traffic_line should tell you when a reload is needed
>
>
> Key: TS-2628
> URL: https://issues.apache.org/jira/browse/TS-2628
> Project: Traffic Server
> Issue Type: Improvement
> Components: Management
>Reporter: James Peach
> Fix For: 5.0.0
>
>
> The management API that {{traffic_line}} uses to make configuration changes
> reports back whether a configuration reload or a restart is needed. We should
> print this to the console so that operators know what action to take next.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2628) traffic_line should tell you when a reload is needed
[
https://issues.apache.org/jira/browse/TS-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach resolved TS-2628.
-
Resolution: Fixed
Fix Version/s: 5.0.0
Assignee: James Peach
> traffic_line should tell you when a reload is needed
>
>
> Key: TS-2628
> URL: https://issues.apache.org/jira/browse/TS-2628
> Project: Traffic Server
> Issue Type: Improvement
> Components: Management
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> The management API that {{traffic_line}} uses to make configuration changes
> reports back whether a configuration reload or a restart is needed. We should
> print this to the console so that operators know what action to take next.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2628) traffic_line should tell you when a reload is needed
James Peach created TS-2628:
---
Summary: traffic_line should tell you when a reload is needed
Key: TS-2628
URL: https://issues.apache.org/jira/browse/TS-2628
Project: Traffic Server
Issue Type: Improvement
Components: Management
Reporter: James Peach
The management API that {{traffic_line}} uses to make configuration changes
reports back whether a configuration reload or a restart is needed. We should
print this to the console so that operators know what action to take next.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2627) reduce management socket code duplication
[ https://issues.apache.org/jira/browse/TS-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-2627. - Resolution: Fixed Fix Version/s: 5.0.0 Assignee: James Peach > reduce management socket code duplication > - > > Key: TS-2627 > URL: https://issues.apache.org/jira/browse/TS-2627 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Management API >Reporter: James Peach >Assignee: James Peach > Fix For: 5.0.0 > > > The management socket code manages to copy+paste code to read bytes from a > socket half a dozen times. Let's make a function. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2627) reduce management socket code duplication
[ https://issues.apache.org/jira/browse/TS-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13930845#comment-13930845 ] ASF subversion and git services commented on TS-2627: - Commit 93fb1bbfd6e693c47db148b43197895e6e0bcf32 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=93fb1bb ] TS-2627: mgmt condense duplicated socket read code Rather than copy the code to read a fixed amount from a socket, make a helper function and call it. > reduce management socket code duplication > - > > Key: TS-2627 > URL: https://issues.apache.org/jira/browse/TS-2627 > Project: Traffic Server > Issue Type: Improvement > Components: Core, Management API >Reporter: James Peach > Fix For: 5.0.0 > > > The management socket code manages to copy+paste code to read bytes from a > socket half a dozen times. Let's make a function. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2627) reduce management socket code duplication
James Peach created TS-2627: --- Summary: reduce management socket code duplication Key: TS-2627 URL: https://issues.apache.org/jira/browse/TS-2627 Project: Traffic Server Issue Type: Improvement Components: Core, Management API Reporter: James Peach The management socket code manages to copy+paste code to read bytes from a socket half a dozen times. Let's make a function. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2626) Problem with Authorization: Negotiate header ( Forward Mode )
[ https://issues.apache.org/jira/browse/TS-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommy Lee updated TS-2626: -- Description: We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some websites that uses Authorization Header. We always get 401 ( Unauthorized ) response. I'm attaching two debug files. One with ATS-3.2.2 that's working and one with ATS-5.0.0 that's broken. Almost the same records.config for both tests. I'm looking for changes in source code too. I'll update the issue if I find an answer. To devs: Could the question mark after the "exchange" can cause that ? This is the only modification between these two versions. ATS-3.2.2 GET - GET http://webmail.candidomendes.edu.br/exchange? ATS-5.0.0 GET - GET http://webmail.candidomendes.edu.br/exchange Thanks. was: We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some websites that uses Authorization Header. We always get 401 ( Unauthorized ) response. I'm attaching two debug files. One with ATS-3.2.2 that's working and one with ATS-5.0.0 that's broken. Almost the same records.config for both tests. I'm looking for changes in source code too. I'll update the issue if I find an answer. Thanks. > Problem with Authorization: Negotiate header ( Forward Mode ) > - > > Key: TS-2626 > URL: https://issues.apache.org/jira/browse/TS-2626 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Tommy Lee > Attachments: ATS-3.2.2-working.txt, ATS-5.0.0-broken.txt > > > We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some > websites that uses Authorization Header. > We always get 401 ( Unauthorized ) response. > I'm attaching two debug files. One with ATS-3.2.2 that's working and one with > ATS-5.0.0 that's broken. > Almost the same records.config for both tests. > I'm looking for changes in source code too. I'll update the issue if I find > an answer. > To devs: Could the question mark after the "exchange" can cause that ? This > is the only modification between these two versions. > ATS-3.2.2 GET - GET http://webmail.candidomendes.edu.br/exchange? > ATS-5.0.0 GET - GET http://webmail.candidomendes.edu.br/exchange > Thanks. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2626) Problem with Authorization: Negotiate header ( Forward Mode )
[ https://issues.apache.org/jira/browse/TS-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommy Lee updated TS-2626: -- Description: We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some websites that uses Authorization Header. We always get 401 ( Unauthorized ) response. I'm attaching two debug files. One with ATS-3.2.2 that's working and one with ATS-5.0.0 that's broken. Almost the same records.config for both tests. I'm looking for changes in source code too. I'll update the issue if I find an answer. Thanks. was: We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some websites that uses Authorization Header. Always get 401 ( Unauthorized ) response. I'm attaching two debug files. One with ATS-3.2.2 that's working and one with ATS-5.0.0 that's broken. Almost the same records.config for both tests. > Problem with Authorization: Negotiate header ( Forward Mode ) > - > > Key: TS-2626 > URL: https://issues.apache.org/jira/browse/TS-2626 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Tommy Lee > Attachments: ATS-3.2.2-working.txt, ATS-5.0.0-broken.txt > > > We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some > websites that uses Authorization Header. > We always get 401 ( Unauthorized ) response. > I'm attaching two debug files. One with ATS-3.2.2 that's working and one with > ATS-5.0.0 that's broken. > Almost the same records.config for both tests. > I'm looking for changes in source code too. I'll update the issue if I find > an answer. > Thanks. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2626) Problem with Authorization: Negotiate header ( Forward Mode )
[ https://issues.apache.org/jira/browse/TS-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommy Lee updated TS-2626: -- Attachment: ATS-5.0.0-broken.txt ATS-3.2.2-working.txt > Problem with Authorization: Negotiate header ( Forward Mode ) > - > > Key: TS-2626 > URL: https://issues.apache.org/jira/browse/TS-2626 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Tommy Lee > Attachments: ATS-3.2.2-working.txt, ATS-5.0.0-broken.txt > > > We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some > websites that uses Authorization Header. > Always get 401 ( Unauthorized ) response. > I'm attaching two debug files. One with ATS-3.2.2 that's working and one with > ATS-5.0.0 that's broken. > Almost the same records.config for both tests. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2626) Problem with Authorization: Negotiate header ( Forward Mode )
[ https://issues.apache.org/jira/browse/TS-2626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommy Lee updated TS-2626: -- Description: We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some websites that uses Authorization Header. Always get 401 ( Unauthorized ) response. I'm attaching two debug files. One with ATS-3.2.2 that's working and one with ATS-5.0.0 that's broken. Almost the same records.config for both tests. was: We are noted that ATS-5.0.0 from GIT master. Couldn't authenticate with some websites that uses Authorization Header. Always get 401 ( Unauthorized ) response. I'm attaching two debug files. One with ATS-3.2.2 that's working and one with ATS-5.0.0 that's broken. Almost the same records.config for both tests. > Problem with Authorization: Negotiate header ( Forward Mode ) > - > > Key: TS-2626 > URL: https://issues.apache.org/jira/browse/TS-2626 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Tommy Lee > > We are noted that ATS-5.0.0 from GIT master couldn't authenticate with some > websites that uses Authorization Header. > Always get 401 ( Unauthorized ) response. > I'm attaching two debug files. One with ATS-3.2.2 that's working and one with > ATS-5.0.0 that's broken. > Almost the same records.config for both tests. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2626) Problem with Authorization: Negotiate header ( Forward Mode )
Tommy Lee created TS-2626: - Summary: Problem with Authorization: Negotiate header ( Forward Mode ) Key: TS-2626 URL: https://issues.apache.org/jira/browse/TS-2626 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Tommy Lee We are noted that ATS-5.0.0 from GIT master. Couldn't authenticate with some websites that uses Authorization Header. Always get 401 ( Unauthorized ) response. I'm attaching two debug files. One with ATS-3.2.2 that's working and one with ATS-5.0.0 that's broken. Almost the same records.config for both tests. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2610) Add "client_protocol_stack", % 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:
0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch)
> Add "client_protocol_stack", % 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
> Labels: review
> Fix For: 5.0.0
>
> Attachments:
> 0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it relys on the patch of
> TS-2612.
> Add "client_protocol_stack"(%) field into LogFormat.
> The *Client Protocol Stack* is usually composed by *transport protocol*(UDP,
> TCP, TLS, ...) and *application protocol*(HTTP, SPDY, RTMP, WebSocket, ...).
>
> The output of % field would be the conjunction of protocol names in
> client protocol stack spliced with '+', such as
> {code}
> "HTTP" // "TCP" is the defualt transport protocol, would be omitted
> by default.
> "TLS+SPDY"
> "TLS+HTTP"
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Description:
This ticket was split from SPDY ticket(TS-2431), and it based on extended
FetchSM ticket(TS-1062);
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 and relatived
tyeps:
{code}
/**
TSClientProtoStack represents what protocols are used by
the client. It may be composed by several TSProtoType.
The value of TSProtoType indicates bit-offset that can
be mapped to TSClientProtoStack by bit shifting.
For example, TLS+SPDY can be mapped to protocol stack:
proto_stack = (1u << TS_PROTO_TLS) | (1u << TS_PROTO_SPDY)
For the sake of brevity, TS_PROTO_TCP is usually omitted in
protocol stack.
*/
typedef enum {
/* Transport protocols (0~11) */
TS_PROTO_UDP = 0,
TS_PROTO_TCP = 1,
TS_PROTO_TLS = 2, /* TLS/SSL */
/* Application protocols (12~31) */
TS_PROTO_HTTP = 12,
TS_PROTO_SPDY = 13,
TS_PROTO_RTMP = 14,
TS_PROTO_WBSK = 15, /* WebSocket */
} TSProtoType;
typedef uint32_t TSClientProtoStack;
tsapi TSVConn TSHttpConnectWithProtoStack(struct sockaddr const* addr,
TSClientProtoStack proto_stack);
{code}
After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API would
be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoStack(addr, (1u << TS_PROTO_HTTP));
}
{code}
was:
This ticket was split from SPDY ticket(TS-2431), and it based on extended
FetchSM ticket(TS-1062);
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 TSHttpConnectWithProtoStack(struct sockaddr const* addr,
TSClientProtoStack proto_stack);
{code}
After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API would
be a special case of it:
{code}
TSVConn
TSHttpConnect(sockaddr const* addr)
{
return TSHttpConnectWithProtoStack(addr, TS_PROTO_HTTP);
}
{code}
> Introduce TSHttpConnectWithProtoStack() 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
>Assignee: Yunkai Zhang
> Labels: api-addition, review
> Fix For: 5.0.0
>
> Attachments:
> 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it based on extended
> FetchSM ticket(TS-1062);
> 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 and
> relatived tyeps:
> {code}
> /**
> TSClientProtoStack represents what protocols are used by
> the client. It may be composed by several TSProtoType.
> The value of TSProtoType indicates bit-offset that can
> be mapped to TSClientProtoStack by bit shifting.
> For example, TLS+SPDY can be mapped to protocol stack:
> proto_stack = (1u << TS_PROTO_TLS) | (1u << TS_PROTO_SPDY)
> For the sake of brevity, TS_PROTO_TCP is usually omitted in
> protocol stack.
>*/
> typedef enum {
> /* Transport protocols (0~11) */
> TS_PROTO_UDP = 0,
> TS_PROTO_TCP = 1,
> TS_PROTO_TLS = 2, /* TLS/SSL */
>
> /* Application protocols (12~31) */
> TS_PROTO_HTTP = 12,
> TS_PROTO_SPDY = 13,
> TS_PROTO_RTMP = 14,
> TS_PROTO_WBSK = 15, /* WebSocket */
> } TSProtoType;
> typedef uint32_t TSClientProtoStack;
> tsapi TSVConn TSHttpConnectWithProtoStack(struct sockaddr const* addr,
> TSClientProtoStack proto_stack);
> {code}
> After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
> would be a special case of it:
> {code}
> TSVConn
> TSHttpConnect(sockaddr const* addr)
> {
> return TSHttpConnectWithProtoStack(addr, (1u << TS_PROTO_HTTP));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2610) Add "client_protocol_stack", % 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: 0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch
> Add "client_protocol_stack", % 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
> Labels: review
> Fix For: 5.0.0
>
> Attachments:
> 0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it relys on the patch of
> TS-2612.
> Add "client_protocol_stack"(%) field into LogFormat.
> The *Client Protocol Stack* is usually composed by *transport protocol*(UDP,
> TCP, TLS, ...) and *application protocol*(HTTP, SPDY, RTMP, WebSocket, ...).
>
> The output of % field would be the conjunction of protocol names in
> client protocol stack spliced with '+', such as
> {code}
> "HTTP" // "TCP" is the defualt transport protocol, would be omitted
> by default.
> "TLS+SPDY"
> "TLS+HTTP"
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Attachment: 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
> Introduce TSHttpConnectWithProtoStack() 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
>Assignee: Yunkai Zhang
> Labels: api-addition, review
> Fix For: 5.0.0
>
> Attachments:
> 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it based on extended
> FetchSM ticket(TS-1062);
> 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 TSHttpConnectWithProtoStack(struct sockaddr const* addr,
> TSClientProtoStack proto_stack);
> {code}
> After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
> would be a special case of it:
> {code}
> TSVConn
> TSHttpConnect(sockaddr const* addr)
> {
> return TSHttpConnectWithProtoStack(addr, TS_PROTO_HTTP);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Attachment: (was:
0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch)
> Introduce TSHttpConnectWithProtoStack() 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
>Assignee: Yunkai Zhang
> Labels: api-addition, review
> Fix For: 5.0.0
>
> Attachments:
> 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it based on extended
> FetchSM ticket(TS-1062);
> 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 TSHttpConnectWithProtoStack(struct sockaddr const* addr,
> TSClientProtoStack proto_stack);
> {code}
> After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
> would be a special case of it:
> {code}
> TSVConn
> TSHttpConnect(sockaddr const* addr)
> {
> return TSHttpConnectWithProtoStack(addr, TS_PROTO_HTTP);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Attachment: 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
> Introduce TSHttpConnectWithProtoStack() 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
>Assignee: Yunkai Zhang
> Labels: api-addition, review
> Fix For: 5.0.0
>
> Attachments:
> 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it based on extended
> FetchSM ticket(TS-1062);
> 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 TSHttpConnectWithProtoStack(struct sockaddr const* addr,
> TSClientProtoStack proto_stack);
> {code}
> After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
> would be a special case of it:
> {code}
> TSVConn
> TSHttpConnect(sockaddr const* addr)
> {
> return TSHttpConnectWithProtoStack(addr, TS_PROTO_HTTP);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Attachment: (was:
0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch)
> Introduce TSHttpConnectWithProtoStack() 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
>Assignee: Yunkai Zhang
> Labels: api-addition, review
> Fix For: 5.0.0
>
> Attachments:
> 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it based on extended
> FetchSM ticket(TS-1062);
> 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 TSHttpConnectWithProtoStack(struct sockaddr const* addr,
> TSClientProtoStack proto_stack);
> {code}
> After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
> would be a special case of it:
> {code}
> TSVConn
> TSHttpConnect(sockaddr const* addr)
> {
> return TSHttpConnectWithProtoStack(addr, TS_PROTO_HTTP);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2610) Add "client_protocol_stack", % 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: 0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch
> Add "client_protocol_stack", % 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
> Labels: review
> Fix For: 5.0.0
>
> Attachments:
> 0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it relys on the patch of
> TS-2612.
> Add "client_protocol_stack"(%) field into LogFormat.
> The *Client Protocol Stack* is usually composed by *transport protocol*(UDP,
> TCP, TLS, ...) and *application protocol*(HTTP, SPDY, RTMP, WebSocket, ...).
>
> The output of % field would be the conjunction of protocol names in
> client protocol stack spliced with '+', such as
> {code}
> "HTTP" // "TCP" is the defualt transport protocol, would be omitted
> by default.
> "TLS+SPDY"
> "TLS+HTTP"
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Attachment: 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
> Introduce TSHttpConnectWithProtoStack() 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
>Assignee: Yunkai Zhang
> Labels: api-addition, review
> Fix For: 5.0.0
>
> Attachments:
> 0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch
>
>
> This ticket was split from SPDY ticket(TS-2431), and it based on extended
> FetchSM ticket(TS-1062);
> 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 TSHttpConnectWithProtoStack(struct sockaddr const* addr,
> TSClientProtoStack proto_stack);
> {code}
> After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
> would be a special case of it:
> {code}
> TSVConn
> TSHttpConnect(sockaddr const* addr)
> {
> return TSHttpConnectWithProtoStack(addr, TS_PROTO_HTTP);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2612) Introduce TSHttpConnectWithProtoStack() API
[
https://issues.apache.org/jira/browse/TS-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2612:
-
Attachment: (was:
0004-TS-2612-Indroduce-TSHttpConnectWithProtoStack-API.patch)
> Introduce TSHttpConnectWithProtoStack() 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
>Assignee: Yunkai Zhang
> Labels: api-addition, review
> Fix For: 5.0.0
>
>
> This ticket was split from SPDY ticket(TS-2431), and it based on extended
> FetchSM ticket(TS-1062);
> 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 TSHttpConnectWithProtoStack(struct sockaddr const* addr,
> TSClientProtoStack proto_stack);
> {code}
> After introducing TSHttpConnectWithProtoStack() API, TSHttpConnect() API
> would be a special case of it:
> {code}
> TSVConn
> TSHttpConnect(sockaddr const* addr)
> {
> return TSHttpConnectWithProtoStack(addr, TS_PROTO_HTTP);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2610) Add "client_protocol_stack", % 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:
0005-TS-2610-Add-client_protocol_stack-cps-field-into-Log.patch)
> Add "client_protocol_stack", % 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
> Labels: review
> Fix For: 5.0.0
>
>
> This ticket was split from SPDY ticket(TS-2431), and it relys on the patch of
> TS-2612.
> Add "client_protocol_stack"(%) field into LogFormat.
> The *Client Protocol Stack* is usually composed by *transport protocol*(UDP,
> TCP, TLS, ...) and *application protocol*(HTTP, SPDY, RTMP, WebSocket, ...).
>
> The output of % field would be the conjunction of protocol names in
> client protocol stack spliced with '+', such as
> {code}
> "HTTP" // "TCP" is the defualt transport protocol, would be omitted
> by default.
> "TLS+SPDY"
> "TLS+HTTP"
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
