[jira] [Closed] (TS-5094) URL encoding required in the redirect pages of 5.3

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz closed TS-5094.
-
Resolution: Fixed

> URL encoding required in the redirect pages of 5.3
> --
>
> Key: TS-5094
> URL: https://issues.apache.org/jira/browse/TS-5094
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Syeda Persia Aziz
>Assignee: Syeda Persia Aziz
> Fix For: 5.3.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> replace psh by epsh 



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

[jira] [Assigned] (TS-5109) Wiretrace log for http/2

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz reassigned TS-5109:
-

Assignee: Syeda Persia Aziz

> Wiretrace log for http/2
> 
>
> Key: TS-5109
> URL: https://issues.apache.org/jira/browse/TS-5109
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Syeda Persia Aziz
>Assignee: Syeda Persia Aziz
>
> The wire-trace log does not print any client side HTTP/2 data (request / 
> response) in the trace blocks. Uncached requests/response can be retrieved 
> from the ats<->origin side but cached ones are impossible to retrieve



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

[jira] [Created] (TS-5109) Wiretrace log for http/2

[Syeda Persia Aziz (JIRA)]

Syeda Persia Aziz created TS-5109:
-

 Summary: Wiretrace log for http/2
 Key: TS-5109
 URL: https://issues.apache.org/jira/browse/TS-5109
 Project: Traffic Server
  Issue Type: Bug
Reporter: Syeda Persia Aziz


The wire-trace log does not print any client side HTTP/2 data (request / 
response) in the trace blocks. Uncached requests/response can be retrieved from 
the ats<->origin side but cached ones are impossible to retrieve



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

[jira] [Commented] (TS-3111) TS-2985 is not fixed on Centos 6.5

[Syeda Persia Aziz (JIRA)]

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

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

Is this issue still present?

> TS-2985 is not fixed on Centos 6.5
> --
>
> Key: TS-3111
> URL: https://issues.apache.org/jira/browse/TS-3111
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Affects Versions: 5.2.0
> Environment: Centos 6.5
>Reporter: Cristi
>Assignee: Syeda Persia Aziz
> Fix For: sometime
>
>
> When configuring with multiple ip-in:ip-out, traffic manager is binding on 
> the specified ip/ports, but does not send anything to traffic_server.
> Tested using:
> Apache Traffic Server - traffic_server - 5.2.0 - (build # 9221 on Oct  2 2014 
> at 21:58:43)
> I think https://issues.apache.org/jira/browse/TS-2985 is not fixed on Centos.
> If I start just traffic_server, everything works fine.



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

[jira] [Assigned] (TS-4524) add unique session ID

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz reassigned TS-4524:
-

Assignee: Syeda Persia Aziz

> add unique session ID
> -
>
> Key: TS-4524
> URL: https://issues.apache.org/jira/browse/TS-4524
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
> Fix For: sometime
>
>
> Since transactions have a unique ID for tracking, {{TSHttpTxnIdGet()}}, it 
> would be convenient to have the same facility for sessions. We should also 
> use this in session-based logs for each protocol.



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

[jira] [Assigned] (TS-4643) Different SSL Options for Origin and Client

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz reassigned TS-4643:
-

Assignee: Syeda Persia Aziz

> Different SSL Options for Origin and Client
> ---
>
> Key: TS-4643
> URL: https://issues.apache.org/jira/browse/TS-4643
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Adi
>Assignee: Syeda Persia Aziz
> Fix For: sometime
>
>
> Currently the setting 
> CONFIG proxy.config.ssl.TLSv1 affects connections from browser to server and 
> server to origin.
> This has to be split to two configuration parameters ideally to differentiate
> Browser to Server and Server to Origin



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

[jira] [Assigned] (TS-4493) Add tests of chunked responses in HTTP/2

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz reassigned TS-4493:
-

Assignee: Syeda Persia Aziz

> Add tests of chunked responses in HTTP/2
> 
>
> Key: TS-4493
> URL: https://issues.apache.org/jira/browse/TS-4493
> Project: Traffic Server
>  Issue Type: Test
>  Components: HTTP/2, Tests
>Reporter: Masaori Koshiba
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>
> We see many bugs around chunked response in HTTP/2. To avoid regressions we 
> needs tests in TSQA.



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

[jira] [Updated] (TS-5094) URL encoding required in the redirect pages of 5.3

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-5094:
--
Fix Version/s: 5.3.3

> URL encoding required in the redirect pages of 5.3
> --
>
> Key: TS-5094
> URL: https://issues.apache.org/jira/browse/TS-5094
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Syeda Persia Aziz
>Assignee: Syeda Persia Aziz
> Fix For: 5.3.3
>
>
> replace psh by epsh 



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

[jira] [Assigned] (TS-5094) URL encoding required in the redirect pages of 5.3

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz reassigned TS-5094:
-

Assignee: Syeda Persia Aziz

> URL encoding required in the redirect pages of 5.3
> --
>
> Key: TS-5094
> URL: https://issues.apache.org/jira/browse/TS-5094
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Syeda Persia Aziz
>Assignee: Syeda Persia Aziz
>
> replace psh by epsh 



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

[jira] [Created] (TS-5094) URL encoding required in the redirect pages of 5.3

[Syeda Persia Aziz (JIRA)]

