[jira] [Commented] (TS-974) TS should have a mode to hold partial objects in cache

[Ebrahim Mohammadi (JIRA)]

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

Ebrahim Mohammadi commented on TS-974:
--

Is there a plan for merging the code? In which version do you guess it'll be 
released?

> TS should have a mode to hold partial objects in cache
> --
>
> Key: TS-974
> URL: https://issues.apache.org/jira/browse/TS-974
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Affects Versions: 3.0.1
>Reporter: William Bardwell
>Assignee: Alan M. Carroll
>  Labels: A
> Fix For: 7.1.0
>
>
> For ATS to do an excelent job caching large files like video it would need to 
> be able to hold partial objects for a large file.  This could be done in a 
> plugin or in the core.  This would need to be integrated with the Range 
> handling code to serve requests out of the partial objects and to get more 
> parts of a file to satisfy a Range request.
> An intermediate step (also do-able in the core or in a plugin) would be to 
> have some settings to let the Range handling code be able to trigger a full 
> file download either asynchronously when a Range response indicates that the 
> file isn't larger than some threshold, or synchronously when a Range request 
> could reasonably be answered quickly from a full request.  (Right now Range 
> requests are tunneled if there is not full cached content as far as I can 
> tell.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4882?focusedWorklogId=29480=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29480
 ]

ASF GitHub Bot logged work on TS-4882:
--

Author: ASF GitHub Bot
Created on: 22/Sep/16 04:29
Start Date: 22/Sep/16 04:29
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/743/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29480)
Time Spent: 2h  (was: 1h 50m)

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1036: TS-4882: TCP Fast Open support for server session...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/743/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4882?focusedWorklogId=29479=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29479
 ]

ASF GitHub Bot logged work on TS-4882:
--

Author: ASF GitHub Bot
Created on: 22/Sep/16 04:25
Start Date: 22/Sep/16 04:25
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/848/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29479)
Time Spent: 1h 50m  (was: 1h 40m)

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1036: TS-4882: TCP Fast Open support for server session...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/848/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4641) Change default for proxy.config.cache.hostdb.sync_frequency

[Miles Libbey (JIRA)]

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

Miles Libbey commented on TS-4641:
--

FWIW in 6.2, we think this caused all of our machines to crash 12 hours after 
making the setting.

> Change default for proxy.config.cache.hostdb.sync_frequency
> ---
>
> Key: TS-4641
> URL: https://issues.apache.org/jira/browse/TS-4641
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Documentation, HostDB
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: incompatible
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> I'd like to propose that we change this setting, to 0, which means disable 
> HostDB Synchronization. This is an incompatible change, but nonetheless a 
> step in the right direction away from persistent HostDB storage. People can 
> of course still enable it.
> {code}
> diff --git a/mgmt/RecordsConfig.cc b/mgmt/RecordsConfig.cc
> index ed71b5c..7a7e1c7 100644
> --- a/mgmt/RecordsConfig.cc
> +++ b/mgmt/RecordsConfig.cc
> @@ -1078,7 +1078,7 @@ static const RecordElement RecordsConfig[] =
>{RECT_CONFIG, "proxy.config.hostdb.timed_round_robin", RECD_INT, "0", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>,
>//   # how often should the hostdb be synced (seconds)
> -  {RECT_CONFIG, "proxy.config.cache.hostdb.sync_frequency", RECD_INT, "120", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> +  {RECT_CONFIG, "proxy.config.cache.hostdb.sync_frequency", RECD_INT, "0", 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>,
>{RECT_CONFIG, "proxy.config.hostdb.host_file.path", RECD_STRING, NULL, 
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
>,
> {code}
> Note that changing  it to 0, or changing it from 0 to something else, 
> requires restart. It's only "dynamic" if it it's not 0 (which turns off the 
> sync cont).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1039: 7.0.x

[yavan123]

Github user yavan123 closed the pull request at:

https://github.com/apache/trafficserver/pull/1039


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1039: 7.0.x

[yavan123]

GitHub user yavan123 opened a pull request:

https://github.com/apache/trafficserver/pull/1039

7.0.x

sample.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/trafficserver 7.0.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1039.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1039


commit 407b5451608eabbdedca41355b6df046713fc23a
Author: James Peach 
Date:   2016-09-15T16:46:14Z

TS-4871: Check for TSStatCreate failure.

(cherry picked from commit 0bd6d8f47a473188a1ffc872b51d8567004ca207)

commit 1387c5f1d4dace420b9c6977b14441a001f4b597
Author: Phil Sorber 
Date:   2016-09-15T14:38:39Z

TS-4868: Add configs back and cleanup other cluster init

(cherry picked from commit 81475fb8d320eef45f1a5607812cd63e016e3b40)




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4796) ATS not closing origin connections on first RST from client

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4796?focusedWorklogId=29477=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29477
 ]

ASF GitHub Bot logged work on TS-4796:
--

Author: ASF GitHub Bot
Created on: 22/Sep/16 02:19
Start Date: 22/Sep/16 02:19
Worklog Time Spent: 10m 
  Work Description: Github user jacksontj commented on the issue:

https://github.com/apache/trafficserver/pull/947
  
@zwoop ping :)


Issue Time Tracking
---

Worklog Id: (was: 29477)
Time Spent: 8h 10m  (was: 8h)

> ATS not closing origin connections on first RST from client
> ---
>
> Key: TS-4796
> URL: https://issues.apache.org/jira/browse/TS-4796
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Thomas Jackson
>Assignee: Thomas Jackson
> Fix For: 7.1.0
>
>  Time Spent: 8h 10m
>  Remaining Estimate: 0h
>
> *TLDR; similar to TS-4720 -- slower to close than it should, instead of never 
> closing*
> As a continuation of TS-4720, while testing that the session is closed when 
> we expect-- I found that it isn't.
> Although we are now closing the sessions, we aren't doing it as quickly as we 
> should. In this client abort case we expect the client to abort, and ATS 
> should initially continue to send bytes to the client-- as we are in the 
> half-open state. After the first set of bytes are sent to the client-- the 
> client will send an RST-- which should signal ATS to stop sending the request 
> (and tear down the origin connection etc.).
> I'm able to reproduce this locally, and the debug output (with some 
> additional comments) looks like below:
> {code}
> < FIN FROM CLIENT >
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (main_handler)> (http) [0] [HttpSM::main_handler, VC_EVENT_EOS]
> [Aug 29 18:25:07.491] Server {0x7effa538a800} DEBUG:  (state_watch_for_client_abort)> (http) [0] 
> [::state_watch_for_client_abort, VC_EVENT_EOS]
> < RST FROM CLIENT >
> Got an HttpTunnel event 100 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_tunnel) [0] producer_handler [http server 
> VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler_chunked)> (http_tunnel) [0] producer_handler_chunked [http 
> server VC_EVENT_READ_READY]
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_size)> (http_chunk) read chunk size of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (read_chunk)> (http_chunk) completed read of chunk of 15 bytes
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (producer_handler)> (http_redirect) [HttpTunnel::producer_handler] 
> enable_redirection: [1 0 0] event: 100
> Got an HttpTunnel event 101 
> [Aug 29 18:25:13.062] Server {0x7effa538a800} DEBUG:  (consumer_handler)> (http_tunnel) [0] consumer_handler [user agent 
> VC_EVENT_WRITE_READY]
> write ready consumer_handler
> {code}
> In this situation the connection doesn't close here at the RST-- but rather 
> on the next set of bytes from the origin to send-- which end up tripping a 
> VC_EVENT_ERROR-- and tearing down the connection.
> When the client sends the first RST epoll returns a WRITE_READY event -- 
> which the HTTPTunnel consumer ignores completely. It seems then that when we 
> recieve the WRITE_READY event we need to determine if we are already in the 
> writing state-- and if so, then we should stop the transaction (since we are 
> already edge-triggered).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #947: TS-4796 Change UnixNetHandler to always bubble up ...

