[jira] [Commented] (TS-1935) ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
[ https://issues.apache.org/jira/browse/TS-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942766#comment-13942766 ] Leif Hedstrom commented on TS-1935: --- I think for the 408's, we should only do it for the server closing the connection. For clients closing connection, I think it's fine not to log anything, or, alternatively log something similar to what we do now (000). > ERR_UNKNOWN/000 showing up 10.4% of the time in production logs > --- > > Key: TS-1935 > URL: https://issues.apache.org/jira/browse/TS-1935 > Project: Traffic Server > Issue Type: Bug >Reporter: Bryan Call > Fix For: 5.2.0 > > > Need to investigate in what conditions this happens. > * Keep-alive or not > * If any requests have happened on the connection > * Is the client or the server closing the connection at the time > * Verify no bytes have been sent from the client, looking at the code it > looks like it > Ideally if the client has not sent any bytes (has not attempted to make a > request) then we shouldn't log the error message. If it is possible a state > machine should not be created in this scenario. > related bug: > TS-1056 > related checkin: > 425e3d7dcb16b40075c7678e71d00b2fcb4b4705 > I also see this happening in on my forward proxy using Chrome: > [bcall@homer trafficserver]$ traffic_logcat -f squid.blog | grep 000 > 1370281253.174 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - > 1370281253.450 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - > 1370281253.891 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2653) SSL Error message cleanup
[
https://issues.apache.org/jira/browse/TS-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942695#comment-13942695
]
Bryan Call edited comment on TS-2653 at 3/21/14 2:38 AM:
-
Most of the error messages happen at line 1256 in s3_pkt.c:
{code}
/* Return up to 'len' payload bytes received in 'type' records.
* 'type' is one of the following:
*
* - SSL3_RT_HANDSHAKE (when ssl3_get_message calls us)
* - SSL3_RT_APPLICATION_DATA (when ssl3_read calls us)
* - 0 (during a shutdown, no data has to be returned)
*
* If we don't have stored data to work from, read a SSL/TLS record first
* (possibly multiple records if we still don't have anything to return).
*
* This function must handle any surprises the peer may have for us, such as
* Alert records (e.g. close_notify), ChangeCipherSpec records (not really
* a surprise, but handled as if it were), or renegotiation requests.
* Also if record payloads contain fragments too small to process, we store
* them until there is enough for the respective protocol (the record protocol
* may use arbitrary fragmentation and even interleaving):
* Change cipher spec protocol
* just 1 byte needed, no need for keeping anything stored
* Alert protocol
* 2 bytes needed (AlertLevel, AlertDescription)
* Handshake protocol
* 4 bytes needed (HandshakeType, uint24 length) -- we just have
* to detect unexpected Client Hello and Hello Request messages
* here, anything else is handled by higher layers
* Application data protocol
* none of our business
*/
int ssl3_read_bytes(SSL *s, int type, unsigned char *buf, int len, int peek)
...
else if (alert_level == 2) /* fatal */
{
char tmp[16];
s->rwstate=SSL_NOTHING;
s->s3->fatal_alert = alert_descr;
SSLerr(SSL_F_SSL3_READ_BYTES, SSL_AD_REASON_OFFSET +
alert_descr); <- this is line 1256
BIO_snprintf(tmp,sizeof tmp,"%d",alert_descr);
ERR_add_error_data(2,"SSL alert number ",tmp);
s->shutdown|=SSL_RECEIVED_SHUTDOWN;
SSL_CTX_remove_session(s->ctx,s->session);
return(0);
}
{code}
was (Author: bcall):
Most of the error messages happen at line 1256 in s3_pkt.c:
{code}
/* Return up to 'len' payload bytes received in 'type' records.
* 'type' is one of the following:
*
* - SSL3_RT_HANDSHAKE (when ssl3_get_message calls us)
* - SSL3_RT_APPLICATION_DATA (when ssl3_read calls us)
* - 0 (during a shutdown, no data has to be returned)
*
* If we don't have stored data to work from, read a SSL/TLS record first
* (possibly multiple records if we still don't have anything to return).
*
* This function must handle any surprises the peer may have for us, such as
* Alert records (e.g. close_notify), ChangeCipherSpec records (not really
* a surprise, but handled as if it were), or renegotiation requests.
* Also if record payloads contain fragments too small to process, we store
* them until there is enough for the respective protocol (the record protocol
* may use arbitrary fragmentation and even interleaving):
* Change cipher spec protocol
* just 1 byte needed, no need for keeping anything stored
* Alert protocol
* 2 bytes needed (AlertLevel, AlertDescription)
* Handshake protocol
* 4 bytes needed (HandshakeType, uint24 length) -- we just have
* to detect unexpected Client Hello and Hello Request messages
* here, anything else is handled by higher layers
* Application data protocol
* none of our business
*/
int ssl3_read_bytes(SSL *s, int type, unsigned char *buf, int len, int peek)
else if (alert_level == 2) /* fatal */
{
char tmp[16];
s->rwstate=SSL_NOTHING;
s->s3->fatal_alert = alert_descr;
SSLerr(SSL_F_SSL3_READ_BYTES, SSL_AD_REASON_OFFSET +
alert_descr); <- this is line 1256
BIO_snprintf(tmp,sizeof tmp,"%d",alert_descr);
ERR_add_error_data(2,"SSL alert number ",tmp);
s->shutdown|=SSL_RECEIVED_SHUTDOWN;
SSL_CTX_remove_session(s->ctx,s->session);
return(0);
}
{code}
> SSL Error message cleanup
> -
>
> Key: TS-2653
> URL: https://issues.apache.org/jira/browse/TS-2653
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, SSL
>Reporter: B
[jira] [Commented] (TS-2653) SSL Error message cleanup
[
https://issues.apache.org/jira/browse/TS-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942695#comment-13942695
]
Bryan Call commented on TS-2653:
Most of the error messages happen at line 1256 in s3_pkt.c:
{code}
/* Return up to 'len' payload bytes received in 'type' records.
* 'type' is one of the following:
*
* - SSL3_RT_HANDSHAKE (when ssl3_get_message calls us)
* - SSL3_RT_APPLICATION_DATA (when ssl3_read calls us)
* - 0 (during a shutdown, no data has to be returned)
*
* If we don't have stored data to work from, read a SSL/TLS record first
* (possibly multiple records if we still don't have anything to return).
*
* This function must handle any surprises the peer may have for us, such as
* Alert records (e.g. close_notify), ChangeCipherSpec records (not really
* a surprise, but handled as if it were), or renegotiation requests.
* Also if record payloads contain fragments too small to process, we store
* them until there is enough for the respective protocol (the record protocol
* may use arbitrary fragmentation and even interleaving):
* Change cipher spec protocol
* just 1 byte needed, no need for keeping anything stored
* Alert protocol
* 2 bytes needed (AlertLevel, AlertDescription)
* Handshake protocol
* 4 bytes needed (HandshakeType, uint24 length) -- we just have
* to detect unexpected Client Hello and Hello Request messages
* here, anything else is handled by higher layers
* Application data protocol
* none of our business
*/
int ssl3_read_bytes(SSL *s, int type, unsigned char *buf, int len, int peek)
else if (alert_level == 2) /* fatal */
{
char tmp[16];
s->rwstate=SSL_NOTHING;
s->s3->fatal_alert = alert_descr;
SSLerr(SSL_F_SSL3_READ_BYTES, SSL_AD_REASON_OFFSET +
alert_descr); <- this is line 1256
BIO_snprintf(tmp,sizeof tmp,"%d",alert_descr);
ERR_add_error_data(2,"SSL alert number ",tmp);
s->shutdown|=SSL_RECEIVED_SHUTDOWN;
SSL_CTX_remove_session(s->ctx,s->session);
return(0);
}
{code}
> SSL Error message cleanup
> -
>
> Key: TS-2653
> URL: https://issues.apache.org/jira/browse/TS-2653
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, SSL
>Reporter: Bryan Call
>
> We see a lot of SSL error messages in production. It would be good to
> determine if these are really errors or remove logging of some of these
> errors:
> {code}
> -bash-4.1$ tail -10 diags.log | cut -f4-20 -d : | grep SSL | sort | uniq
> -c | sort -rn
>3108 SSL::36:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3079 SSL::32:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3068 SSL::27:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3051 SSL::44:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3043 SSL::24:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3041 SSL::47:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3041 SSL::38:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3040 SSL::46:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3025 SSL::34:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3025 SSL::25:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3021 SSL::31:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3011 SSL::42:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3006 SSL::39:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3004 SSL::29:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>3000 SSL::30:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2996 SSL::43:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2993 SSL::45:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
>2977 SSL::40:error:140943E8:SSL
> routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL
[jira] [Created] (TS-2653) SSL Error message cleanup
Bryan Call created TS-2653:
--
Summary: SSL Error message cleanup
Key: TS-2653
URL: https://issues.apache.org/jira/browse/TS-2653
Project: Traffic Server
Issue Type: Bug
Components: Logging, SSL
Reporter: Bryan Call
We see a lot of SSL error messages in production. It would be good to
determine if these are really errors or remove logging of some of these errors:
{code}
-bash-4.1$ tail -10 diags.log | cut -f4-20 -d : | grep SSL | sort | uniq -c
| sort -rn
3108 SSL::36:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3079 SSL::32:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3068 SSL::27:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3051 SSL::44:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3043 SSL::24:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3041 SSL::47:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3041 SSL::38:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3040 SSL::46:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3025 SSL::34:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3025 SSL::25:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3021 SSL::31:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3011 SSL::42:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3006 SSL::39:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3004 SSL::29:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
3000 SSL::30:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
2996 SSL::43:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
2993 SSL::45:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
2977 SSL::40:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
2976 SSL::33:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
2974 SSL::41:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
2974 SSL::28:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
2958 SSL::37:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
2947 SSL::35:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
2922 SSL::26:error:140943E8:SSL
routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1256:SSL alert number 0
28 SSL::36:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
26 SSL::24:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
25 SSL::44:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
25 SSL::27:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
24 SSL::34:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
24 SSL::30:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
23 SSL::39:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
23 SSL::33:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
23 SSL::32:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
22 SSL::44:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
unknown ca:s3_pkt.c:1256:SSL alert number 48
21 SSL::38:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
20 SSL::45:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
20 SSL::41:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
20 SSL::28:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate expired:s3_pkt.c:1256:SSL alert number 45
19 SSL::42:error:14094415:S
[jira] [Comment Edited] (TS-1935) ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
[ https://issues.apache.org/jira/browse/TS-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942643#comment-13942643 ] Bryan Call edited comment on TS-1935 at 3/21/14 1:44 AM: - [~zwoop], Do you mean logging for the client or the server or both closing the connection? ERR_TIMEOUT/408 is a good error message if we are only going to log one and I think only logging the server closing the connection is the best thing to do. was (Author: bcall): [~zwoop], Do you mean logging for the client or the server or both close the connection? ERR_TIMEOUT/408 is a good error message if we are only going to log one and I think only logging the server closing the connection is the best thing to do. > ERR_UNKNOWN/000 showing up 10.4% of the time in production logs > --- > > Key: TS-1935 > URL: https://issues.apache.org/jira/browse/TS-1935 > Project: Traffic Server > Issue Type: Bug >Reporter: Bryan Call > Fix For: 5.2.0 > > > Need to investigate in what conditions this happens. > * Keep-alive or not > * If any requests have happened on the connection > * Is the client or the server closing the connection at the time > * Verify no bytes have been sent from the client, looking at the code it > looks like it > Ideally if the client has not sent any bytes (has not attempted to make a > request) then we shouldn't log the error message. If it is possible a state > machine should not be created in this scenario. > related bug: > TS-1056 > related checkin: > 425e3d7dcb16b40075c7678e71d00b2fcb4b4705 > I also see this happening in on my forward proxy using Chrome: > [bcall@homer trafficserver]$ traffic_logcat -f squid.blog | grep 000 > 1370281253.174 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - > 1370281253.450 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - > 1370281253.891 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1935) ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
[ https://issues.apache.org/jira/browse/TS-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942643#comment-13942643 ] Bryan Call commented on TS-1935: [~zwoop], Do you mean logging for the client or the server or both close the connection? ERR_TIMEOUT/408 is a good error message if we are only going to log one and I think only logging the server closing the connection is the best thing to do. > ERR_UNKNOWN/000 showing up 10.4% of the time in production logs > --- > > Key: TS-1935 > URL: https://issues.apache.org/jira/browse/TS-1935 > Project: Traffic Server > Issue Type: Bug >Reporter: Bryan Call > Fix For: 5.2.0 > > > Need to investigate in what conditions this happens. > * Keep-alive or not > * If any requests have happened on the connection > * Is the client or the server closing the connection at the time > * Verify no bytes have been sent from the client, looking at the code it > looks like it > Ideally if the client has not sent any bytes (has not attempted to make a > request) then we shouldn't log the error message. If it is possible a state > machine should not be created in this scenario. > related bug: > TS-1056 > related checkin: > 425e3d7dcb16b40075c7678e71d00b2fcb4b4705 > I also see this happening in on my forward proxy using Chrome: > [bcall@homer trafficserver]$ traffic_logcat -f squid.blog | grep 000 > 1370281253.174 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - > 1370281253.450 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - > 1370281253.891 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1935) ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
[ https://issues.apache.org/jira/browse/TS-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942600#comment-13942600 ] Leif Hedstrom commented on TS-1935: --- I'm ok either way honestly, as a metric, it might be useful to actually see the 408's in the log. So slight bias towards having them in log, with a better message other than UNKNOWN :). > ERR_UNKNOWN/000 showing up 10.4% of the time in production logs > --- > > Key: TS-1935 > URL: https://issues.apache.org/jira/browse/TS-1935 > Project: Traffic Server > Issue Type: Bug >Reporter: Bryan Call > Fix For: 5.2.0 > > > Need to investigate in what conditions this happens. > * Keep-alive or not > * If any requests have happened on the connection > * Is the client or the server closing the connection at the time > * Verify no bytes have been sent from the client, looking at the code it > looks like it > Ideally if the client has not sent any bytes (has not attempted to make a > request) then we shouldn't log the error message. If it is possible a state > machine should not be created in this scenario. > related bug: > TS-1056 > related checkin: > 425e3d7dcb16b40075c7678e71d00b2fcb4b4705 > I also see this happening in on my forward proxy using Chrome: > [bcall@homer trafficserver]$ traffic_logcat -f squid.blog | grep 000 > 1370281253.174 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - > 1370281253.450 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - > 1370281253.891 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - - -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1935) ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
[
https://issues.apache.org/jira/browse/TS-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942567#comment-13942567
]
Bryan Call commented on TS-1935:
Testing the behavior of httpd and squid.
httpd only logs the request when the server closes the connection because of a
timeout and doesn't log the request when the client closes the connection
without transferring any http bytes:
{code}
https:
[20/Mar/2014:15:43:59 -0700] 192.168.1.13 TLSv1 DHE-RSA-AES256-SHA "-" -
192.168.1.13 - - [20/Mar/2014:15:43:59 -0700] "-" 408 -
http:
192.168.1.16 - - [20/Mar/2014:14:31:44 -0700] "-" 408 - "-" "-"
{code}
Squid doesn't log anything in either case.
> ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
> ---
>
> Key: TS-1935
> URL: https://issues.apache.org/jira/browse/TS-1935
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Bryan Call
> Fix For: 5.2.0
>
>
> Need to investigate in what conditions this happens.
> * Keep-alive or not
> * If any requests have happened on the connection
> * Is the client or the server closing the connection at the time
> * Verify no bytes have been sent from the client, looking at the code it
> looks like it
> Ideally if the client has not sent any bytes (has not attempted to make a
> request) then we shouldn't log the error message. If it is possible a state
> machine should not be created in this scenario.
> related bug:
> TS-1056
> related checkin:
> 425e3d7dcb16b40075c7678e71d00b2fcb4b4705
> I also see this happening in on my forward proxy using Chrome:
> [bcall@homer trafficserver]$ traffic_logcat -f squid.blog | grep 000
> 1370281253.174 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - -
> 1370281253.450 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - -
> 1370281253.891 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - -
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2594) Segmentation fault for 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942525#comment-13942525
]
Alan M. Carroll commented on TS-2594:
-
New theory - change of WKS_IDX values for some field names is the problem due
to [this
change|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blobdiff;f=proxy/hdrs/HdrToken.cc;h=72bbbe1069b0094570a4909c5f12ceda25612d11;hp=4374d85ce456b1ef51190109b8221f15ff2d3a1e;hb=4cf9975e9b8ff0cc5510707443da0adafbb962cb;hpb=f057cdccaa8beac782028f1a8086971d46b15f95].
I have verified this shifted some of the values but I'm still investigating
how that would be a serious problem. It may be that this causes the presence
bits or slot accelerators to be set wrong, which would be sufficient for all of
the observed problems here and in TS-2564.
Still investigating.
> Segmentation fault for 4.2.0-rc0
>
>
> Key: TS-2594
> URL: https://issues.apache.org/jira/browse/TS-2594
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 4.2.0
>Reporter: bettydramit
> Labels: crash
> Fix For: 4.2.0, 5.0.0
>
>
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr'
> [TrafficServer] using root directory '/usr'
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf70f)[0x2b4e95ab670f]
> /lib64/libc.so.6(memcpy+0xe)[0x2b4e96a4595e]
> /usr/lib64/trafficserver/libtsutil.so.4(StrList::_new_cell(char const*,
> int)+0xef)[0x2b4e939ac88f]
> /usr/bin/traffic_server(StrList::new_cell(char const*, int)+0x9f)[0x5ff919]
> /usr/bin/traffic_server(StrList::append_string(char const*,
> int)+0x28)[0x5ff9ce]
> /usr/bin/traffic_server(mime_field_value_get_comma_list(MIMEField*,
> StrList*)+0x51)[0x602a39]
> /usr/bin/traffic_server(MIMEField::value_get_comma_list(StrList*)+0x22)[0x551052]
> /usr/bin/traffic_server(MIMEHdr::value_get_comma_list(char const*, int,
> StrList*)+0x4a)[0x5510a0]
> /usr/bin/traffic_server(HttpTransactCache::CalcVariability(CacheLookupHttpConfig*,
> HTTPHdr*, HTTPHdr*, HTTPHdr*)+0xab)[0x5a3399]
> /usr/bin/traffic_server(HttpTransactCache::calculate_quality_of_match(CacheLookupHttpConfig*,
> HTTPHdr*, HTTPHdr*, HTTPHdr*)+0xc68)[0x5a19b0]
> /usr/bin/traffic_server(HttpTransactCache::SelectFromAlternates(CacheHTTPInfoVector*,
> HTTPHdr*, CacheLookupHttpConfig*)+0x28c)[0x5a0a7e]
> /usr/bin/traffic_server(CacheVC::openReadStartHead(int,
> Event*)+0x5f2)[0x68e590]
> /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x6b)[0x4e7137]
> /usr/bin/traffic_server(CacheVC::handleReadDone(int, Event*)+0x1127)[0x66bfa9]
> /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x6b)[0x4e7137]
> /usr/bin/traffic_server(AIOCallbackInternal::io_complete(int,
> void*)+0x3b)[0x671371]
> /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x6b)[0x4e7137]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xc7)[0x6d9165]
> /usr/bin/traffic_server(EThread::execute()+0x9f)[0x6d9333]
> /usr/bin/traffic_server(main+0x122f)[0x50e634]
> /lib64/libc.so.6(__libc_start_main+0xfc)[0x2b4e969dad1c]
> /usr/bin/traffic_server[0x4ca098]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-1935) ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
[
https://issues.apache.org/jira/browse/TS-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942495#comment-13942495
]
Bryan Call edited comment on TS-1935 at 3/20/14 11:16 PM:
--
This is easy to reproduce by using netcat for http or openssl s_client for
https:
{code}
client:
[bcall@homer trafficserver]$ openssl s_client -connect localhost:8433 -reconnect
server:
1395357082.796 2 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357082.796 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357082.797 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357082.797 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357082.798 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
client:
[bcall@homer trafficserver]$ echo -n | ncat -4 localhost 8080
[bcall@homer trafficserver]$ echo -n | ncat -4 localhost 8080
[bcall@homer trafficserver]$ echo -n | ncat -4 localhost 8080
server:
1395357323.910 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357327.348 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357327.612 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
{code}
was (Author: bcall):
This is easy to reproduce by using netcat for http or openssl s_client for
https:
{code}
client:
[bcall@homer trafficserver]$ openssl s_client -connect localhost:8433 -reconnect
server:
1395357082.796 2 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357082.796 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357082.797 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357082.797 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357082.798 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
client:
[bcall@homer trafficserver]$ echo -n | ncat -4 localhost 8080
[bcall@homer trafficserver]$ echo -n | ncat -4 localhost 8080
[bcall@homer trafficserver]$ echo -n | ncat -4 localhost 8080
1395357323.910 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357327.348 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357327.612 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
{code}
> ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
> ---
>
> Key: TS-1935
> URL: https://issues.apache.org/jira/browse/TS-1935
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Bryan Call
> Fix For: 5.2.0
>
>
> Need to investigate in what conditions this happens.
> * Keep-alive or not
> * If any requests have happened on the connection
> * Is the client or the server closing the connection at the time
> * Verify no bytes have been sent from the client, looking at the code it
> looks like it
> Ideally if the client has not sent any bytes (has not attempted to make a
> request) then we shouldn't log the error message. If it is possible a state
> machine should not be created in this scenario.
> related bug:
> TS-1056
> related checkin:
> 425e3d7dcb16b40075c7678e71d00b2fcb4b4705
> I also see this happening in on my forward proxy using Chrome:
> [bcall@homer trafficserver]$ traffic_logcat -f squid.blog | grep 000
> 1370281253.174 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - -
> 1370281253.450 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - -
> 1370281253.891 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - -
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-1935) ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
[
https://issues.apache.org/jira/browse/TS-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942495#comment-13942495
]
Bryan Call commented on TS-1935:
This is easy to reproduce by using netcat for http or openssl s_client for
https:
{code}
client:
[bcall@homer trafficserver]$ openssl s_client -connect localhost:8433 -reconnect
server:
1395357082.796 2 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357082.796 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357082.797 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357082.797 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357082.798 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
client:
[bcall@homer trafficserver]$ echo -n | ncat -4 localhost 8080
[bcall@homer trafficserver]$ echo -n | ncat -4 localhost 8080
[bcall@homer trafficserver]$ echo -n | ncat -4 localhost 8080
1395357323.910 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357327.348 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
1395357327.612 0 127.0.0.1 ERR_UNKNOWN/000 0 - / - EMPTY/- -
{code}
> ERR_UNKNOWN/000 showing up 10.4% of the time in production logs
> ---
>
> Key: TS-1935
> URL: https://issues.apache.org/jira/browse/TS-1935
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Bryan Call
> Fix For: 5.2.0
>
>
> Need to investigate in what conditions this happens.
> * Keep-alive or not
> * If any requests have happened on the connection
> * Is the client or the server closing the connection at the time
> * Verify no bytes have been sent from the client, looking at the code it
> looks like it
> Ideally if the client has not sent any bytes (has not attempted to make a
> request) then we shouldn't log the error message. If it is possible a state
> machine should not be created in this scenario.
> related bug:
> TS-1056
> related checkin:
> 425e3d7dcb16b40075c7678e71d00b2fcb4b4705
> I also see this happening in on my forward proxy using Chrome:
> [bcall@homer trafficserver]$ traffic_logcat -f squid.blog | grep 000
> 1370281253.174 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - -
> 1370281253.450 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - -
> 1370281253.891 0 192.168.1.30 ERR_UNKNOWN/000 0 - / - EMPTY/- - -
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2652) atscppapi: Allow developers to cancel AsyncHttpFetch in specific and AsyncProviders in general
[ https://issues.apache.org/jira/browse/TS-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942416#comment-13942416 ] ASF GitHub Bot commented on TS-2652: GitHub user manjeshnilange opened a pull request: https://github.com/apache/trafficserver/pull/65 Patch for TS-2652: Allowing cancelation of AsyncProviders You can merge this pull request into a Git repository by running: $ git pull https://github.com/manjeshnilange/trafficserver master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/65.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 #65 commit af12e778714f6950316d2752339be178df43d7f1 Author: Manjesh Nilange Date: 2014-03-20T22:22:52Z Patch for TS-2652: Allowing cancelation of AsyncProviders > atscppapi: Allow developers to cancel AsyncHttpFetch in specific and > AsyncProviders in general > -- > > Key: TS-2652 > URL: https://issues.apache.org/jira/browse/TS-2652 > Project: Traffic Server > Issue Type: Wish >Reporter: Manjesh Nilange >Assignee: Brian Geffon > > Use case - if a plugin starts an async http fetch but wants to cancel it > before completion (timeout or something), the options available today are > 1) setting some state in the plugin and using this to ignore the callback. > 2) delete receiver (most cases a transaction plugin). > #1 is ugly and #2 is not possible always (there may be other things the > plugin wants to do). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2652) atscppapi: Allow developers to cancel AsyncHttpFetch in specific and AsyncProviders in general
Manjesh Nilange created TS-2652: --- Summary: atscppapi: Allow developers to cancel AsyncHttpFetch in specific and AsyncProviders in general Key: TS-2652 URL: https://issues.apache.org/jira/browse/TS-2652 Project: Traffic Server Issue Type: Wish Reporter: Manjesh Nilange Use case - if a plugin starts an async http fetch but wants to cancel it before completion (timeout or something), the options available today are 1) setting some state in the plugin and using this to ignore the callback. 2) delete receiver (most cases a transaction plugin). #1 is ugly and #2 is not possible always (there may be other things the plugin wants to do). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2652) atscppapi: Allow developers to cancel AsyncHttpFetch in specific and AsyncProviders in general
[ https://issues.apache.org/jira/browse/TS-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manjesh Nilange reassigned TS-2652: --- Assignee: Brian Geffon > atscppapi: Allow developers to cancel AsyncHttpFetch in specific and > AsyncProviders in general > -- > > Key: TS-2652 > URL: https://issues.apache.org/jira/browse/TS-2652 > Project: Traffic Server > Issue Type: Wish >Reporter: Manjesh Nilange >Assignee: Brian Geffon > > Use case - if a plugin starts an async http fetch but wants to cancel it > before completion (timeout or something), the options available today are > 1) setting some state in the plugin and using this to ignore the callback. > 2) delete receiver (most cases a transaction plugin). > #1 is ugly and #2 is not possible always (there may be other things the > plugin wants to do). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942014#comment-13942014
]
ASF subversion and git services commented on TS-2431:
-
Commit 79dd5035f9d361b5e0c8a2b4f71d2bd8dc243fb3 in trafficserver's branch
refs/heads/master from [~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=79dd503 ]
TS-2431: Migrate Taobao SPDY plugin to ATS core
This path depends on FetchSM, so seriously speaking, the migration
to ATS core is finished *partially*. I had tried to remove the dependency
of FetchSM and create a specific VC for each http request in spdy sm, but I
found it was not so easy, so I give up temporary. Let me push this
patch to community before it's perfect enough, at least, this series
patches can statisfy TAOBAO's current demand.
With this patch, ATS supports SPDY(v3/v3.1), the SPDY can run with/without
SSL:
1) SPDY without SSL:
It will share the same port number with HTTP, and ATS will recognize
SPDY/HTTP by detecting the first byte of client request.
2) SPDY with SSL:
When running SPDY with SSL, the code needs OpenSSL(>=1.01), if this
version of OpenSSL is installed in user-defined DIR, you may need to
use '--with-openssl=' option to tell ATS where to search.
Signed-off-by: Yunkai Zhang
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
> 0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
> 0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942013#comment-13942013
]
ASF subversion and git services commented on TS-2431:
-
Commit f90f3a488323ccb8b98c5571ef6cf035f1be51a9 in trafficserver's branch
refs/heads/master from [~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f90f3a4 ]
TS-2431: Preparation of SPDY protocol
*) Create basic data structures for SPDY protocal, such as:
SpdyAcceptCont.
*) SPDY will share the same port number with HTTP protocol, ATS can
recognize them by detecting the first byte of client request.
*) HttpAccept looks like a subclass of NetAccept. To avoid confusing,
rename HttpAccept to HttpAcceptCont.
Signed-off-by: Yunkai Zhang
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
> 0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
> 0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13942012#comment-13942012
]
ASF subversion and git services commented on TS-2431:
-
Commit f1a005e8c882d716c39475079614530b9abc8de4 in trafficserver's branch
refs/heads/master from [~yunkai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f1a005e ]
TS-2431: Add autoconf options for SPDY
*) Add '--enable-spdy' opton.
*) Add 'TS_HAS_SPDY' macro.
*) Conditional checking spdylay library.
Signed-off-by: Yunkai Zhang
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
> 0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
> 0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was: 0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
> 0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: 0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
> 0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
> 0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
> 0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
> 0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0014-TS-2431-Ignore-fetch-errors-after-FETCH_BODY_DONE.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
> 0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
> 0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0013-TS-2431-Set-eof-flag-to-prevent-spdy-client-hang.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0011-TS-2431-Fix-dechunking-on-FetchSM-s-response-data.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0010-TS-2431-Fix-infinite-loop-when-reading-the-fist-byte.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0012-TS-2431-Set-the-water-mark-of-resp_buffer-with-INT64.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0009-TS-2431-Close-SPDY-request-when-SPDY-is-not-endabled.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: 0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch
0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments: 0001-TS-2431-Add-autoconf-options-for-SPDY.V4.patch,
> 0002-TS-2431-Preparation-of-SPDY-protocol.V4.patch,
> 0003-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V4.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0007-TS-2431-Set-proto_type-properly-for-HttpSM.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0008-TS-2431-Add-client_req_proto_type-cqpt-field-into-lo.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was: 0006-TS-2431-Add-SSL-supporting-for-SPDY.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0005-TS-2431-Migrate-Taobao-SPDY-plugin-to-ATS-core.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was: 0003-TS-2431-Extends-and-optimizes-FetchSM.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was:
0004-TS-2431-Implement-dechunk-supporting-in-FetchSM.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was: 0002-TS-2431-Add-autoconf-options-for-SPDY.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2431) Add SPDY support to ATS
[
https://issues.apache.org/jira/browse/TS-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang updated TS-2431:
-
Attachment: (was: 0001-TS-2431-Preparation-of-SPDY-protocol.V3.patch)
> Add SPDY support to ATS
> ---
>
> Key: TS-2431
> URL: https://issues.apache.org/jira/browse/TS-2431
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 5.0.0
>
> Attachments:
> 0015-TS-2431-Move-SpdySM-from-iocore-net-to-proxy-spdy.V3.patch,
> 0016-TS-2431-Don-t-run-SPDY-on-HTTP-port-by-default.V3.patch
>
>
> I must say, sorry for my late. And now, I have finished the first version,
> the migration of Taobao SPDY plugin to ATS core.
> But seriously speaking, the migration to ATS core is finished *partially*. I
> had tried to remove the dependency of *fetcher* library created by @Quehan
> and create a specific VC for each http request in spdy sm, but I found it was
> too difficult, so I give up temporarily.
> Let me push this series patches to here before it's perfect enough, at least,
> this series can statisfy TAOBAO's current demand (in fact, this version has
> had good performance in our testing, but it can do much better I think).
> I had thought another solution instread of recreating a new VC for each http
> request in spdy sm, which will replace FetchSM's function and speed up SPDY
> protocol, but will not change the framework of this version. So I can hacking
> it based on these patches in the future.
> == *UPDATE* ==
> - From now on, SPDY can work with SSL, Cheers!
> ==How to test it==
> - Install *spdylay* library, here is URL of this lib:
> Download spdylay library: https://github.com/tatsuhiro-t/spdylay
> - Use '--enable-spdy' option to compile ATS:
> {code}
> $ ./configure --enable-spdy
> $ make all && make install
> {code}
> - SPDY can work with SSL now, it depends on OpenSSL >= 1.0.1. You can use
> '--with-openssl=' option to tell ATS where to search it:
> {code}
> $ ./configure --enable-spdy --with-openssl=/path/to/openssl-1.01
> {code}
> - Need not to config anything if you just want to test SPDY without SSL.
>The code can recognize SPDY or HTTP by reading this first byte of request.
> - When test SPDY+SSL, you may need to configure SSL key properly for ATS.
> - You can use *spdycat* in spdylay(or other SPDY client) to do request, for
> example:
> {code}
> # SPDY without SSL
> $ spdycat -3 -v --no-tls http://localhost/b.txt
> # SPDY + SSL
> $ spdycat -3 -v https://localhost/b.txt
> {code}
> - You can enable debuging logs of SPDY:
> {code}
> CONFIG proxy.config.diags.debug.enabled INT 1
> CONFIG proxy.config.diags.debug.tags STRING spdy
> {code}
> ==TODO===
> - Migrate spdy configuration to ATS records.config
> Any feedbacks are welcome.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2594) Segmentation fault for 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13941771#comment-13941771
]
Alan M. Carroll commented on TS-2594:
-
Current theory - HttpTransact::merge_response_header_with_cached_header is
broken.
This can delete fields out of the MIME heap and then put them back. But, I can
find no place where it would update the slot accelerators. The scenario would be
1) the headers are merged, 'Vary' is replaced, putting it in a different slot.
2) the heap strings are moved. The new 'Vary' is updated, but the old one is
not, leaving a dangling slot reference which is pointed at by the slot
accelerator.
Still investigating.
> Segmentation fault for 4.2.0-rc0
>
>
> Key: TS-2594
> URL: https://issues.apache.org/jira/browse/TS-2594
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 4.2.0
>Reporter: bettydramit
> Labels: crash
> Fix For: 4.2.0, 5.0.0
>
>
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr'
> [TrafficServer] using root directory '/usr'
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf70f)[0x2b4e95ab670f]
> /lib64/libc.so.6(memcpy+0xe)[0x2b4e96a4595e]
> /usr/lib64/trafficserver/libtsutil.so.4(StrList::_new_cell(char const*,
> int)+0xef)[0x2b4e939ac88f]
> /usr/bin/traffic_server(StrList::new_cell(char const*, int)+0x9f)[0x5ff919]
> /usr/bin/traffic_server(StrList::append_string(char const*,
> int)+0x28)[0x5ff9ce]
> /usr/bin/traffic_server(mime_field_value_get_comma_list(MIMEField*,
> StrList*)+0x51)[0x602a39]
> /usr/bin/traffic_server(MIMEField::value_get_comma_list(StrList*)+0x22)[0x551052]
> /usr/bin/traffic_server(MIMEHdr::value_get_comma_list(char const*, int,
> StrList*)+0x4a)[0x5510a0]
> /usr/bin/traffic_server(HttpTransactCache::CalcVariability(CacheLookupHttpConfig*,
> HTTPHdr*, HTTPHdr*, HTTPHdr*)+0xab)[0x5a3399]
> /usr/bin/traffic_server(HttpTransactCache::calculate_quality_of_match(CacheLookupHttpConfig*,
> HTTPHdr*, HTTPHdr*, HTTPHdr*)+0xc68)[0x5a19b0]
> /usr/bin/traffic_server(HttpTransactCache::SelectFromAlternates(CacheHTTPInfoVector*,
> HTTPHdr*, CacheLookupHttpConfig*)+0x28c)[0x5a0a7e]
> /usr/bin/traffic_server(CacheVC::openReadStartHead(int,
> Event*)+0x5f2)[0x68e590]
> /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x6b)[0x4e7137]
> /usr/bin/traffic_server(CacheVC::handleReadDone(int, Event*)+0x1127)[0x66bfa9]
> /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x6b)[0x4e7137]
> /usr/bin/traffic_server(AIOCallbackInternal::io_complete(int,
> void*)+0x3b)[0x671371]
> /usr/bin/traffic_server(Continuation::handleEvent(int, void*)+0x6b)[0x4e7137]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0xc7)[0x6d9165]
> /usr/bin/traffic_server(EThread::execute()+0x9f)[0x6d9333]
> /usr/bin/traffic_server(main+0x122f)[0x50e634]
> /lib64/libc.so.6(__libc_start_main+0xfc)[0x2b4e969dad1c]
> /usr/bin/traffic_server[0x4ca098]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