Syeda Persia Aziz created TS-5094:
-

 Summary: URL encoding required in the redirect pages of 5.3
 Key: TS-5094
 URL: https://issues.apache.org/jira/browse/TS-5094
 Project: Traffic Server
  Issue Type: Bug
Reporter: Syeda Persia Aziz


replace psh by epsh 



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

[jira] [Commented] (TS-1257) Replace Tcl_Hash* with lib/ts/Map

[Syeda Persia Aziz (JIRA)]

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

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

>From the description of this issue, we need to decide whether we want to 
>replace the underlying implementation of InkHashTable or we want to replace it 
>totally by Map. Is this still under discussion? [~amc] [~zwoop] [~i.galic]

> Replace Tcl_Hash* with lib/ts/Map
> -
>
> Key: TS-1257
> URL: https://issues.apache.org/jira/browse/TS-1257
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup, Core
>Reporter: Igor Galić
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>
> We have our own implementation of maps that we use in most new code. We have 
> already discussed looking into removing the old Tcl cruft by replacing it 
> with {{Map}}, but have neither followed up on the ML nor Jira - or in the 
> code ;)
> This ticket is a reminder that this task exists and wants to be done!
> As to whether we simply replace the Tcl Implementation underneath, or visibly 
> to all developers, replace {{InkHashTable}} with {{Map}}, remains to be 
> discussed/decided/evaluated.



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

[jira] [Commented] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc

[Syeda Persia Aziz (JIRA)]

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

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

ah, I forgot that I have an account. However, I have a PR for this one 

> CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE) in 
> iocore/net/SSLConfig.cc
> 
>
> Key: TS-4978
> URL: https://issues.apache.org/jira/browse/TS-4978
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TLS
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I think this is perhaps from TS-4858:
> {code}
> *** CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
> /iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
> 252   ats_free(ssl_server_ca_cert_filename);
> 253   ats_free(CACertRelativePath);
> 254 
> 255 #if HAVE_OPENSSL_SESSION_TICKETS
> 256   REC_ReadConfigStringAlloc(ticket_key_filename, 
> "proxy.config.ssl.server.ticket_key.filename");
> 257   if (this->ticket_key_filename != NULL) {
>CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
>Passing freed pointer "this->ticket_key_filename" as an argument to 
> "relative_to".
> 258 ats_scoped_str 
> ticket_key_path(Layout::relative_to(this->serverCertPathOnly, 
> this->ticket_key_filename));
> 259 default_global_keyblock = 
> ssl_create_ticket_keyblock(ticket_key_path);
> 260   } else {
> 261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
> 262   }
> 263 #endif
> {code}



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

[jira] [Commented] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc

[Syeda Persia Aziz (JIRA)]

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

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

Does Coverity complain about other such type of members like cipherSuite, 
serverCACertFilename etc.?

> CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE) in 
> iocore/net/SSLConfig.cc
> 
>
> Key: TS-4978
> URL: https://issues.apache.org/jira/browse/TS-4978
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TLS
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>
> I think this is perhaps from TS-4858:
> {code}
> *** CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
> /iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
> 252   ats_free(ssl_server_ca_cert_filename);
> 253   ats_free(CACertRelativePath);
> 254 
> 255 #if HAVE_OPENSSL_SESSION_TICKETS
> 256   REC_ReadConfigStringAlloc(ticket_key_filename, 
> "proxy.config.ssl.server.ticket_key.filename");
> 257   if (this->ticket_key_filename != NULL) {
>CID 1364311:  Memory - illegal accesses  (USE_AFTER_FREE)
>Passing freed pointer "this->ticket_key_filename" as an argument to 
> "relative_to".
> 258 ats_scoped_str 
> ticket_key_path(Layout::relative_to(this->serverCertPathOnly, 
> this->ticket_key_filename));
> 259 default_global_keyblock = 
> ssl_create_ticket_keyblock(ticket_key_path);
> 260   } else {
> 261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
> 262   }
> 263 #endif
> {code}



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

[jira] [Created] (TS-4891) ATS-7.0.x giving segmentation fault

[Syeda Persia Aziz (JIRA)]

Syeda Persia Aziz created TS-4891:
-

 Summary: ATS-7.0.x giving segmentation fault
 Key: TS-4891
 URL: https://issues.apache.org/jira/browse/TS-4891
 Project: Traffic Server
  Issue Type: Bug
Reporter: Syeda Persia Aziz


The current 7.0.x branch is giving me segmentation fault as I run it. It 
happens when trying to elevate_fopen Diags.log. It fails and shoots an 
diags-error message which does not have any debug tag.

The trace and info can be found here: 

https://gist.github.com/persiaAziz/48a321a1c1913af1580261fa40d14df0



--
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] [Assigned] (TS-4858) Global session ticket key block leaks.

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz reassigned TS-4858:
-

Assignee: Syeda Persia Aziz