[jacksontj]

Github user jacksontj commented on the issue:

https://github.com/apache/trafficserver/pull/947
  
@zwoop ping :)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work started] (TS-4715) clean up log format documentation

[Jon Sime (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on TS-4715 started by Jon Sime.

> clean up log format documentation
> -
>
> Key: TS-4715
> URL: https://issues.apache.org/jira/browse/TS-4715
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: James Peach
>Assignee: Jon Sime
> Fix For: Docs
>
>
> While looking at the log documentation, it seemed like we could make some 
> improvements
> - Move the logging tags into a separate page. This would make it easier to 
> find them from the index and give us an opportunity to group them by category.
> - Verify that all log fields are documented. Might be helpful to have a code 
> change or tool that lists them.
> - Add logging tag anchor links. It would be helpful to be able to link to a 
> specific logging tag like we do for records.config variables.
> - All mentions of log fields should like to their definitions.
> - The "Custom Field Cross-Reference" section is confusing since there is 
> already a previous section documenting the predefined formats. We should 
> condense this.
> - The "Log Field Slicing" section should be moved to the section that 
> describes the general log format syntax.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4715) clean up log format documentation

[Jon Sime (JIRA)]

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

Jon Sime commented on TS-4715:
--

Commit 6d2c6cb addresses almost all these points, and includes a lot of other 
cleanup/reorganization/additions to the Admin guide's logging chapter. It also 
bumps it up to a top-level chapter, instead of jamming it together with the 
monitoring sections into the slightly-obscuring "Event and Error Monitoring" 
where it used to be. There's now two separate, very simply labeled chapters: 
"Logging" and "Monitoring."

I'm not closing this issue from that commit because I've yet to make an 
exhaustive pass through the docs to make sure all log field references are 
actually linked (instead of just listing the field name as a bareword), and 
verifying that all the log fields in the proxy code are actually in the docs 
now. Once those two things are taken care of, this issue will be fully 
addressed.

> clean up log format documentation
> -
>
> Key: TS-4715
> URL: https://issues.apache.org/jira/browse/TS-4715
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: James Peach
>Assignee: Jon Sime
> Fix For: Docs
>
>
> While looking at the log documentation, it seemed like we could make some 
> improvements
> - Move the logging tags into a separate page. This would make it easier to 
> find them from the index and give us an opportunity to group them by category.
> - Verify that all log fields are documented. Might be helpful to have a code 
> change or tool that lists them.
> - Add logging tag anchor links. It would be helpful to be able to link to a 
> specific logging tag like we do for records.config variables.
> - All mentions of log fields should like to their definitions.
> - The "Custom Field Cross-Reference" section is confusing since there is 
> already a previous section documenting the predefined formats. We should 
> condense this.
> - The "Log Field Slicing" section should be moved to the section that 
> describes the general log format syntax.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4882?focusedWorklogId=29473=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29473
 ]

ASF GitHub Bot logged work on TS-4882:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 23:43
Start Date: 21/Sep/16 23:43
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1036#discussion_r79952516
  
