[jira] [Commented] (TS-3415) H2 sending FIN stream too early
[
https://issues.apache.org/jira/browse/TS-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14346168#comment-14346168
]
Ryo Okubo commented on TS-3415:
---
I agree. Any data frame must not be sent after FIN. I'll add the protection.
> H2 sending FIN stream too early
> ---
>
> Key: TS-3415
> URL: https://issues.apache.org/jira/browse/TS-3415
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Sudheer Vinukonda
> Attachments: ts-3415-02.diff, ts-3415-3414.diff, ts-3415.diff
>
>
> With H2 running on the docs/jenkins server, some of us have noticed empty
> pages on chrome/FF when hitting those servers. Looking at the H2 traces, it
> seems that ATS is sending FIN streams (both SPDY_SESSION_RECV_HEADERS and
> SPDY_SESSION_RECV_DATA with fin flag set to true) before sending the data
> frames. This makes the browser display blank pages.
> Example:
> {code}
> t=31890437 [st=140]SPDY_SESSION_RECV_DATA
>--> fin = true
>--> size = 0
>--> stream_id = 1
> t=31890437 [st=140]SPDY_SESSION_RECV_DATA
>--> fin = false
>--> size = 2591
>--> stream_id = 1
> {code}
> Detailed traces below:
> {code}
> 1112054: SPDY_SESSION
> ci.trafficserver.apache.org:443 (DIRECT)
> Start Time: 2015-02-26 13:30:14.060
> t=31890297 [st= 0] +SPDY_SESSION [dt=?]
> --> host = "ci.trafficserver.apache.org:443"
> --> proxy = "DIRECT"
> t=31890297 [st= 0]SPDY_SESSION_INITIALIZED
>--> protocol = "h2-14"
>--> source_dependency = 1112049 (SOCKET)
> t=31890297 [st= 0]SPDY_SESSION_SEND_SETTINGS
>--> settings = ["[id:3 flags:0 value:1000]","[id:4
> flags:0 value:10485760]"]
> t=31890297 [st= 0]SPDY_STREAM_UPDATE_RECV_WINDOW
>--> delta = 10420224
>--> window_size = 10485760
> t=31890297 [st= 0]SPDY_SESSION_SENT_WINDOW_UPDATE_FRAME
>--> delta = 10420224
>--> stream_id = 0
> t=31890297 [st= 0]SPDY_SESSION_SYN_STREAM
>--> fin = true
>--> :authority: ci.trafficserver.apache.org
>:method: GET
>:path: /job/tsqa-master/180/consoleFull
>:scheme: https
>accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
>accept-encoding: gzip, deflate, sdch
>accept-language: en-US,en;q=0.8
>cache-control: max-age=0
>cookie: [71 bytes were stripped]
>user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X
> 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115
> Safari/537.36
>--> spdy_priority = 0
>--> stream_id = 1
>--> unidirectional = false
> t=31890335 [st= 38]SPDY_SESSION_RECV_SETTINGS
>--> clear_persisted = false
>--> host = "ci.trafficserver.apache.org:443"
> t=31890335 [st= 38]SPDY_SESSION_RECV_SETTING
>--> flags = 0
>--> id = 1
>--> value = 4096
> t=31890335 [st= 38]SPDY_SESSION_RECV_SETTING
>--> flags = 0
>--> id = 2
>--> value = 0
> t=31890335 [st= 38]SPDY_SESSION_RECV_SETTING
>--> flags = 0
>--> id = 3
>--> value = 100
> t=31890436 [st=139]SPDY_SESSION_RECV_HEADERS
>--> fin = true
>--> :status: 200
>age: 1
>cache-control: no-cache,no-store,must-revalidate
>content-encoding: gzip
>content-type: text/html;charset=UTF-8
>date: Thu, 26 Feb 2015 21:30:14 GMT
>expires: Thu, 01 Jan 1970 00:00:00 GMT
>server: ATS/5.3.0
>set-cookie: [67 bytes were stripped]
>strict-transport-security: max-age=86400
>via: http/1.1 ATS (ApacheTrafficServer/5.3.0
> [cMsSf ])
>x-frame-options: sameorigin
>x-hudson: 1.395
>x-hudson-cli-port: 40666
>x-hudson-theme: default
>
[jira] [Commented] (TS-3197) dest_ip in cache.config should be expand to network style
[ https://issues.apache.org/jira/browse/TS-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345768#comment-14345768 ] Leif Hedstrom commented on TS-3197: --- [~amc] Is it reasonable to leave this as an "Improvement" Jira? Is anyone going to work on this? > dest_ip in cache.config should be expand to network style > - > > Key: TS-3197 > URL: https://issues.apache.org/jira/browse/TS-3197 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Configuration, Performance >Reporter: Luca Rea >Priority: Minor > Fix For: sometime > > > Hi, > I'm tring to exclude a /22 netblock from the cache system but the syntax > "dest_ip" doesn't work, detalis below: > dest_ip="x.y.84.0-x.y.87.255" action=never-cache > I've tried to "stop,clear-cache,start" several times but every time images > have been put into the cache and log shows "NONE FIN FIN TCP_MEM_HIT" or > "NONE FIN FIN TCP_IMS_HIT". > Other Info: > proxy.node.version.manager.long=Apache Traffic Server - traffic_manager - > 5.1.0 - (build # 81013 on Sep 10 2014 at 13:13:42) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3311) Possible lookups on NULL hostnames in HostDB
[ https://issues.apache.org/jira/browse/TS-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345654#comment-14345654 ] Leif Hedstrom commented on TS-3311: --- The patch looks fine. I haven't tried to reproduce the bug with it, but my observations on this triggering is as follow: 1) The recursive resolve needs to resolve "localhost". 2) parent.config has to exist. I'm not 100% certain, but I don't think it has to be enabled (we parse parent.config regardless if it's enabled or not). 3) It'll only trigger once the entry for "localhost" is in the HostDB cache, and the TTL expires. I.e. on revalidation of the entry. 4) It seems to primarily happen on the traffic_cop health checks (i.e. proxying http://127.0.0.1:8083/synthetic.txt). > Possible lookups on NULL hostnames in HostDB > > > Key: TS-3311 > URL: https://issues.apache.org/jira/browse/TS-3311 > Project: Traffic Server > Issue Type: Bug > Components: HostDB >Reporter: Steve Malenfant >Assignee: Alan M. Carroll > Fix For: 5.3.0 > > > Getting multiple segfaults per day on 4.2.1. > [4324544.324222] [ET_NET 23][10504]: segfault at 0 ip 2acd66546168 sp > 2acd71f190b8 error 4 in libtsutil.so.4.2.1[2acd66521000+34000] > [4410696.820857] [ET_NET 19][22738]: segfault at 0 ip 2af09f339168 sp > 2af0aa9230b8 error 4 in libtsutil.so.4.2.1[2af09f314000+34000] > [4497039.474253] [ET_NET 12][34872]: segfault at 0 ip 2ad17e6a1168 sp > 2ad1896100b8 error 4 in libtsutil.so.4.2.1[2ad17e67c000+34000] > [4583372.073916] [ET_NET 3][46994]: segfault at 0 ip 2aced4227168 sp > 2aceda7d80b8 error 4 in libtsutil.so.4.2.1[2aced4202000+34000] > [4756046.944373] [ET_NET 22][10799]: segfault at 0 ip 2b1771f76168 sp > 2b177d9130b8 error 4 in libtsutil.so.4.2.1[2b1771f51000+34000] > Stack Trace : > (gdb) bt > #0 ink_inet_addr (s=) at ink_inet.cc:107 > #1 0x005e0df5 in is_dotted_form_hostname (mutex=0x1d32cb0, md5=..., > ignore_timeout=false) at P_HostDBProcessor.h:545 > #2 probe (mutex=0x1d32cb0, md5=..., ignore_timeout=false) at HostDB.cc:668 > #3 0x005e2b34 in HostDBProcessor::getby (this=, > cont=0x2b514cc749d0, hostname=0x0, len=, > ip=0x2b50e8f092b0, aforce_dns=false, host_res_style=HOST_RES_NONE, > dns_lookup_timeout=0) > at HostDB.cc:772 > #4 0x00517f2c in getbyaddr_re (this=0x2b514cc749d0) at > ../../iocore/hostdb/I_HostDBProcessor.h:417 > #5 HttpSM::do_hostdb_reverse_lookup (this=0x2b514cc749d0) at HttpSM.cc:3968 > #6 0x0052f028 in HttpSM::set_next_state (this=0x2b514cc749d0) at > HttpSM.cc:6932 > #7 0x00518242 in HttpSM::do_hostdb_lookup (this=0x2b514cc749d0) at > HttpSM.cc:3950 > #8 0x0052f44a in HttpSM::set_next_state (this=0x2b514cc749d0) at > HttpSM.cc:6925 > #9 0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at > HttpSM.cc:1559 > #10 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at > HttpSM.cc:6825 > #11 0x0052ea8a in HttpSM::set_next_state (this=0x2b514cc749d0) at > HttpSM.cc:7224 > #12 0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at > HttpSM.cc:1559 > #13 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at > HttpSM.cc:6825 > #14 0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at > HttpSM.cc:1559 > #15 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at > HttpSM.cc:6825 > #16 0x0052fef6 in HttpSM::state_read_client_request_header > (this=0x2b514cc749d0, event=100, data=) at HttpSM.cc:821 > #17 0x0052a5b8 in HttpSM::main_handler (this=0x2b514cc749d0, > event=100, data=0x2b514802ca08) at HttpSM.cc:2539 > #18 0x0068793b in handleEvent (event=, > vc=0x2b514802c900) at ../../iocore/eventsystem/I_Continuation.h:146 > #19 read_signal_and_update (event=, vc=0x2b514802c900) > at UnixNetVConnection.cc:138 > #20 0x00689ec4 in read_from_net (nh=0x2b50e2e17c10, > vc=0x2b514802c900, thread=) at UnixNetVConnection.cc:320 > #21 0x0067fb12 in NetHandler::mainNetEvent (this=0x2b50e2e17c10, > event=, e=) at UnixNet.cc:384 > #22 0x006ac8cf in handleEvent (this=0x2b50e2e14010, e=0x1a9ef30, > calling_code=5) at I_Continuation.h:146 > #23 EThread::process_event (this=0x2b50e2e14010, e=0x1a9ef30, calling_code=5) > at UnixEThread.cc:145 > #24 0x006ad273 in EThread::execute (this=0x2b50e2e14010) at > UnixEThread.cc:269 > #25 0x006abc2a in spawn_thread_internal (a=0x198f820) at Thread.cc:88 > #26 0x2b50e026b9d1 in start_thread () from /lib64/libpthread.so.0 > #27 0x00381b2e8b6d in clone () from /lib64/libc.so.6 > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3414) New API for Outgoing Address
[ https://issues.apache.org/jira/browse/TS-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345606#comment-14345606 ] Kit Chan commented on TS-3414: -- I saw you updated the lua plugin as well to add this feature. Thanks. Can you please update the lua plugin doc as well? https://github.com/apache/trafficserver/blob/master/doc/reference/plugins/ts_lua.en.rst Thanks. > New API for Outgoing Address > - > > Key: TS-3414 > URL: https://issues.apache.org/jira/browse/TS-3414 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Affects Versions: 5.3.0 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 5.3.0 > > > There's currently no TS API to retrieve the source address used by the proxy > in the outbound connections. > I would like to add a new TS API that can provide this info - In addition to > making it consistent with the API for inbound addresses (where we have TS API > for both remote and local addresses), there may be other use cases that need > this info (e.g. applying rate limiting on the inbound side based on the > ephemeral ports). > tsapi struct sockaddr const* TSHttpTxnOutgoingAddrGet(TSHttpTxn txnp); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3421) Add a -t range feature for authproxy plugin
[ https://issues.apache.org/jira/browse/TS-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345505#comment-14345505 ] ASF subversion and git services commented on TS-3421: - Commit 9f7cdf8d13dcf90842a74af1db24b53ca1d2cfc1 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9f7cdf8 ] TS-3421 Updated docs > Add a -t range feature for authproxy plugin > --- > > Key: TS-3421 > URL: https://issues.apache.org/jira/browse/TS-3421 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.3.0 > > > Similar to the -t head option, this would send a request asking for no body. > The difference is that we use the GET request, which can allow more proxies > to actually fetch and serve the authproxy request from cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3414) New API for Outgoing Address
[ https://issues.apache.org/jira/browse/TS-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda resolved TS-3414. --- Resolution: Fixed > New API for Outgoing Address > - > > Key: TS-3414 > URL: https://issues.apache.org/jira/browse/TS-3414 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Affects Versions: 5.3.0 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 5.3.0 > > > There's currently no TS API to retrieve the source address used by the proxy > in the outbound connections. > I would like to add a new TS API that can provide this info - In addition to > making it consistent with the API for inbound addresses (where we have TS API > for both remote and local addresses), there may be other use cases that need > this info (e.g. applying rate limiting on the inbound side based on the > ephemeral ports). > tsapi struct sockaddr const* TSHttpTxnOutgoingAddrGet(TSHttpTxn txnp); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3414) New API for Outgoing Address
[ https://issues.apache.org/jira/browse/TS-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345339#comment-14345339 ] ASF subversion and git services commented on TS-3414: - Commit cd60e20bd4b554930a4d6eef77762154f5b1aed8 in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=cd60e20 ] [TS-3414]: Update docs for TSHttpTxnOutgoingAddrGet and TSHttpTxnIncomingAddrGet > New API for Outgoing Address > - > > Key: TS-3414 > URL: https://issues.apache.org/jira/browse/TS-3414 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Affects Versions: 5.3.0 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 5.3.0 > > > There's currently no TS API to retrieve the source address used by the proxy > in the outbound connections. > I would like to add a new TS API that can provide this info - In addition to > making it consistent with the API for inbound addresses (where we have TS API > for both remote and local addresses), there may be other use cases that need > this info (e.g. applying rate limiting on the inbound side based on the > ephemeral ports). > tsapi struct sockaddr const* TSHttpTxnOutgoingAddrGet(TSHttpTxn txnp); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3414) New API for Outgoing Address
[ https://issues.apache.org/jira/browse/TS-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3414: -- Affects Version/s: 5.3.0 Fix Version/s: 5.3.0 Assignee: Sudheer Vinukonda > New API for Outgoing Address > - > > Key: TS-3414 > URL: https://issues.apache.org/jira/browse/TS-3414 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Affects Versions: 5.3.0 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 5.3.0 > > > There's currently no TS API to retrieve the source address used by the proxy > in the outbound connections. > I would like to add a new TS API that can provide this info - In addition to > making it consistent with the API for inbound addresses (where we have TS API > for both remote and local addresses), there may be other use cases that need > this info (e.g. applying rate limiting on the inbound side based on the > ephemeral ports). > tsapi struct sockaddr const* TSHttpTxnOutgoingAddrGet(TSHttpTxn txnp); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3414) New API for Outgoing Address
[ https://issues.apache.org/jira/browse/TS-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345322#comment-14345322 ] ASF subversion and git services commented on TS-3414: - Commit efae3a4f914a7dda7b3f586a0c09c93435b90efb in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=efae3a4 ] [TS-3414]: Add new TS API TSHttpTxnOutgoingAddrGet > New API for Outgoing Address > - > > Key: TS-3414 > URL: https://issues.apache.org/jira/browse/TS-3414 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Affects Versions: 5.3.0 >Reporter: Sudheer Vinukonda >Assignee: Sudheer Vinukonda > Fix For: 5.3.0 > > > There's currently no TS API to retrieve the source address used by the proxy > in the outbound connections. > I would like to add a new TS API that can provide this info - In addition to > making it consistent with the API for inbound addresses (where we have TS API > for both remote and local addresses), there may be other use cases that need > this info (e.g. applying rate limiting on the inbound side based on the > ephemeral ports). > tsapi struct sockaddr const* TSHttpTxnOutgoingAddrGet(TSHttpTxn txnp); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3415) H2 sending FIN stream too early
[
https://issues.apache.org/jira/browse/TS-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345227#comment-14345227
]
Sudheer Vinukonda commented on TS-3415:
---
[~rokubo]: Your patch resolves this bug, but, I wonder, if it would make sense
to have some sort of (independent) protection to not send out any data frames
after FIN.
> H2 sending FIN stream too early
> ---
>
> Key: TS-3415
> URL: https://issues.apache.org/jira/browse/TS-3415
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Sudheer Vinukonda
> Attachments: ts-3415-02.diff, ts-3415-3414.diff, ts-3415.diff
>
>
> With H2 running on the docs/jenkins server, some of us have noticed empty
> pages on chrome/FF when hitting those servers. Looking at the H2 traces, it
> seems that ATS is sending FIN streams (both SPDY_SESSION_RECV_HEADERS and
> SPDY_SESSION_RECV_DATA with fin flag set to true) before sending the data
> frames. This makes the browser display blank pages.
> Example:
> {code}
> t=31890437 [st=140]SPDY_SESSION_RECV_DATA
>--> fin = true
>--> size = 0
>--> stream_id = 1
> t=31890437 [st=140]SPDY_SESSION_RECV_DATA
>--> fin = false
>--> size = 2591
>--> stream_id = 1
> {code}
> Detailed traces below:
> {code}
> 1112054: SPDY_SESSION
> ci.trafficserver.apache.org:443 (DIRECT)
> Start Time: 2015-02-26 13:30:14.060
> t=31890297 [st= 0] +SPDY_SESSION [dt=?]
> --> host = "ci.trafficserver.apache.org:443"
> --> proxy = "DIRECT"
> t=31890297 [st= 0]SPDY_SESSION_INITIALIZED
>--> protocol = "h2-14"
>--> source_dependency = 1112049 (SOCKET)
> t=31890297 [st= 0]SPDY_SESSION_SEND_SETTINGS
>--> settings = ["[id:3 flags:0 value:1000]","[id:4
> flags:0 value:10485760]"]
> t=31890297 [st= 0]SPDY_STREAM_UPDATE_RECV_WINDOW
>--> delta = 10420224
>--> window_size = 10485760
> t=31890297 [st= 0]SPDY_SESSION_SENT_WINDOW_UPDATE_FRAME
>--> delta = 10420224
>--> stream_id = 0
> t=31890297 [st= 0]SPDY_SESSION_SYN_STREAM
>--> fin = true
>--> :authority: ci.trafficserver.apache.org
>:method: GET
>:path: /job/tsqa-master/180/consoleFull
>:scheme: https
>accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
>accept-encoding: gzip, deflate, sdch
>accept-language: en-US,en;q=0.8
>cache-control: max-age=0
>cookie: [71 bytes were stripped]
>user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X
> 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115
> Safari/537.36
>--> spdy_priority = 0
>--> stream_id = 1
>--> unidirectional = false
> t=31890335 [st= 38]SPDY_SESSION_RECV_SETTINGS
>--> clear_persisted = false
>--> host = "ci.trafficserver.apache.org:443"
> t=31890335 [st= 38]SPDY_SESSION_RECV_SETTING
>--> flags = 0
>--> id = 1
>--> value = 4096
> t=31890335 [st= 38]SPDY_SESSION_RECV_SETTING
>--> flags = 0
>--> id = 2
>--> value = 0
> t=31890335 [st= 38]SPDY_SESSION_RECV_SETTING
>--> flags = 0
>--> id = 3
>--> value = 100
> t=31890436 [st=139]SPDY_SESSION_RECV_HEADERS
>--> fin = true
>--> :status: 200
>age: 1
>cache-control: no-cache,no-store,must-revalidate
>content-encoding: gzip
>content-type: text/html;charset=UTF-8
>date: Thu, 26 Feb 2015 21:30:14 GMT
>expires: Thu, 01 Jan 1970 00:00:00 GMT
>server: ATS/5.3.0
>set-cookie: [67 bytes were stripped]
>strict-transport-security: max-age=86400
>via: http/1.1 ATS (ApacheTrafficServer/5.3.0
> [cMsSf ])
>x-frame-options: sameorigin
>x-hudson: 1.395
>
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[
https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344988#comment-14344988
]
Feifei Cai commented on TS-2497:
For *redirect GET* use case, the test is as follows:
{noformat}
$ curl http://httpbin.org/redirect-to?url=http://httpbin.org/get -L -v
{noformat}
However, the *redirect POST* request is not support:
{noformat}
$ curl http://httpbin.org/redirect-to?url=http://httpbin.org/post -d xxx -L -v
{noformat}
References:
# http://httpbin.org/
# https://github.com/Runscope/httpbin/issues/156
> Failed post results in tunnel buffers being returned to freelist prematurely
>
>
> Key: TS-2497
> URL: https://issues.apache.org/jira/browse/TS-2497
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 4.2.0
>
> Attachments: TS-2497.patch, client.js, origin-server.js, repro.js
>
>
> When a post fails to an origin server either the server died or the server
> returned a response without reading all of the post data, in either case, TS
> will destroy buffers too early. This normally does not result in a crash
> because the MIOBuffers are returned to the freelist and only with sufficient
> load will the race happen causing a crash. Additionally, even if a crash
> doesn't happen you might have data corruption across post requests from the
> buffers being used after being returned to the freelist.
> Thanks to Thomas Jackson for help reproducing and resolving this bug.
> An example stack trace, while we've seen other crashes in write_avail too.
> #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at
> ../iocore/eventsystem/I_IOBuffer.h:362
> #1 0x0050d151 in MIOBuffer::append_block_internal
> (this=0x2aab38001130, b=0x2aab0c037200) at
> ../iocore/eventsystem/P_IOBuffer.h:946
> #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130,
> asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986
> #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at
> ../iocore/eventsystem/P_IOBuffer.h:994
> #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at
> ../iocore/eventsystem/P_IOBuffer.h:1002
> #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at
> ../iocore/eventsystem/P_IOBuffer.h:1048
> #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208,
> vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234
> #7 0x006c37bf in UnixNetVConnection::net_read_io
> (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at
> UnixNetVConnection.cc:816
> #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208,
> event=5, e=0x271d8e0) at UnixNet.cc:380
> #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208,
> event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146
> #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010,
> e=0x271d8e0, calling_code=5) at UnixEThread.cc:142
> #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at
> UnixEThread.cc:264
> #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88
> #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0
> #14 0x0033728e68ed in clone () from /lib64/libc.so.6
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3197) dest_ip in cache.config should be expand to network style
[ https://issues.apache.org/jira/browse/TS-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-3197: -- Issue Type: Improvement (was: Bug) > dest_ip in cache.config should be expand to network style > - > > Key: TS-3197 > URL: https://issues.apache.org/jira/browse/TS-3197 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Configuration, Performance >Reporter: Luca Rea > Fix For: sometime > > > Hi, > I'm tring to exclude a /22 netblock from the cache system but the syntax > "dest_ip" doesn't work, detalis below: > dest_ip="x.y.84.0-x.y.87.255" action=never-cache > I've tried to "stop,clear-cache,start" several times but every time images > have been put into the cache and log shows "NONE FIN FIN TCP_MEM_HIT" or > "NONE FIN FIN TCP_IMS_HIT". > Other Info: > proxy.node.version.manager.long=Apache Traffic Server - traffic_manager - > 5.1.0 - (build # 81013 on Sep 10 2014 at 13:13:42) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3197) dest_ip in cache.config should be expand to network style
[ https://issues.apache.org/jira/browse/TS-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-3197: -- Priority: Minor (was: Major) > dest_ip in cache.config should be expand to network style > - > > Key: TS-3197 > URL: https://issues.apache.org/jira/browse/TS-3197 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Configuration, Performance >Reporter: Luca Rea >Priority: Minor > Fix For: sometime > > > Hi, > I'm tring to exclude a /22 netblock from the cache system but the syntax > "dest_ip" doesn't work, detalis below: > dest_ip="x.y.84.0-x.y.87.255" action=never-cache > I've tried to "stop,clear-cache,start" several times but every time images > have been put into the cache and log shows "NONE FIN FIN TCP_MEM_HIT" or > "NONE FIN FIN TCP_IMS_HIT". > Other Info: > proxy.node.version.manager.long=Apache Traffic Server - traffic_manager - > 5.1.0 - (build # 81013 on Sep 10 2014 at 13:13:42) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3197) dest_ip in cache.config should be expand to network style
[ https://issues.apache.org/jira/browse/TS-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming updated TS-3197: -- Summary: dest_ip in cache.config should be expand to network style (was: dest_ip in cache.config doesn't work) > dest_ip in cache.config should be expand to network style > - > > Key: TS-3197 > URL: https://issues.apache.org/jira/browse/TS-3197 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Configuration, Performance >Reporter: Luca Rea > Fix For: sometime > > > Hi, > I'm tring to exclude a /22 netblock from the cache system but the syntax > "dest_ip" doesn't work, detalis below: > dest_ip="x.y.84.0-x.y.87.255" action=never-cache > I've tried to "stop,clear-cache,start" several times but every time images > have been put into the cache and log shows "NONE FIN FIN TCP_MEM_HIT" or > "NONE FIN FIN TCP_IMS_HIT". > Other Info: > proxy.node.version.manager.long=Apache Traffic Server - traffic_manager - > 5.1.0 - (build # 81013 on Sep 10 2014 at 13:13:42) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3212) 200 code is returned as 304
[
https://issues.apache.org/jira/browse/TS-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344883#comment-14344883
]
Zhao Yongming commented on TS-3212:
---
yeah, let us start tracking on cache control issue then.
and what confusing me is that why IMS is there if your resonse including all
the 'no-cache' directives to inform the client that the content is not
cache-able. that is weird.
anyway, keep this issue open until we fix the cache-control and recheck it.
> 200 code is returned as 304
> ---
>
> Key: TS-3212
> URL: https://issues.apache.org/jira/browse/TS-3212
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: Luca Rea
> Fix For: sometime
>
>
> The live streaming videos from akamaihd.net CDN cannot be watched because ATS
> rewrite codes 200 into 304 and videos enter continuosly in buffering status:
> {code}
> GET
> http://abclive.abcnews.com/z/abc_live1@136327/1200_02769fd3e0d85977-p.bootstrap?g=PDSTQVGEMQKR&b=500,300,700,900,1200&hdcore=3.1.0&plugin=aasp-3.1.0.43.124
> HTTP/1.1
> Host: abclive.abcnews.com
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101
> Firefox/33.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
> Accept-Encoding: gzip, deflate
> Referer:
> http://a.abcnews.com/assets/player/amp/2.0.0012/amp.premier/AkamaiPremierPlayer.swf
> Cookie: _alid_=0OHcZb9VLdpbE6LrNYyDDA==
> Connection: keep-alive
> HTTP/1.1 200 OK
> Server: ContactLab
> Mime-Version: 1.0
> Content-Type: video/abst
> Content-Length: 122
> Last-Modified: Tue, 25 Nov 2014 05:28:32 GMT
> Expires: Tue, 25 Nov 2014 15:31:53 GMT
> Cache-Control: max-age=0, no-cache
> Pragma: no-cache
> Date: Tue, 25 Nov 2014 15:31:53 GMT
> access-control-allow-origin: *
> Set-Cookie: _alid_=0OHcZb9VLdpbE6LrNYyDDA==; path=/z/abc_live1@136327/;
> domain=abclive.abcnews.com
> Age: 0
> Connection: keep-alive
> GET
> http://abclive.abcnews.com/z/abc_live1@136327/1200_02769fd3e0d85977-p.bootstrap?g=PDSTQVGEMQKR&b=500,300,700,900,1200&hdcore=3.1.0&plugin=aasp-3.1.0.43.124
> HTTP/1.1
> Host: abclive.abcnews.com
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101
> Firefox/33.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
> Accept-Encoding: gzip, deflate
> Referer:
> http://a.abcnews.com/assets/player/amp/2.0.0012/amp.premier/AkamaiPremierPlayer.swf
> Cookie: _alid_=0OHcZb9VLdpbE6LrNYyDDA==
> Connection: keep-alive
> If-Modified-Since: Tue, 25 Nov 2014 05:28:32 GMT
> HTTP/1.1 304 Not Modified
> Date: Tue, 25 Nov 2014 15:31:58 GMT
> Expires: Tue, 25 Nov 2014 15:31:58 GMT
> Cache-Control: max-age=0, no-cache
> Connection: keep-alive
> Server: ContactLab
> {code}
> using the url_regex to skip cache/IMS doesn't work, the workaround is the
> following line in records.config:
> CONFIG proxy.config.http.cache.cache_urls_that_look_dynamic INT 0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely
[ https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344875#comment-14344875 ] Feifei Cai commented on TS-2497: Not quite clear about the POST/PUT redirection use case. For GET methods, I have simple test case; however, I have not set up a test case for POST redirection yet. BTW, I tried reverting the patch , i.e. deallocate memory in both no origin server response and receive origin server response cases, it runs stable for ~3 days in our production server. > Failed post results in tunnel buffers being returned to freelist prematurely > > > Key: TS-2497 > URL: https://issues.apache.org/jira/browse/TS-2497 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 4.2.0 > > Attachments: TS-2497.patch, client.js, origin-server.js, repro.js > > > When a post fails to an origin server either the server died or the server > returned a response without reading all of the post data, in either case, TS > will destroy buffers too early. This normally does not result in a crash > because the MIOBuffers are returned to the freelist and only with sufficient > load will the race happen causing a crash. Additionally, even if a crash > doesn't happen you might have data corruption across post requests from the > buffers being used after being returned to the freelist. > Thanks to Thomas Jackson for help reproducing and resolving this bug. > An example stack trace, while we've seen other crashes in write_avail too. > #0 0x004eff14 in IOBufferBlock::read_avail (this=0x0) at > ../iocore/eventsystem/I_IOBuffer.h:362 > #1 0x0050d151 in MIOBuffer::append_block_internal > (this=0x2aab38001130, b=0x2aab0c037200) at > ../iocore/eventsystem/P_IOBuffer.h:946 > #2 0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, > asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986 > #3 0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at > ../iocore/eventsystem/P_IOBuffer.h:994 > #4 0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at > ../iocore/eventsystem/P_IOBuffer.h:1002 > #5 0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at > ../iocore/eventsystem/P_IOBuffer.h:1048 > #6 0x006c18f3 in read_from_net (nh=0x2aaafca0d208, > vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234 > #7 0x006c37bf in UnixNetVConnection::net_read_io > (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at > UnixNetVConnection.cc:816 > #8 0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, > event=5, e=0x271d8e0) at UnixNet.cc:380 > #9 0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, > event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146 > #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, > e=0x271d8e0, calling_code=5) at UnixEThread.cc:142 > #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at > UnixEThread.cc:264 > #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88 > #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0 > #14 0x0033728e68ed in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3212) 200 code is returned as 304
[
https://issues.apache.org/jira/browse/TS-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344764#comment-14344764
]
Luca Rea commented on TS-3212:
--
Hi Zhao,
the workaround I've applied has been to disable cache of dynamic urls:
CONFIG proxy.config.http.cache.cache_urls_that_look_dynamic INT 0
Like you already explained I suppose cache.config is not working as expected.
> 200 code is returned as 304
> ---
>
> Key: TS-3212
> URL: https://issues.apache.org/jira/browse/TS-3212
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: Luca Rea
> Fix For: sometime
>
>
> The live streaming videos from akamaihd.net CDN cannot be watched because ATS
> rewrite codes 200 into 304 and videos enter continuosly in buffering status:
> {code}
> GET
> http://abclive.abcnews.com/z/abc_live1@136327/1200_02769fd3e0d85977-p.bootstrap?g=PDSTQVGEMQKR&b=500,300,700,900,1200&hdcore=3.1.0&plugin=aasp-3.1.0.43.124
> HTTP/1.1
> Host: abclive.abcnews.com
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101
> Firefox/33.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
> Accept-Encoding: gzip, deflate
> Referer:
> http://a.abcnews.com/assets/player/amp/2.0.0012/amp.premier/AkamaiPremierPlayer.swf
> Cookie: _alid_=0OHcZb9VLdpbE6LrNYyDDA==
> Connection: keep-alive
> HTTP/1.1 200 OK
> Server: ContactLab
> Mime-Version: 1.0
> Content-Type: video/abst
> Content-Length: 122
> Last-Modified: Tue, 25 Nov 2014 05:28:32 GMT
> Expires: Tue, 25 Nov 2014 15:31:53 GMT
> Cache-Control: max-age=0, no-cache
> Pragma: no-cache
> Date: Tue, 25 Nov 2014 15:31:53 GMT
> access-control-allow-origin: *
> Set-Cookie: _alid_=0OHcZb9VLdpbE6LrNYyDDA==; path=/z/abc_live1@136327/;
> domain=abclive.abcnews.com
> Age: 0
> Connection: keep-alive
> GET
> http://abclive.abcnews.com/z/abc_live1@136327/1200_02769fd3e0d85977-p.bootstrap?g=PDSTQVGEMQKR&b=500,300,700,900,1200&hdcore=3.1.0&plugin=aasp-3.1.0.43.124
> HTTP/1.1
> Host: abclive.abcnews.com
> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101
> Firefox/33.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
> Accept-Encoding: gzip, deflate
> Referer:
> http://a.abcnews.com/assets/player/amp/2.0.0012/amp.premier/AkamaiPremierPlayer.swf
> Cookie: _alid_=0OHcZb9VLdpbE6LrNYyDDA==
> Connection: keep-alive
> If-Modified-Since: Tue, 25 Nov 2014 05:28:32 GMT
> HTTP/1.1 304 Not Modified
> Date: Tue, 25 Nov 2014 15:31:58 GMT
> Expires: Tue, 25 Nov 2014 15:31:58 GMT
> Cache-Control: max-age=0, no-cache
> Connection: keep-alive
> Server: ContactLab
> {code}
> using the url_regex to skip cache/IMS doesn't work, the workaround is the
> following line in records.config:
> CONFIG proxy.config.http.cache.cache_urls_that_look_dynamic INT 0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