> Global session ticket key block leaks.
> --
>
> Key: TS-4858
> URL: https://issues.apache.org/jira/browse/TS-4858
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: James Peach
>Assignee: Syeda Persia Aziz
>
> From source inspection, ``global_default_keyblock`` is always assigned so it 
> will leak on configuration reload.
> Have not reproduced this since I wasn't able to get SSL config reload to work 
> :-(



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

[jira] [Created] (TS-4850) host specific error pages not showing up

[Syeda Persia Aziz (JIRA)]

Syeda Persia Aziz created TS-4850:
-

 Summary: host specific error pages not showing up
 Key: TS-4850
 URL: https://issues.apache.org/jira/browse/TS-4850
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Syeda Persia Aziz


BodyFactory should return host specific error pages when 
proxy.config.body_factory.enable_customizations is set to 3. The problem is the 
context parameter that is being passed to the lookup function 
"determine_set_by_host" contains NULL in the hostname field. Hence the default 
set is being returned. 



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

[jira] [Updated] (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:all-tabpanel
 ]

Syeda Persia Aziz updated TS-4819:
--
Description:  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  (was:  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)

> 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
>Reporter: Syeda Persia Aziz
> 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] [Updated] (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:all-tabpanel
 ]

Syeda Persia Aziz updated TS-4819:
--
Description:  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  (was:  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.  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)

> 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
>Reporter: Syeda Persia Aziz
> 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] [Updated] (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:all-tabpanel
 ]

Syeda Persia Aziz updated TS-4819:
--
Attachment: test_post.py

> 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
>Reporter: Syeda Persia Aziz
> 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.  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=15468821#comment-15468821
 ] 

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

## Test program
import gevent
import socket
import requests
import os
from threading import Thread
import sys
bSTOP = False
def handleResponse(response,*args, **kwargs):
print(response.status_code)

def gen():
yield 'pforpersia,champaignurbana'.encode('utf-8')
yield 'there'.encode('utf-8')

def txn_replay():
try:
request_session = requests.Session()
hostname = "127.0.0.1"
port = "8080"
request_session.proxies =  {"http": "http://{0}:{1}".format(hostname, 
port)}
hdr = {'content-type': 'application/json', 'User-Agent': 'YMobile/1.0 
(com.yahoo.mobile.client.android.mail/5.7.1; Android/6.0.1; MMB29K; zenltetmo; 
samsung; SM-G928T; 5.0; 2560x1440;)'
, 'Content-MD5':'5f4308e950ab4d7188e96ddf740855ec', 'Content-Length':'20'}
response = request_session.post('http://blabla.com/blabla', 
headers=hdr, stream=True, data=gen())
except UnicodeEncodeError as e:
print("UnicodeEncodeError exception")

except requests.exceptions.ContentDecodingError as e:
print("ContentDecodingError",e)
except:
e=sys.exc_info()
print("ERROR in requests: ",e)

def main():
txn_replay()

if __name__ == '__main__':
main()

> 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
>Reporter: Syeda Persia Aziz
>
>  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. This problem can be reproduced using the python 
> file 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] [Issue Comment Deleted] (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:all-tabpanel
 ]

Syeda Persia Aziz updated TS-4819:
--
Comment: was deleted

(was: ## Test program
import gevent
import socket
import requests
import os
from threading import Thread
import sys
bSTOP = False
def handleResponse(response,*args, **kwargs):
print(response.status_code)

def gen():
yield 'pforpersia,champaignurbana'.encode('utf-8')
yield 'there'.encode('utf-8')

def txn_replay():
try:
request_session = requests.Session()
hostname = "127.0.0.1"
port = "8080"
request_session.proxies =  {"http": "http://{0}:{1}".format(hostname, 
port)}
hdr = {'content-type': 'application/json', 'User-Agent': 'YMobile/1.0 
(com.yahoo.mobile.client.android.mail/5.7.1; Android/6.0.1; MMB29K; zenltetmo; 
samsung; SM-G928T; 5.0; 2560x1440;)'
, 'Content-MD5':'5f4308e950ab4d7188e96ddf740855ec', 'Content-Length':'20'}
response = request_session.post('http://blabla.com/blabla', 
headers=hdr, stream=True, data=gen())
except UnicodeEncodeError as e:
print("UnicodeEncodeError exception")

except requests.exceptions.ContentDecodingError as e:
print("ContentDecodingError",e)
except:
e=sys.exc_info()
print("ERROR in requests: ",e)

def main():
txn_replay()

if __name__ == '__main__':
main())

> 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
>Reporter: Syeda Persia Aziz
>
>  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. This problem can be reproduced using the python 
> file 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] [Updated] (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:all-tabpanel
 ]

Syeda Persia Aziz updated TS-4819:
--
Description:  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.  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  (was:  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. 
This problem can be reproduced using the python file 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)

> 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
>Reporter: Syeda Persia Aziz
>
>  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.  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=15468820#comment-15468820
 ] 

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