--- Diff: iocore/net/BIO_fastopen.cc ---
@@ -0,0 +1,168 @@
+/** @file
+ *
+ *  OpenSSL socket BIO that does TCP Fast Open.
+ *
+ *  @section license License
+ *
+ *  Licensed to the Apache Software Foundation (ASF) under one
+ *  or more contributor license agreements.  See the NOTICE file
+ *  distributed with this work for additional information
+ *  regarding copyright ownership.  The ASF licenses this file
+ *  to you under the Apache License, Version 2.0 (the
+ *  "License"); you may not use this file except in compliance
+ *  with the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *  Unless required by applicable law or agreed to in writing, software
+ *  distributed under the License is distributed on an "AS IS" BASIS,
+ *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
implied.
+ *  See the License for the specific language governing permissions and
+ *  limitations under the License.
+ */
+
+#include "P_Net.h"
+#include "I_SocketManager.h"
+#include "ts/ink_assert.h"
+
+#include "BIO_fastopen.h"
+
+static int
+fastopen_create(BIO *bio)
+{
+  bio->init  = 0;
+  bio->num   = NO_FD;
+  bio->flags = 0;
+  bio->ptr   = NULL;
+
+  return 1;
+}
+
+static int
+fastopen_destroy(BIO *bio)
+{
+  if (bio) {
+// We expect this BIO to not own the socket, so we must always
+// be in NOCLOSE mode.
+ink_assert(bio->shutdown == BIO_NOCLOSE);
+fastopen_create(bio);
+  }
+
+  return 1;
+}
+
+static int
+fastopen_bwrite(BIO *bio, const char *in, int insz)
+{
+  int64_t err;
+
+  errno = 0;
+  BIO_clear_retry_flags(bio);
+  ink_assert(bio->num != NO_FD);
+
+  if (bio->ptr) {
+// On the first write only, make a TFO request if TFO is enabled.
+// The best documentation on the behavior of the Linux API is in
+// RFC 7413. If we get EINPROGRESS it means that the SYN has been
+// sent without data and we should retry.
--- End diff --

the server doesn't have a tfo cookie for the origin


Issue Time Tracking
---

Worklog Id: (was: 29473)
Time Spent: 1h 40m  (was: 1.5h)

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4882?focusedWorklogId=29471=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29471
 ]

ASF GitHub Bot logged work on TS-4882:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 23:43
Start Date: 21/Sep/16 23:43
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1036#discussion_r79950331
  
--- Diff: doc/admin-guide/files/records.config.en.rst ---
@@ -3388,13 +3388,19 @@ Sockets
 TCP_NODELAY  (1)
 SO_KEEPALIVE (2)
 SO_LINGER (4) - with a timeout of 0 seconds
+TCP_FASTOPEN (8)
 
 .. note::
 
This is a bitmask and you need to decide what bits to set.  Therefore,
you must set the value to ``3`` if you want to enable nodelay and
keepalive options above.
 
+.. note::
+
+   To allow TCP Fast Open for client sockets on Linux, bit 2 of
--- End diff --

Isn't it bit 1 for client sessions or a value of 1?  That should be the 
default on most linux distros.


Issue Time Tracking
---

Worklog Id: (was: 29471)
Time Spent: 1h 40m  (was: 1.5h)

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1036: TS-4882: TCP Fast Open support for server ...

[bryancall]

Github user bryancall commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1036#discussion_r79952516
  
--- Diff: iocore/net/BIO_fastopen.cc ---
@@ -0,0 +1,168 @@
+/** @file
+ *
+ *  OpenSSL socket BIO that does TCP Fast Open.
+ *
+ *  @section license License
+ *
+ *  Licensed to the Apache Software Foundation (ASF) under one
+ *  or more contributor license agreements.  See the NOTICE file
+ *  distributed with this work for additional information
+ *  regarding copyright ownership.  The ASF licenses this file
+ *  to you under the Apache License, Version 2.0 (the
+ *  "License"); you may not use this file except in compliance
+ *  with the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *  Unless required by applicable law or agreed to in writing, software
+ *  distributed under the License is distributed on an "AS IS" BASIS,
+ *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
implied.
+ *  See the License for the specific language governing permissions and
+ *  limitations under the License.
+ */
+
+#include "P_Net.h"
+#include "I_SocketManager.h"
+#include "ts/ink_assert.h"
+
+#include "BIO_fastopen.h"
+
+static int
+fastopen_create(BIO *bio)
+{
+  bio->init  = 0;
+  bio->num   = NO_FD;
+  bio->flags = 0;
+  bio->ptr   = NULL;
+
+  return 1;
+}
+
+static int
+fastopen_destroy(BIO *bio)
+{
+  if (bio) {
+// We expect this BIO to not own the socket, so we must always
+// be in NOCLOSE mode.
+ink_assert(bio->shutdown == BIO_NOCLOSE);
+fastopen_create(bio);
+  }
+
+  return 1;
+}
+
+static int
+fastopen_bwrite(BIO *bio, const char *in, int insz)
+{
+  int64_t err;
+
+  errno = 0;
+  BIO_clear_retry_flags(bio);
+  ink_assert(bio->num != NO_FD);
+
+  if (bio->ptr) {
+// On the first write only, make a TFO request if TFO is enabled.
+// The best documentation on the behavior of the Linux API is in
+// RFC 7413. If we get EINPROGRESS it means that the SYN has been
+// sent without data and we should retry.
--- End diff --

the server doesn't have a tfo cookie for the origin


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4882?focusedWorklogId=29472=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29472
 ]

ASF GitHub Bot logged work on TS-4882:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 23:43
Start Date: 21/Sep/16 23:43
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on a diff in the pull 
request:

https://github.com/apache/trafficserver/pull/1036#discussion_r79950862
  
--- Diff: doc/admin-guide/files/records.config.en.rst ---
@@ -3426,6 +3433,11 @@ Sockets
are co-located and large numbers of sockets are retained
in the TIME_WAIT state.
 
+.. note::
+
+   To allow TCP Fast Open for server sockets on Linux, bit 1 of
--- End diff --

For a server to listen bit 2 should be set or a value of 2.  If you want 
client and server set you should set 3.


Issue Time Tracking
---

Worklog Id: (was: 29472)
Time Spent: 1h 40m  (was: 1.5h)

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1036: TS-4882: TCP Fast Open support for server ...

[bryancall]

Github user bryancall commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1036#discussion_r79950862
  
--- Diff: doc/admin-guide/files/records.config.en.rst ---
@@ -3426,6 +3433,11 @@ Sockets
are co-located and large numbers of sockets are retained
in the TIME_WAIT state.
 
+.. note::
+
+   To allow TCP Fast Open for server sockets on Linux, bit 1 of
--- End diff --

For a server to listen bit 2 should be set or a value of 2.  If you want 
client and server set you should set 3.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver pull request #1036: TS-4882: TCP Fast Open support for server ...

[bryancall]

Github user bryancall commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/1036#discussion_r79950331
  
--- Diff: doc/admin-guide/files/records.config.en.rst ---
@@ -3388,13 +3388,19 @@ Sockets
 TCP_NODELAY  (1)
 SO_KEEPALIVE (2)
 SO_LINGER (4) - with a timeout of 0 seconds
+TCP_FASTOPEN (8)
 
 .. note::
 
This is a bitmask and you need to decide what bits to set.  Therefore,
you must set the value to ``3`` if you want to enable nodelay and
keepalive options above.
 
+.. note::
+
+   To allow TCP Fast Open for client sockets on Linux, bit 2 of
--- End diff --

Isn't it bit 1 for client sessions or a value of 1?  That should be the 
default on most linux distros.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4884) Remove a few unused variables/define in EThread

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4884?focusedWorklogId=29470=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29470
 ]