(gdb) bt
#0  0x0055a532 in ProxyClientTransaction::get_half_close_flag 
(this=0x7fffec27be40) at http/../ProxyClientTransaction.h:78
#1  0x005f3cdf in HttpSM::do_setup_post_tunnel (this=0x7fffd0cce1e0, 
to_vc_type=HTTP_SERVER_VC) at HttpSM.cc:5621
#2  0x005e5434 in HttpSM::state_send_server_request_header 
(this=0x7fffd0cce1e0, event=103, data=0x7fffb8018b90) at HttpSM.cc:1995
#3  0x005e7e00 in HttpSM::main_handler (this=0x7fffd0cce1e0, event=103, 
data=0x7fffb8018b90) at HttpSM.cc:2658
#4  0x005100f2 in Continuation::handleEvent (this=0x7fffd0cce1e0, 
event=103, data=0x7fffb8018b90) at ../iocore/eventsystem/I_Continuation.h:153
#5  0x00799b17 in write_signal_and_update (event=103, 
vc=0x7fffb8018a00) at UnixNetVConnection.cc:184
#6  0x00799d22 in write_signal_done (event=103, nh=0x74ecdcd0, 
vc=0x7fffb8018a00) at UnixNetVConnection.cc:226
#7  0x0079b19e in write_to_net_io (nh=0x74ecdcd0, 
vc=0x7fffb8018a00, thread=0x74eca010) at UnixNetVConnection.cc:566
#8  0x0079a91d in write_to_net (nh=0x74ecdcd0, vc=0x7fffb8018a00, 
thread=0x74eca010) at UnixNetVConnection.cc:423
#9  0x00791802 in NetHandler::mainNetEvent (this=0x74ecdcd0, 
event=5, e=0x1192d00) at UnixNet.cc:530
#10 0x005100f2 in Continuation::handleEvent (this=0x74ecdcd0, 
event=5, data=0x1192d00) at ../iocore/eventsystem/I_Continuation.h:153
#11 0x007bd88b in EThread::process_event (this=0x74eca010, 
e=0x1192d00, calling_code=5) at UnixEThread.cc:148
#12 0x007bde8e in EThread::execute (this=0x74eca010) at 
UnixEThread.cc:275
#13 0x007bce30 in spawn_thread_internal (a=0x114bab0) at Thread.cc:86
#14 0x76a5c6fa in start_thread (arg=0x74ac5700) at 
pthread_create.c:333
#15 0x75cedb5d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109


> 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
>Reporter: Syeda Persia Aziz
>
>  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. This problem can be reproduced using the python 
> file 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] [Created] (TS-4819) ATS-6.2.x crashes if the message-body of a chunk is not correctly formatted

[Syeda Persia Aziz (JIRA)]

Syeda Persia Aziz created TS-4819:
-

 Summary: 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
Reporter: Syeda Persia Aziz


 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. This problem can be reproduced using the python file 
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-4263) Session tickets keys in ssl_multicert.config do not work with SNI discovered hosts

[Syeda Persia Aziz (JIRA)]

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

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

There is a config that can globally disable/enable session ticket. 

PR: https://github.com/apache/trafficserver/pull/758

However, I didn't remove the ticket_key_name option from the ssl_multicert 
config file. Should be an easy thing to do

> Session tickets keys in ssl_multicert.config do not work with SNI discovered 
> hosts
> --
>
> Key: TS-4263
> URL: https://issues.apache.org/jira/browse/TS-4263
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, SSL
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
>  Labels: A
> Fix For: 7.0.0
>
>
> If you have a ssl_multicert.config without dest_ip= rules, i.e. requiring SNI 
> negotiation to get a TLS session, then you can not configure the session 
> ticket keys block, at all. Meaning, there's no way to share the keys across 
> more than one machine.
> I went down a bit of a rathole trying to fix this, but it's somewhat ugly. At 
> the point of resuming a session, the SSL call back provides the 16 byte 
> key-name, but the SNI name is seemingly not available at this point.
> A possible solution is to change the lookups to always be on the 16-byte 
> key-name, and keep a separate lookup table for the key blocks. This is in 
> itself a little ugly, because the ownerships around SSLCertContext is a 
> little murky. But it seems the cleanest, and definitely seemed to have been 
> the intent from OpenSSL's callback signature.
> Another option, which could not be done in the 6.x release cycle, is to 
> remove the ticket_key_name= option from ssl_multicert.config entirely, and 
> only have a single, global key block configured via records.config.



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

[jira] [Created] (TS-4604) The page on "configuring traffic server" needs correction

[Syeda Persia Aziz (JIRA)]

Syeda Persia Aziz created TS-4604:
-

 Summary: The page on "configuring traffic server" needs correction
 Key: TS-4604
 URL: https://issues.apache.org/jira/browse/TS-4604
 Project: Traffic Server
  Issue Type: Bug
  Components: Documentation
Reporter: Syeda Persia Aziz



https://docs.trafficserver.apache.org/en/latest/admin-guide/configuring-traffic-server.en.html?highlight=traffic_config

"traffic_config" does not exist. Also this page talks about traffic line but 
the examples use traffic_ctl, which looks confusing.



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

[jira] [Updated] (TS-3371) Should create a global session ticket disable

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-3371:
--
Description: 
The current implementation requires the ATS to set the ssl_ticket_enabled=0 for 
every entry in ssl_multicert.config to turn off the ssl ticket session support.

It would be better to have a global switch.  It seems highly unlikely that 
someone will want to deploy ssl tickets for some destinations but not others.

Would also be good to have a switch to disable ATS from offering session 
tickets when communicating with origin servers.

  was:
The current implementation requires the user to set the ssl_ticket_enabled=0 
for every entry in ssl_multiserver.config to turn off the ssl ticket session 
support.

It would be better to have a global switch.  It seems highly unlikely that 
someone will want to deploy ssl tickets for some destinations but not others.

Would also be good to have a switch to disable ATS from offering session 
tickets when communicating with origin servers.


> Should create a global session ticket disable
> -
>
> Key: TS-3371
> URL: https://issues.apache.org/jira/browse/TS-3371
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Syeda Persia Aziz
> Fix For: sometime
>
>
> The current implementation requires the ATS to set the ssl_ticket_enabled=0 
> for every entry in ssl_multicert.config to turn off the ssl ticket session 
> support.
> It would be better to have a global switch.  It seems highly unlikely that 
> someone will want to deploy ssl tickets for some destinations but not others.
> Would also be good to have a switch to disable ATS from offering session 
> tickets when communicating with origin servers.



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

[jira] [Updated] (TS-3831) Overridable error response type

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-3831:
--
Description: 
ATS has a set of error pages in the folder body_factory, namely access#denied, 
access#proxy_auth_required,connect#dns_failed... etc. All these error pages are 
loaded in a RawHashTable. When there is an error for e.g. access denied,  ATS 
builds a error response of type access#denied. We can have an overridable 
config that will decide which custom error page to send to the client. This 
config will be set per remap rule. We can have the custom error pages in the 
body_factory folder and these pages will follow a specific naming convention 
for e.g. $var_access#denied, $var_access#proxy_auth_required, ….. Here $var is 
the overridable config (proxy.config.error.response.type). 

Example: 
in Remap.config

map www.abcxyz.com www.efgijk.com @plugin=config.so 
@pparam=proxy.config.error.response.type=yahoo

Now, if there is for e.g. a 'access denied' error, the build_error_response 
will build a customized error response of type yahoo_access#denied . If it can 
not find the type yahoo_access#denied, then it will simply build the default 
access#denied error response. 

Note: I already have a patch for this.

  was:
ATS has a set of error pages in the folder body_factory, namely access#denied, 
access#proxy_auth_required,connect#dns_failed... etc. All these error pages are 
loaded in a RawHashTable. When there is an error for e.g. access denied,  ATS 
builds a error response of type access#denied. We can have an overridable 
config that will decide which custom error page to send to the client. This 
config will be set per remap rule. We can have the custom error pages in the 
body_factory folder and these pages will follow a specific naming convention 
for e.g. $var_access#denied, $var_proxy_auth_required, ….. Here $var is the 
overridable config (proxy.config.error.response.type). 

Example: 
in Remap.config

map www.abcxyz.com www.efgijk.com @plugin=config.so 
@pparam=proxy.config.error.response.type=yahoo

Now, if there is for e.g. a 'access denied' error, the build_error_response 
will build a customized error response of type yahoo_access#denied . If it can 
not find the type yahoo_access#denied, then it will simply build the default 
access#denied error response. 

Note: I already have a patch for this.


 Overridable error response type
 ---

 Key: TS-3831
 URL: https://issues.apache.org/jira/browse/TS-3831
 Project: Traffic Server
  Issue Type: New Feature
  Components: Configuration
Reporter: Syeda Persia Aziz

 ATS has a set of error pages in the folder body_factory, namely 
 access#denied, access#proxy_auth_required,connect#dns_failed... etc. All 
 these error pages are loaded in a RawHashTable. When there is an error for 
 e.g. access denied,  ATS builds a error response of type access#denied. We 
 can have an overridable config that will decide which custom error page to 
 send to the client. This config will be set per remap rule. We can have the 
 custom error pages in the body_factory folder and these pages will follow a 
 specific naming convention for e.g. $var_access#denied, 
 $var_access#proxy_auth_required, ….. Here $var is the overridable config 
 (proxy.config.error.response.type). 
 Example: 
 in Remap.config
 map www.abcxyz.com www.efgijk.com @plugin=config.so 
 @pparam=proxy.config.error.response.type=yahoo
 Now, if there is for e.g. a 'access denied' error, the build_error_response 
 will build a customized error response of type yahoo_access#denied . If it 
 can not find the type yahoo_access#denied, then it will simply build the 
 default access#denied error response. 
 Note: I already have a patch for this.



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

[jira] [Updated] (TS-3831) Overridable error response type

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-3831:
--
Description: 
ATS has a set of error pages in the folder body_factory, namely 
access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... 
etc. All these error pages are loaded in a RawHashTable. When there is an error 
for e.g. access denied,  ATS builds a error response of type access#denied. We 
can have an overridable config that will decide which custom error page to send 
to the client. This config will be set per remap rule. We can have the custom 
error pages in the body_factory folder and these pages will follow a specific 
naming convention for e.g. $var_access#denied.html, 
$var_proxy_auth_required.html, ….. Here $var is the overridable config 
(proxy.config.error.response.type). 

Example: 
in Remap.config

map www.abcxyz.com www.efgijk.com @plugin=config.so 
@pparam=proxy.config.error.response.type=yahoo

Now, if there is for e.g. a 'access denied' error, the build_error_response 
will build a customized error response of type yahoo_access#denied . If it can 
not find the type yahoo_access#denied, then it will simply build the default 
access#denied error response. 

Note: I already have a patch for this. I am thinking of test cases.

  was:
ATS has a set of error pages in the folder body_factory, namely 
access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... 
etc. All these error pages are loaded in a RawHashTable. When there is an error 
for e.g. access denied,  ATS builds a error response of type access#denied. We 
can have an overridable config that will decide which custom error page to send 
to the client. This config will be set per remap rule. We can have the custom 
error pages in the body_factory folder and these pages will follow a specific 
naming convention for e.g. $var_access#denied.html, 
$var_proxy_auth_required.html, ….. Here $var is the overridable config 
(proxy.config.error.response.type). 

Example: 
in Remap.config