ASF GitHub Bot logged work on TS-4884:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 23:33
Start Date: 21/Sep/16 23:33
Worklog Time Spent: 10m 
  Work Description: Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1038


Issue Time Tracking
---

Worklog Id: (was: 29470)
Time Spent: 20m  (was: 10m)

> Remove a few unused variables/define in EThread
> ---
>
> Key: TS-4884
> URL: https://issues.apache.org/jira/browse/TS-4884
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Masato Gosui
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> EThread has variable accept_event and main_accept_index, which are unused.
> Also MAX_ACCEPT_EVENTS is not used other than the declaration of accept_event.
> We should be able to remove them without any side effects.
> Looks like these are remnants of old code cleanup.
> https://github.com/apache/trafficserver/commit/0a0c90dd94fd53a0cf9617f945e4e7d9fe42c7a9



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1038: TS-4884: Remove a few unused variables/def...

[PSUdaemon]

Github user PSUdaemon closed the pull request at:

https://github.com/apache/trafficserver/pull/1038


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4507) It is still possible for SSN_CLOSE hook to be called before TXN_CLOSE hook

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4507:


Requesting the backport because other stability fixes rely on these changes.

> It is still possible for SSN_CLOSE hook to be called before TXN_CLOSE hook
> --
>
> Key: TS-4507
> URL: https://issues.apache.org/jira/browse/TS-4507
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> One of our plugins will occasionally crash.  It appears there is still a path 
> for HTTP2 that has the SSN_CLOSE hook close before the TXN_CLOSE hook.
> Working through solutions that delay the SSN_CLOSE hook until after all the 
> TXN_CLOSE hooks, but does not lose the SSN_CLOSE. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4507) It is still possible for SSN_CLOSE hook to be called before TXN_CLOSE hook

[Susan Hinrichs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Susan Hinrichs updated TS-4507:
---
Backport to Version: 6.2.1

> It is still possible for SSN_CLOSE hook to be called before TXN_CLOSE hook
> --
>
> Key: TS-4507
> URL: https://issues.apache.org/jira/browse/TS-4507
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> One of our plugins will occasionally crash.  It appears there is still a path 
> for HTTP2 that has the SSN_CLOSE hook close before the TXN_CLOSE hook.
> Working through solutions that delay the SSN_CLOSE hook until after all the 
> TXN_CLOSE hooks, but does not lose the SSN_CLOSE. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4882?focusedWorklogId=29468=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29468
 ]

ASF GitHub Bot logged work on TS-4882:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 21:04
Start Date: 21/Sep/16 21:04
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/742/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29468)
Time Spent: 1.5h  (was: 1h 20m)

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1036: TS-4882: TCP Fast Open support for server session...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/742/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4882?focusedWorklogId=29467=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29467
 ]

ASF GitHub Bot logged work on TS-4882:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 21:03
Start Date: 21/Sep/16 21:03
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/847/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29467)
Time Spent: 1h 20m  (was: 1h 10m)

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1036: TS-4882: TCP Fast Open support for server session...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/847/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4815) CID 1267839 dead code in /mgmt/api/CfgContextManager.cc: return TS_ERR_PARAMS;

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4815?focusedWorklogId=29465=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29465
 ]

ASF GitHub Bot logged work on TS-4815:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 20:03
Start Date: 21/Sep/16 20:03
Worklog Time Spent: 10m 
  Work Description: Github user ngara commented on the issue:

https://github.com/apache/trafficserver/pull/963
  
Alright, I cleaned up my mess. Here's just the single commit.


Issue Time Tracking
---

Worklog Id: (was: 29465)
Time Spent: 2h 20m  (was: 2h 10m)

> CID 1267839 dead code in /mgmt/api/CfgContextManager.cc: return TS_ERR_PARAMS;
> --
>
> Key: TS-4815
> URL: https://issues.apache.org/jira/browse/TS-4815
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: Nathan Garabedian
>Assignee: Nathan Garabedian
> Fix For: 7.1.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
>   cond_notnull: Condition ctx, taking true branch. Now the value of ctx 
> is not NULL.
> 165  ink_assert(ctx);
>   notnull: At condition ctx, the value of ctx cannot be NULL.
>   dead_error_condition: The condition !ctx cannot be true.
> 166  if (!ctx) {
>   
> CID 1267839 (#1 of 1): Logically dead code (DEADCODE)
> dead_error_line: Execution cannot reach this statement: return TS_ERR_PARAMS;.
> 167return TS_ERR_PARAMS;
> 168  }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #963: TS-4815 - CID 1267839 dead code in /mgmt/api/CfgCo...

[ngara]

Github user ngara commented on the issue:

https://github.com/apache/trafficserver/pull/963
  
Alright, I cleaned up my mess. Here's just the single commit.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4882?focusedWorklogId=29463=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29463
 ]

ASF GitHub Bot logged work on TS-4882:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 19:39
Start Date: 21/Sep/16 19:39
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/741/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29463)
Time Spent: 1h 10m  (was: 1h)

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1036: TS-4882: TCP Fast Open support for server session...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/741/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4882?focusedWorklogId=29462=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29462
 ]

ASF GitHub Bot logged work on TS-4882:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 19:39
Start Date: 21/Sep/16 19:39
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/846/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29462)
Time Spent: 1h  (was: 50m)

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1036: TS-4882: TCP Fast Open support for server session...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/846/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4819) ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4819:


Got a fix that addresses Persia's use case, but it may end up closing the 
Client Session (and invoking the SSN_CLOSE hook) before the transaction closes. 
 Poking around in our local code, I see another fix that would preserve the 
hook ordering on shutdown.  Will try to extract that fix and make a PR.

> ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted
> ---
>
> Key: TS-4819
> URL: https://issues.apache.org/jira/browse/TS-4819
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: Syeda Persia Aziz
> Fix For: 7.1.0
>
> Attachments: test_post.py
>
>
>  I found this when using the python "requests" library to generate HTTP 
> requests to test the ATS. The request method of this library generates 
> incorrect message body (i.e., does not follow the standard format) if both 
> Content-Length and chunked encoding are specified. ATS can handle requests 
> with these two fields being specified. It is the wrong format of the chunk 
> that makes the ATS crash. The test program to reproduce the issue is 
> attached. If the Content-Length is  removed from the header, then the library 
> generates the correct format and ATS responds correctly. Ideally, 
> content-length and chunked encoding should not be specified together



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1036: TS-4882: TCP Fast Open support for server session...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/845/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4882?focusedWorklogId=29461=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29461
 ]

ASF GitHub Bot logged work on TS-4882:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 18:58
Start Date: 21/Sep/16 18:58
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
FreeBSD build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/845/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29461)
Time Spent: 50m  (was: 40m)

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4882) TCP Fast Open support for SSL server sessions.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4882?focusedWorklogId=29460=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29460
 ]

ASF GitHub Bot logged work on TS-4882:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 18:54
Start Date: 21/Sep/16 18:54
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/740/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29460)
Time Spent: 40m  (was: 0.5h)

> TCP Fast Open support for SSL server sessions.
> --
>
> Key: TS-4882
> URL: https://issues.apache.org/jira/browse/TS-4882
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, SSL
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Add support for using TCP Fast Open on TLS server sessions. This is mainly 
> interesting for CONNECT tunnels where we can't use long running persistent 
> sessions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #1036: TS-4882: TCP Fast Open support for server session...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1036
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/740/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

[Gancho Tenev (JIRA)]

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

Gancho Tenev commented on TS-4334:
--

[~jamesf], sounds good. The above solution was just to demonstrate the idea, 
you would need to adjust it to your particular use-case and verify if it works.

Cheers,
--Gancho

> The cache_range_requests plugin always attempts to modify the cache key.
> 
>
> Key: TS-4334
> URL: https://issues.apache.org/jira/browse/TS-4334
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>
> A TrafficServer administrator should be able to specify whether or not the 
> cache_range_requests plugin should modify the cache key.  The cache key may 
> be modified by a previous plugin in a plugin chain and there is no way to 
> configure cache_range_requests not to do any further modifications to the 
> cache key.  Having multiple plugins responsible for cache key modifications 
> can cause unexpected behavior, especially when a plugin chain ordering is 
> changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4819) ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-4819:


I think this bug is related to TS-4664.  On an error, the state machine calls 
ua_session->do_io_close() which causes the SSN_CLOSE hook to be processed.  

We are running internally with the fix proposed by TS-4664.  This delays the 
ProxyClientSession SSN_CLOSE hook processing until we get to a point when the 
State Machine is gone.  This particular case does not crash in our patched 
5.3.x. Without this fix, the SSN_CLOSE processing happens immediately which 
frees the Http1ClientSession (and Http2ClientTransaction object).  In this 
particular case, the freed ua_session object is referenced on the way out of 
the function causing the crash.  

This error case freeing might also explain some of the crashes we are seeing in 
6.2/7.0.

> ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted
> ---
>
> Key: TS-4819
> URL: https://issues.apache.org/jira/browse/TS-4819
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: Syeda Persia Aziz
> Fix For: 7.1.0
>
> Attachments: test_post.py
>
>
>  I found this when using the python "requests" library to generate HTTP 
> requests to test the ATS. The request method of this library generates 
> incorrect message body (i.e., does not follow the standard format) if both 
> Content-Length and chunked encoding are specified. ATS can handle requests 
> with these two fields being specified. It is the wrong format of the chunk 
> that makes the ATS crash. The test program to reproduce the issue is 
> attached. If the Content-Length is  removed from the header, then the library 
> generates the correct format and ATS responds correctly. Ideally, 
> content-length and chunked encoding should not be specified together



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4819) ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz commented on TS-4819:
---

bt full
===

#0  0x0055aa15 in ProxyClientTransaction::get_half_close_flag 
(this=0x7fffb027bad0) at http/../ProxyClientTransaction.h:79
__FUNCTION__ = "get_half_close_flag"
#1  0x005f43bf in HttpSM::do_setup_post_tunnel (this=0x7fffe810c1e0, 
to_vc_type=HTTP_SERVER_VC) at HttpSM.cc:5621
chunked = true
post_redirect = false
p = 0x7fffe810d718
#2  0x005e5b14 in HttpSM::state_send_server_request_header 
(this=0x7fffe810c1e0, event=103, data=0x7fffa4018e90) at HttpSM.cc:1995
__FUNCTION__ = "state_send_server_request_header"
method = 118
#3  0x005e84e0 in HttpSM::main_handler (this=0x7fffe810c1e0, event=103, 
data=0x7fffa4018e90) at HttpSM.cc:2658
jump_point = (int (HttpSM::*)(HttpSM * const, int, void *)) 0x5e587c 