map www.abcxyz.com www.efgijk.com @plugin=config.so 
@pparam=proxy.config.error.response.type=yahoo

Now, if there is for e.g. a 'access denied' error, the build_error_response 
will build a customized error response of type yahoo_access#denied . If it can 
not find the type yahoo_access#denied, then it will simply build the default 
access#denied error response. 

I already have a patch for this


 Overridable error response type
 ---

 Key: TS-3831
 URL: https://issues.apache.org/jira/browse/TS-3831
 Project: Traffic Server
  Issue Type: New Feature
  Components: Configuration
Reporter: Syeda Persia Aziz

 ATS has a set of error pages in the folder body_factory, namely 
 access#denied.html, 
 access#proxy_auth_required.html,connect#dns_failed.html... etc. All these 
 error pages are loaded in a RawHashTable. When there is an error for e.g. 
 access denied,  ATS builds a error response of type access#denied. We can 
 have an overridable config that will decide which custom error page to send 
 to the client. This config will be set per remap rule. We can have the custom 
 error pages in the body_factory folder and these pages will follow a specific 
 naming convention for e.g. $var_access#denied.html, 
 $var_proxy_auth_required.html, ….. Here $var is the overridable config 
 (proxy.config.error.response.type). 
 Example: 
 in Remap.config
 map www.abcxyz.com www.efgijk.com @plugin=config.so 
 @pparam=proxy.config.error.response.type=yahoo
 Now, if there is for e.g. a 'access denied' error, the build_error_response 
 will build a customized error response of type yahoo_access#denied . If it 
 can not find the type yahoo_access#denied, then it will simply build the 
 default access#denied error response. 
 Note: I already have a patch for this. I am thinking of test cases.



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

[jira] [Updated] (TS-3831) Overridable error response type

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-3831:
--
Description: 
ATS has a set of error pages in the folder body_factory, namely 
access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... 
etc. All these error pages are loaded in a RawHashTable. When there is an error 
for e.g. access denied,  ATS builds a error response of type access#denied. We 
can have an overridable config that will decide which custom error page to send 
to the client. This config will be set per remap rule. We can have the custom 
error pages in the body_factory folder and these pages will follow a specific 
naming convention for e.g. $var_access#denied.html, 
$var_proxy_auth_required.html, ….. Here $var is the overridable config 
(proxy.config.error.response.type). 

Example: 
in Remap.config

map www.abcxyz.com www.efgijk.com @plugin=config.so 
@pparam=proxy.config.error.response.type=yahoo

Now, if there is for e.g. a 'access denied' error, the build_error_response 
will build a customized error response of type yahoo_access#denied . If it can 
not find the type yahoo_access#denied, then it will simply build the default 
access#denied error response. 

I already have a patch for this

  was:
ATS has a set of error pages in the folder body_factory, namely 
access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... 
etc. All these error pages are loaded in a RawHashTable. When there is an error 
for e.g. access denied,  ATS builds a error response of type access#denied. We 
can have an overridable config that will decide which custom error page to send 
to the client. This config will be set per remap rule. We can have the custom 
error pages in the body_factory folder and these pages will follow a specific 
naming convention for e.g. $var_access#denied.html, 
$var_proxy_auth_required.html, ….. Here $var is the overridable config 
(proxy.config.error.response.type). 

Example: 
in Remap.config

map www.abcxyz.com www.efgijk.com @plugin=config.so 
@pparam=proxy.config.error.response.type=yahoo

Now, if there is for e.g. a 'access denied' error, the build_error_response 
will build a customized error response of type yahoo_access#denied . If it can 
not find the type yahoo_access#denied, then it will simply build the default 
access#denied error response. 


 Overridable error response type
 ---

 Key: TS-3831
 URL: https://issues.apache.org/jira/browse/TS-3831
 Project: Traffic Server
  Issue Type: New Feature
  Components: Configuration
Reporter: Syeda Persia Aziz

 ATS has a set of error pages in the folder body_factory, namely 
 access#denied.html, 
 access#proxy_auth_required.html,connect#dns_failed.html... etc. All these 
 error pages are loaded in a RawHashTable. When there is an error for e.g. 
 access denied,  ATS builds a error response of type access#denied. We can 
 have an overridable config that will decide which custom error page to send 
 to the client. This config will be set per remap rule. We can have the custom 
 error pages in the body_factory folder and these pages will follow a specific 
 naming convention for e.g. $var_access#denied.html, 
 $var_proxy_auth_required.html, ….. Here $var is the overridable config 
 (proxy.config.error.response.type). 
 Example: 
 in Remap.config
 map www.abcxyz.com www.efgijk.com @plugin=config.so 
 @pparam=proxy.config.error.response.type=yahoo
 Now, if there is for e.g. a 'access denied' error, the build_error_response 
 will build a customized error response of type yahoo_access#denied . If it 
 can not find the type yahoo_access#denied, then it will simply build the 
 default access#denied error response. 
 I already have a patch for this



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

[jira] [Updated] (TS-3831) Overridable error response type

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-3831:
--
Description: 
ATS has a set of error pages in the folder body_factory, namely access#denied, 
access#proxy_auth_required,connect#dns_failed... etc. All these error pages are 
loaded in a RawHashTable. When there is an error for e.g. access denied,  ATS 
builds a error response of type access#denied. We can have an overridable 
config that will decide which custom error page to send to the client. This 
config will be set per remap rule. We can have the custom error pages in the 
body_factory folder and these pages will follow a specific naming convention 
for e.g. $var_access#denied, $var_proxy_auth_required, ….. Here $var is the 
overridable config (proxy.config.error.response.type). 