__FUNCTION__ = "main_handler"
vc_entry = 0x7fffe810d9d0
#4  0x00510374 in Continuation::handleEvent (this=0x7fffe810c1e0, 
event=103, data=0x7fffa4018e90) at ../iocore/eventsystem/I_Continuation.h:153
No locals.
#5  0x0079a019 in write_signal_and_update (event=103, 
vc=0x7fffa4018d00) at UnixNetVConnection.cc:184
__FUNCTION__ = "write_signal_and_update"
#6  0x0079a224 in write_signal_done (event=103, nh=0x74bcacd0, 
vc=0x7fffa4018d00) at UnixNetVConnection.cc:226
No locals.
#7  0x0079b5b3 in write_to_net_io (nh=0x74bcacd0, 
vc=0x7fffa4018d00, thread=0x74bc7010) at UnixNetVConnection.cc:556
wbe_event = 0
s = 0x7fffa4018e88
mutex = 0x1130cd0
lock = {m = {m_ptr = 0x7fffb024e460}, lock_acquired = true}
__FUNCTION__ = "write_to_net_io"
ntodo = 480
buf = @0x7fffa4018eb0: {name = 0x0, mbuf = 0x0, entry = 0x0}
towrite = 480
signalled = 0
needs = -2147483644
total_written = 480
r = 480
#8  0x0079ae1f in write_to_net (nh=0x74bcacd0, vc=0x7fffa4018d00, 
thread=0x74bc7010) at UnixNetVConnection.cc:423
mutex = 0x1130cd0
#9  0x00791cd2 in NetHandler::mainNetEvent (this=0x74bcacd0, 
event=5, e=0x1194ac0) at UnixNet.cc:530
epd = 0x7fffa4018f48
poll_timeout = 10
pd = 0x7429c010
vc = 0x7fffa4018d00
__FUNCTION__ = "mainNetEvent"
#10 0x00510374 in Continuation::handleEvent (this=0x74bcacd0, 
event=5, data=0x1194ac0) at ../iocore/eventsystem/I_Continuation.h:153
No locals.
#11 0x007bdc6f in EThread::process_event (this=0x74bc7010, 
e=0x1194ac0, calling_code=5) at UnixEThread.cc:148
c_temp = 0x74bcacd0
lock = {m = {m_ptr = 0x11303a0}, lock_acquired = true}
__FUNCTION__ = "process_event"
#12 0x007be272 in EThread::execute (this=0x74bc7010) at 
UnixEThread.cc:275
done_one = false
e = 0x1194ac0
NegativeQueue = {> = {head = 0x0}, tail = 
0x0}


> ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted
> ---
>
> Key: TS-4819
> URL: https://issues.apache.org/jira/browse/TS-4819
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: Syeda Persia Aziz
> Fix For: 7.1.0
>
> Attachments: test_post.py
>
>
>  I found this when using the python "requests" library to generate HTTP 
> requests to test the ATS. The request method of this library generates 
> incorrect message body (i.e., does not follow the standard format) if both 
> Content-Length and chunked encoding are specified. ATS can handle requests 
> with these two fields being specified. It is the wrong format of the chunk 
> that makes the ATS crash. The test program to reproduce the issue is 
> attached. If the Content-Length is  removed from the header, then the library 
> generates the correct format and ATS responds correctly. Ideally, 
> content-length and chunked encoding should not be specified together



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4815) CID 1267839 dead code in /mgmt/api/CfgContextManager.cc: return TS_ERR_PARAMS;

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4815?focusedWorklogId=29446=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29446
 ]

ASF GitHub Bot logged work on TS-4815:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 15:42
Start Date: 21/Sep/16 15:42
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/963
  
@ngara  Maybe I'm reading this wrong, but it looks like we still have 3 
commits in this PR. If that's the case, can you please squash that down into a 
single commit? No reason to have the 2 previous versions in the git commit 
history.


Issue Time Tracking
---

Worklog Id: (was: 29446)
Time Spent: 2h 10m  (was: 2h)

> CID 1267839 dead code in /mgmt/api/CfgContextManager.cc: return TS_ERR_PARAMS;
> --
>
> Key: TS-4815
> URL: https://issues.apache.org/jira/browse/TS-4815
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: Nathan Garabedian
>Assignee: Nathan Garabedian
> Fix For: 7.1.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
>   cond_notnull: Condition ctx, taking true branch. Now the value of ctx 
> is not NULL.
> 165  ink_assert(ctx);
>   notnull: At condition ctx, the value of ctx cannot be NULL.
>   dead_error_condition: The condition !ctx cannot be true.
> 166  if (!ctx) {
>   
> CID 1267839 (#1 of 1): Logically dead code (DEADCODE)
> dead_error_line: Execution cannot reach this statement: return TS_ERR_PARAMS;.
> 167return TS_ERR_PARAMS;
> 168  }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #963: TS-4815 - CID 1267839 dead code in /mgmt/api/CfgCo...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/963
  
@ngara  Maybe I'm reading this wrong, but it looks like we still have 3 
commits in this PR. If that's the case, can you please squash that down into a 
single commit? No reason to have the 2 previous versions in the git commit 
history.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4705) Proposal: NetVC Context

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4705?focusedWorklogId=29445=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29445
 ]

ASF GitHub Bot logged work on TS-4705:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 15:18
Start Date: 21/Sep/16 15:18
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/753
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/844/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29445)
Time Spent: 3.5h  (was: 3h 20m)

> Proposal: NetVC Context
> ---
>
> Key: TS-4705
> URL: https://issues.apache.org/jira/browse/TS-4705
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.1.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Goal 1st:
> In the NetVConnection, we have get_local_addr() and get_remote_addr() methods.
> Also have members local_addr, remote_addr and netvc->con.addr.
> Thus, we should using netvc->con.addr or remote_addr to replace member 
> server_addr in UnixNetVConnection.
> Goal 2nd:
> SSLNetVConnection has member sslClientConnection with 2 methods 
> setSSLClientConnection() and getSSLClientConnection() to indictor ATS is a 
> client or server in a SSL session.
> To abstract above two goals, I'm design the netvc context function.
> As a proxy, there has two side: client side ( Client <-> Proxy ) and server 
> side ( Proxy <-> Server ). With the netvc context funtion to indicate which 
> side the NetVC working on.
> Goal 3rd:
> Fix a minor bug in NetAccept::do_blocking_accept, call to 
> check_emergency_throttle(con) first then allocate vc.
> Goal 4th:
> NetAccept Optimize, remove dup code, etc...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #753: TS-4705: Proposal: NetVC Context

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/753
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/844/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4705) Proposal: NetVC Context

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4705?focusedWorklogId=29444=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29444
 ]

ASF GitHub Bot logged work on TS-4705:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 15:14
Start Date: 21/Sep/16 15:14
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/753
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/739/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 29444)
Time Spent: 3h 20m  (was: 3h 10m)