Example: 
in Remap.config

map www.abcxyz.com www.efgijk.com @plugin=config.so 
@pparam=proxy.config.error.response.type=yahoo

Now, if there is for e.g. a 'access denied' error, the build_error_response 
will build a customized error response of type yahoo_access#denied . If it can 
not find the type yahoo_access#denied, then it will simply build the default 
access#denied error response. 

Note: I already have a patch for this. I am thinking of test cases.

  was:
ATS has a set of error pages in the folder body_factory, namely 
access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... 
etc. All these error pages are loaded in a RawHashTable. When there is an error 
for e.g. access denied,  ATS builds a error response of type access#denied. We 
can have an overridable config that will decide which custom error page to send 
to the client. This config will be set per remap rule. We can have the custom 
error pages in the body_factory folder and these pages will follow a specific 
naming convention for e.g. $var_access#denied.html, 
$var_proxy_auth_required.html, ….. Here $var is the overridable config 
(proxy.config.error.response.type). 

Example: 
in Remap.config

map www.abcxyz.com www.efgijk.com @plugin=config.so 
@pparam=proxy.config.error.response.type=yahoo

Now, if there is for e.g. a 'access denied' error, the build_error_response 
will build a customized error response of type yahoo_access#denied . If it can 
not find the type yahoo_access#denied, then it will simply build the default 
access#denied error response. 

Note: I already have a patch for this. I am thinking of test cases.


 Overridable error response type
 ---

 Key: TS-3831
 URL: https://issues.apache.org/jira/browse/TS-3831
 Project: Traffic Server
  Issue Type: New Feature
  Components: Configuration
Reporter: Syeda Persia Aziz

 ATS has a set of error pages in the folder body_factory, namely 
 access#denied, access#proxy_auth_required,connect#dns_failed... etc. All 
 these error pages are loaded in a RawHashTable. When there is an error for 
 e.g. access denied,  ATS builds a error response of type access#denied. We 
 can have an overridable config that will decide which custom error page to 
 send to the client. This config will be set per remap rule. We can have the 
 custom error pages in the body_factory folder and these pages will follow a 
 specific naming convention for e.g. $var_access#denied, 
 $var_proxy_auth_required, ….. Here $var is the overridable config 
 (proxy.config.error.response.type). 
 Example: 
 in Remap.config
 map www.abcxyz.com www.efgijk.com @plugin=config.so 
 @pparam=proxy.config.error.response.type=yahoo
 Now, if there is for e.g. a 'access denied' error, the build_error_response 
 will build a customized error response of type yahoo_access#denied . If it 
 can not find the type yahoo_access#denied, then it will simply build the 
 default access#denied error response. 
 Note: I already have a patch for this. I am thinking of test cases.



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

[jira] [Updated] (TS-3831) Overridable error response type

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-3831:
--
Description: 
ATS has a set of error pages in the folder body_factory, namely access#denied, 
access#proxy_auth_required,connect#dns_failed... etc. All these error pages are 
loaded in a RawHashTable. When there is an error for e.g. access denied,  ATS 
builds a error response of type access#denied. We can have an overridable 
config that will decide which custom error page to send to the client. This 
config will be set per remap rule. We can have the custom error pages in the 
body_factory folder and these pages will follow a specific naming convention 
for e.g. $var_access#denied, $var_proxy_auth_required, ….. Here $var is the 
overridable config (proxy.config.error.response.type). 

Example: 
in Remap.config

map www.abcxyz.com www.efgijk.com @plugin=config.so 
@pparam=proxy.config.error.response.type=yahoo

Now, if there is for e.g. a 'access denied' error, the build_error_response 
will build a customized error response of type yahoo_access#denied . If it can 
not find the type yahoo_access#denied, then it will simply build the default 
access#denied error response. 

Note: I already have a patch for this.

  was:
ATS has a set of error pages in the folder body_factory, namely access#denied, 
access#proxy_auth_required,connect#dns_failed... etc. All these error pages are 
loaded in a RawHashTable. When there is an error for e.g. access denied,  ATS 
builds a error response of type access#denied. We can have an overridable 
config that will decide which custom error page to send to the client. This 
config will be set per remap rule. We can have the custom error pages in the 
body_factory folder and these pages will follow a specific naming convention 
for e.g. $var_access#denied, $var_proxy_auth_required, ….. Here $var is the 
overridable config (proxy.config.error.response.type). 

Example: 
in Remap.config

map www.abcxyz.com www.efgijk.com @plugin=config.so 
@pparam=proxy.config.error.response.type=yahoo

Now, if there is for e.g. a 'access denied' error, the build_error_response 
will build a customized error response of type yahoo_access#denied . If it can 
not find the type yahoo_access#denied, then it will simply build the default 
access#denied error response. 

Note: I already have a patch for this. I am thinking of test cases.


 Overridable error response type
 ---

 Key: TS-3831
 URL: https://issues.apache.org/jira/browse/TS-3831
 Project: Traffic Server
  Issue Type: New Feature
  Components: Configuration