> Proposal: NetVC Context
> ---
>
> Key: TS-4705
> URL: https://issues.apache.org/jira/browse/TS-4705
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.1.0
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> Goal 1st:
> In the NetVConnection, we have get_local_addr() and get_remote_addr() methods.
> Also have members local_addr, remote_addr and netvc->con.addr.
> Thus, we should using netvc->con.addr or remote_addr to replace member 
> server_addr in UnixNetVConnection.
> Goal 2nd:
> SSLNetVConnection has member sslClientConnection with 2 methods 
> setSSLClientConnection() and getSSLClientConnection() to indictor ATS is a 
> client or server in a SSL session.
> To abstract above two goals, I'm design the netvc context function.
> As a proxy, there has two side: client side ( Client <-> Proxy ) and server 
> side ( Proxy <-> Server ). With the netvc context funtion to indicate which 
> side the NetVC working on.
> Goal 3rd:
> Fix a minor bug in NetAccept::do_blocking_accept, call to 
> check_emergency_throttle(con) first then allocate vc.
> Goal 4th:
> NetAccept Optimize, remove dup code, etc...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #753: TS-4705: Proposal: NetVC Context

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/753
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/739/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-4468:
-

If they are always the same, then why does it matter which is used as an 
argument to {{acquire_session}}? Although I see the point of what the patch is 
actually doing if on the origin server side the SNI and FQDN in the request are 
always the same. It may be only in the sticky session case this matters.

> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[Oknet Xu (JIRA)]

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

Oknet Xu commented on TS-4468:
--

{code}
One thing that's not clear is in what situations `t_state.current.server->name` 
is not the same as `server_request.get_host`.
{code}

according the code, they are synced.

There would be a bug if they are not synced.

Therefore, we should revert the commit and fix the bug.

> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[Oknet Xu (JIRA)]

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

Oknet Xu commented on TS-4468:
--

{code}
At most, if we decided we needed to be stringent in enforcing SNI/host matching 
on client side, I would want the ability to opt out. 
{code}

agree with that, an option to control it. [~jered]

> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[Oknet Xu (JIRA)]

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

Oknet Xu edited comment on TS-4468 at 9/21/16 2:01 PM:
---

RFC 6066 conflic with RFC 7540:

{code}
RFC 6066

If the server_name is
   established in the TLS session handshake, the client SHOULD NOT
   attempt to request a different server name at the application layer.

{code}


{code}
RFC 7540

9.1.1 Connection Reuse

Connections that are made to an origin server, either directly or through a 
tunnel created using the CONNECT method (Section 8.3), MAY be reused for 
requests with multiple different URI authority components. A connection can be 
reused as long as the origin server is authoritative (Section 10.1). For TCP 
connections without TLS, this depends on the host having resolved to the same 
IP address.

For https resources, connection reuse additionally depends on having a 
certificate that is valid for the host in the URI. The certificate presented by 
the server MUST satisfy any checks that the client would perform when forming a 
new TLS connection for the host in the URI.

An origin server might offer a certificate with multiple subjectAltName 
attributes or names with wildcards, one of which is valid for the authority in 
the URI. For example, a certificate with a subjectAltName of *.example.com 
might permit the use of the same connection for requests to URIs starting with 
https://a.example.com/ and https://b.example.com/.

{code}


RFC 7540, HTTP/2 allow connection reuse depends on having a certificate that is 
valid for the host in the URI.
But RFC 6066, Only allow connection reuse depends on having a same SNI for the 
host in the URI.

Depend on a research for Firefox, Chrome and Edge, Sarfri:
https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/

- Firefox reuse connection by IP address.
- The chrome reuse connection by both.
- Edge & Sarfri reuse connection by hostname.



was (Author: oknet):
RFC 6066 conflic with RFC 7540:

{code}
RFC 6066

If the server_name is
   established in the TLS session handshake, the client SHOULD NOT
   attempt to request a different server name at the application layer.

{code}


{code}
RFC 7540

9.1.1 Connection Reuse

Connections that are made to an origin server, either directly or through a 
tunnel created using the CONNECT method (Section 8.3), MAY be reused for 
requests with multiple different URI authority components. A connection can be 
reused as long as the origin server is authoritative (Section 10.1). For TCP 
connections without TLS, this depends on the host having resolved to the same 
IP address.

For https resources, connection reuse additionally depends on having a 
certificate that is valid for the host in the URI. The certificate presented by 
the server MUST satisfy any checks that the client would perform when forming a 
new TLS connection for the host in the URI.

An origin server might offer a certificate with multiple subjectAltName 
attributes or names with wildcards, one of which is valid for the authority in 
the URI. For example, a certificate with a subjectAltName of *.example.com 
might permit the use of the same connection for requests to URIs starting with 
https://a.example.com/ and https://b.example.com/.

{code}


RFC 7540, HTTP/2 allow connection reuse depends on having a certificate that is 
valid for the host in the URI.
But RFC 6066, Only allow connection reuse depends on having a same SNI for the 
host in the URI.


> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:

[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS

[Oknet Xu (JIRA)]

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

Oknet Xu commented on TS-4468:
--

RFC 6066 conflic with RFC 7540:

{code}
RFC 6066

If the server_name is
   established in the TLS session handshake, the client SHOULD NOT
   attempt to request a different server name at the application layer.

{code}


{code}
RFC 7540

9.1.1 Connection Reuse

Connections that are made to an origin server, either directly or through a 
tunnel created using the CONNECT method (Section 8.3), MAY be reused for 
requests with multiple different URI authority components. A connection can be 
reused as long as the origin server is authoritative (Section 10.1). For TCP 
connections without TLS, this depends on the host having resolved to the same 
IP address.

For https resources, connection reuse additionally depends on having a 
certificate that is valid for the host in the URI. The certificate presented by 
the server MUST satisfy any checks that the client would perform when forming a 
new TLS connection for the host in the URI.

An origin server might offer a certificate with multiple subjectAltName 
attributes or names with wildcards, one of which is valid for the authority in 
the URI. For example, a certificate with a subjectAltName of *.example.com 
might permit the use of the same connection for requests to URIs starting with 
https://a.example.com/ and https://b.example.com/.

{code}


RFC 7540, HTTP/2 allow connection reuse depends on having a certificate that is 
valid for the host in the URI.
But RFC 6066, Only allow connection reuse depends on having a same SNI for the 
host in the URI.


> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both", 
> which compares IP address, port, and FQDN when determining whether a 
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a 
> reverse proxy.  The compared value is the origin server FQDN after mapping, 
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS 
> will attempt to reuse a connection that may have an SNI Host that does not 
> match the HTTP Host.  With Apache 2.4 origin servers this results in 400 Bad 
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see 
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of 
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is 
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when 
> determining if reuse of server session is allowed (when 
> server_session_sharing.match is set to "host" or "both").



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

[James Fang (JIRA)]

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

James Fang commented on TS-4334:


should we change :

cond %{SEND_RESPONSE_HDR_HOOK}
cond %{STATUS} =200
set-status 206

to 

cond %{SEND_RESPONSE_HDR_HOOK}
cond %{CLIENT-HEADER:@Original-Range} [NOT,AND]
cond %{STATUS} =200
set-status 206

to avoid changing status for no range request ?

> The cache_range_requests plugin always attempts to modify the cache key.
> 
>
> Key: TS-4334
> URL: https://issues.apache.org/jira/browse/TS-4334
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>
> A TrafficServer administrator should be able to specify whether or not the 
> cache_range_requests plugin should modify the cache key.  The cache key may 
> be modified by a previous plugin in a plugin chain and there is no way to 
> configure cache_range_requests not to do any further modifications to the 
> cache key.  Having multiple plugins responsible for cache key modifications 
> can cause unexpected behavior, especially when a plugin chain ordering is 
> changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

[James Fang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Fang updated TS-4334:
---
Comment: was deleted

(was: cache_range_local.config  will change a 200 status to 206, so we may need 
add another condition:

cond %{SEND_RESPONSE_HDR_HOOK}
cond %{CLIENT-HEADER:Range} AND # only match range request
cond %{STATUS} =200
set-status 206
)

> The cache_range_requests plugin always attempts to modify the cache key.
> 
>
> Key: TS-4334
> URL: https://issues.apache.org/jira/browse/TS-4334
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>
> A TrafficServer administrator should be able to specify whether or not the 
> cache_range_requests plugin should modify the cache key.  The cache key may 
> be modified by a previous plugin in a plugin chain and there is no way to 
> configure cache_range_requests not to do any further modifications to the 
> cache key.  Having multiple plugins responsible for cache key modifications 
> can cause unexpected behavior, especially when a plugin chain ordering is 
> changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4334) The cache_range_requests plugin always attempts to modify the cache key.

[James Fang (JIRA)]

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

James Fang commented on TS-4334:


cache_range_local.config  will change a 200 status to 206, so we may need add 
another condition:

cond %{SEND_RESPONSE_HDR_HOOK}
cond %{CLIENT-HEADER:Range} AND # only match range request
cond %{STATUS} =200
set-status 206


> The cache_range_requests plugin always attempts to modify the cache key.
> 
>
> Key: TS-4334
> URL: https://issues.apache.org/jira/browse/TS-4334
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Nolan Astrein
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
>
> A TrafficServer administrator should be able to specify whether or not the 
> cache_range_requests plugin should modify the cache key.  The cache key may 
> be modified by a previous plugin in a plugin chain and there is no way to 
> configure cache_range_requests not to do any further modifications to the 
> cache key.  Having multiple plugins responsible for cache key modifications 
> can cause unexpected behavior, especially when a plugin chain ordering is 
> changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4884) Remove a few unused variables/define in EThread

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4884?focusedWorklogId=29432=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-29432
 ]

ASF GitHub Bot logged work on TS-4884:
--

Author: ASF GitHub Bot
Created on: 21/Sep/16 09:26
Start Date: 21/Sep/16 09:26
Worklog Time Spent: 10m 
  Work Description: GitHub user mgosui opened a pull request:

https://github.com/apache/trafficserver/pull/1038

TS-4884: Remove a few unused variables/define in EThread

[TS-4884](https://issues.apache.org/jira/browse/TS-4884)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mgosui/trafficserver ts-4884

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1038.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1038


commit ba5c4a78699ce83a2327361b72532014ef274e0e
Author: Masato Gosui 
Date:   2016-09-21T09:24:41Z

TS-4884: Remove a few unused variables/define in EThread




Issue Time Tracking
---

Worklog Id: (was: 29432)
Time Spent: 10m
Remaining Estimate: 0h

> Remove a few unused variables/define in EThread
> ---
>
> Key: TS-4884
> URL: https://issues.apache.org/jira/browse/TS-4884
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Masato Gosui
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> EThread has variable accept_event and main_accept_index, which are unused.
> Also MAX_ACCEPT_EVENTS is not used other than the declaration of accept_event.
> We should be able to remove them without any side effects.
> Looks like these are remnants of old code cleanup.
> https://github.com/apache/trafficserver/commit/0a0c90dd94fd53a0cf9617f945e4e7d9fe42c7a9



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #1038: TS-4884: Remove a few unused variables/def...

[mgosui]

GitHub user mgosui opened a pull request:

https://github.com/apache/trafficserver/pull/1038

TS-4884: Remove a few unused variables/define in EThread

[TS-4884](https://issues.apache.org/jira/browse/TS-4884)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mgosui/trafficserver ts-4884

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/1038.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1038


commit ba5c4a78699ce83a2327361b72532014ef274e0e
Author: Masato Gosui 
Date:   2016-09-21T09:24:41Z

TS-4884: Remove a few unused variables/define in EThread




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (TS-4884) Remove a few unused variables/define in EThread

[Masato Gosui (JIRA)]

Masato Gosui created TS-4884:


 Summary: Remove a few unused variables/define in EThread
 Key: TS-4884
 URL: https://issues.apache.org/jira/browse/TS-4884
 Project: Traffic Server
  Issue Type: Improvement
  Components: Core
Reporter: Masato Gosui


EThread has variable accept_event and main_accept_index, which are unused.
Also MAX_ACCEPT_EVENTS is not used other than the declaration of accept_event.
We should be able to remove them without any side effects.

Looks like these are remnants of old code cleanup.
https://github.com/apache/trafficserver/commit/0a0c90dd94fd53a0cf9617f945e4e7d9fe42c7a9



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)