Reporter: Syeda Persia Aziz

 ATS has a set of error pages in the folder body_factory, namely 
 access#denied, access#proxy_auth_required,connect#dns_failed... etc. All 
 these error pages are loaded in a RawHashTable. When there is an error for 
 e.g. access denied,  ATS builds a error response of type access#denied. We 
 can have an overridable config that will decide which custom error page to 
 send to the client. This config will be set per remap rule. We can have the 
 custom error pages in the body_factory folder and these pages will follow a 
 specific naming convention for e.g. $var_access#denied, 
 $var_proxy_auth_required, ….. Here $var is the overridable config 
 (proxy.config.error.response.type). 
 Example: 
 in Remap.config
 map www.abcxyz.com www.efgijk.com @plugin=config.so 
 @pparam=proxy.config.error.response.type=yahoo
 Now, if there is for e.g. a 'access denied' error, the build_error_response 
 will build a customized error response of type yahoo_access#denied . If it 
 can not find the type yahoo_access#denied, then it will simply build the 
 default access#denied error response. 
 Note: I already have a patch for this.



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

[jira] [Created] (TS-3831) Overridable error response type

[Syeda Persia Aziz (JIRA)]

Syeda Persia Aziz created TS-3831:
-

 Summary: Overridable error response type
 Key: TS-3831
 URL: https://issues.apache.org/jira/browse/TS-3831
 Project: Traffic Server
  Issue Type: New Feature
  Components: Configuration
Reporter: Syeda Persia Aziz


ATS has a set of error pages in the folder body_factory, namely 
access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... 
etc. All these error pages are loaded in a RawHashTable. When there is an error 
for e.g. access denied,  ATS builds a error response of type access#denied. We 
can have an overridable config that will decide which custom error page to send 
to the client. This config will be set per remap rule. We can have the custom 
error pages in the body_factory folder and these pages will follow a specific 
naming convention for e.g. $var_access#denied.html, 
$var_proxy_auth_required.html, ….. Here $var is the overridable config 
(proxy.config.error.response.type). 

Example: 
in Remap.config

map www.abcxyz.com www.efgijk.com @plugin=config.so 
@pparam=proxy.config.error.response.type=yahoo

Now, if there is for e.g. a 'access denied' error, the build_error_response 
will build a customized error response of type yahoo_access#denied . If it can 
not find the type yahoo_access#denied, then it will simply build the default 
access#denied error response. 



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

[jira] [Commented] (TS-3746) We need to make proxy.config.ssl.client.verify.server overridable

[Syeda Persia Aziz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14622738#comment-14622738
 ] 

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

Yes, per transaction

 We need to make proxy.config.ssl.client.verify.server overridable
 -

 Key: TS-3746
 URL: https://issues.apache.org/jira/browse/TS-3746
 Project: Traffic Server
  Issue Type: New Feature
  Components: Configuration
Reporter: Syeda Persia Aziz
  Labels: Yahoo
 Fix For: sometime


 We need to make proxy.config.ssl.client.verify.server overridable. Some 
 origin servers need validation to avoid MITM attacks while others don't.



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

[jira] [Created] (TS-3746) We need to make proxy.config.ssl.client.verify.server overridable

[Syeda Persia Aziz (JIRA)]

Syeda Persia Aziz created TS-3746:
-

 Summary: We need to make proxy.config.ssl.client.verify.server 
overridable
 Key: TS-3746
 URL: https://issues.apache.org/jira/browse/TS-3746
 Project: Traffic Server
  Issue Type: New Feature
  Components: Configuration
Reporter: Syeda Persia Aziz


We need to make proxy.config.ssl.client.verify.server overridable. Some origin 
servers need validation to avoid MITM attacks while others don't.



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

[jira] [Updated] (TS-3746) We need to make proxy.config.ssl.client.verify.server overridable

[Syeda Persia Aziz (JIRA)]

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

Syeda Persia Aziz updated TS-3746:
--
Labels: Yahoo  (was: )

 We need to make proxy.config.ssl.client.verify.server overridable
 -

 Key: TS-3746
 URL: https://issues.apache.org/jira/browse/TS-3746
 Project: Traffic Server
  Issue Type: New Feature
  Components: Configuration
Reporter: Syeda Persia Aziz
  Labels: Yahoo

 We need to make proxy.config.ssl.client.verify.server overridable. Some 
 origin servers need validation to avoid MITM attacks while others don't.



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

[jira] [Commented] (TS-3136) Change default TLS cipher suites

[Syeda Persia Aziz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583688#comment-14583688
 ] 

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

I agree

 Change default TLS cipher suites
 

 Key: TS-3136
 URL: https://issues.apache.org/jira/browse/TS-3136
 Project: Traffic Server
  Issue Type: Improvement
  Components: Security, SSL
Reporter: Leif Hedstrom
Assignee: Syeda Persia Aziz
  Labels: compatibility
 Fix For: 6.0.0


 In TS-3135 [~i.galic] suggested:
 {quote}
 also, recommendations for a safer ciphersuite:
 SSLCipherSuite 
 ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
  
 from https://cipherli.st/
 {quote}
 [~jacksontj] had responded with:
 {quote}
 [~i.galic] That cipher quite is geared towards security, but doesn't support 
 quite a few older clients. I'd recommend we use the suite from mozilla 
 (https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations)
  which is a good mix of security and compatibility:
 {code}
 ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
 {code}
 {quote}



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