[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14107114#comment-14107114
]
Alan M. Carroll edited comment on TS-2983 at 8/22/14 5:24 PM:
--
The issue was the the IOBufferReader was initialized after data had arrived in
the IOBuffer. That can lead to dropped data depending on how much the client
sends initially. Moving the reader init to the constructor instead of the event
handler fixes the problem. See the comments on MIOBuffer::alloc_reader for more
detail.
was (Author: amc):
The issue was the the IOBufferReader was initialized after data had arrived in
the IOBuffer. That can lead to dropped data depending on how much the client
sends initially. Moving the read init to the constructor instead of the event
handler fixes the problem. See the comments on MIOBuffer::alloc_reader for more
detail.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=x;%20ypcdb=xx - NONE/- -
> {code}
> After a lot of debugging, figured that the request was getting corrupted even
> before remap and in fact, is being parsed incorrectly at the read request
> state. Further analysis lead me to the commit TS-2197 (commit
> 30fcc2b2e698831d1a9e4db1474d8cfc202818a3 in Oct'13), which has altered the
> way the request is read slightly. Reverting the commit seems to have fixed
> the issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090878#comment-14090878
]
Sudheer Vinukonda edited comment on TS-2983 at 8/8/14 3:41 PM:
---
Turns out that enabling probe for http also may be corrupting the requests.
Apologies for the misinformation, I may not have run it long enough earlier.
The https corruption was happening so often that, it was clear within a minute,
but, the http issue seems to be happening with really low frequency (once/hour
or so) - this may also be due to the generally lower percentage of http
traffic on our host. Anyway, for now, turning off both http and https probe and
we are back to trying to find the root cause.
{code}
1407509742.113 0 207.178.224.170 ERR_CONNECT_FAIL 404 0 bS?Q?
MLrM???[?'?j?ni?? http://%00?%009%008%005%003%002%00%04%00/??%00
INVALID_CODE(3833167298291761197)/1 - - f1 f2 f3 f4
1407509742.113 0 207.178.224.170 ERR_CONNECT_FAIL 404 1713 bS?Q?
MLrM???[?'?j?ni?? http://%00?%009%008%005%003%002%00%04%00/??%00
INVALID_CODE(4770214920072593453)/1 - text/html f1 f2 f3 f4
{code}
was (Author: sudheerv):
Turns out that enabling probe for http also may be corrupting the requests.
Apologies for the misinformation, I may not have run it long enough earlier.
The https corruption was happening so often that, it was clear within a minute,
but, the http issue seems to be happening with really low frequency (once/hour
or so) - this may also be due to the generally lower percentage of http
traffic on our host. Anyway, for now, turning off both http and https probe and
we are back to trying to find the root cause.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCb
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090288#comment-14090288
]
Sudheer Vinukonda edited comment on TS-2983 at 8/8/14 4:36 AM:
---
Thanks, [~zwoop]..If everyone agrees to not probe the SSL connection, I would
not mind that very much :=)
[~jpe...@apache.org] - Just to understand the mystery, I was looking at the
changes in TS-2751 and was wondering if the newly added ProtocolProbeTrampoline
does "everything", that the SSLNextProtocolTrampoline did for SSL connection
prior to TS-2751. In particular, I was curious about the below comments in
SSLNextProtocolAccept.cc indicating that the continuation that's handling the
read event must have a mutex etc. Perhaps, I am missing something, but, it
seemed to me that the new ProtocolProbeTrampoline did not seem to have such a
mechanism? One reason why I am curious about this is that, looking at the logs,
it seemed to me that multiple requests were garbled on each other (for e.g., a
header from request-1seemed to overwrite the fields in request-2).
{code}
"// SSLNextProtocolTrampoline is the receiver of the I/O event generated when
we perform a 0-length read on the new SSL
// connection. The 0-length read forces the SSL handshake, which allows us to
bind an endpoint that is selected by the
// NPN extension. The Continuation that receives the read event *must* have a
mutex, but we don't want to take a global
// lock across the handshake, so we make a trampoline to bounce the event from
the SSL acceptor to the ultimate session
// acceptor.
"
{code}
was (Author: sudheerv):
Thanks, [~zwoop]..If everyone agrees to not probe the SSL connection, I would
not mind that very much :=)
[~jpe...@apache.org] - Just to understand the mystery, I was looking at the
changes in TS-2751 and was wondering if the newly added ProtocolProbeTrampoline
does "everything", that the SSLNextProtocolTrampoline did for SSL connection
prior to TS-2751. In particular, I was curious about the below comments in
SSLNextProtocolAccept.cc indicating that the continuation that's handling the
read event must have a mutex etc. Perhaps, I am missing something, but, it
seemed to me that the new ProtocolProbeTrampoline did not seem to have such a
mechanism?
{code}
"// SSLNextProtocolTrampoline is the receiver of the I/O event generated when
we perform a 0-length read on the new SSL
// connection. The 0-length read forces the SSL handshake, which allows us to
bind an endpoint that is selected by the
// NPN extension. The Continuation that receives the read event *must* have a
mutex, but we don't want to take a global
// lock across the handshake, so we make a trampoline to bounce the event from
the SSL acceptor to the ultimate session
// acceptor.
"
{code}
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-2983.diff
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyT
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090094#comment-14090094
]
Sudheer Vinukonda edited comment on TS-2983 at 8/8/14 4:21 AM:
---
For non-TLS and non-SSL pure http, enabling the probe seems fine even after
TS-2751. The problem only happens when the probe is enabled for SSL connection.
It's not very clear from the description in TS-2751 that protocol probe support
was also being added for SSL. I agree with [~jpe...@apache.org]'s view to
support protocol probe for SSL as well, for the sake of completeness. Will try
and debug the issue.
was (Author: sudheerv):
For non-TLS and non-SSL pure http, enabling the probe seems fine even after
TS-2751. The problem only happens when the probe is enabled for SSL connection.
It's not very clear from the description in TS-2751 that protocol probe support
is also being added for SSL. I agree with [~jpe...@apache.org]'s view to
support protocol probe for SSL as well, for the sake of completeness. Will try
and debug the issue.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-2983.diff
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wism
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090094#comment-14090094
]
Sudheer Vinukonda edited comment on TS-2983 at 8/8/14 1:27 AM:
---
For non-TLS and non-SSL pure http, enabling the probe seems fine even after
TS-2751. The problem only happens when the probe is enabled for SSL connection.
It's not very clear from the description in TS-2751 that protocol probe support
is also being added for SSL. I agree with [~jpe...@apache.org]'s view to
support protocol probe for SSL as well, for the sake of completeness. Will try
and debug the issue.
was (Author: sudheerv):
For non-TLS and non-SSL pure http, enabling the probe seems fine even after
TS-2751. The problem only happens when the probe is enabled for SSL connection.
It's not very clear from the description in TS-2751 that protocol probe is also
being added for SSL. I agree with [~jpe...@apache.org]'s view to support
protocol probe for SSL as well, for the sake of completeness. Will try and
debug the issue.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-2983.diff
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8ndd
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090094#comment-14090094
]
Sudheer Vinukonda edited comment on TS-2983 at 8/8/14 1:26 AM:
---
For non-TLS and non-SSL pure http, enabling the probe seems fine even after
TS-2751. The problem only happens when the probe is enabled for SSL connection.
It's not very clear from the description in TS-2751 that protocol probe is also
being added for SSL. I agree with [~jpe...@apache.org]'s view to support
protocol probe for SSL as well, for the sake of completeness. Will try and
debug the issue.
was (Author: sudheerv):
For non-TLS and non-SSL pure http, enabling the probe seems fine even after
TS-2751. The problem only happens when the probe is enabled for SSL connection.
It's not very clear from the description in TS-2751 that protocol probe is also
being added for SSL. I agree with [~jpe...@apache.org]'s view to support SSL
probe for completeness. Will try and debug the issue.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-2983.diff
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48y
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090094#comment-14090094
]
Sudheer Vinukonda edited comment on TS-2983 at 8/8/14 1:25 AM:
---
For non-TLS and non-SSL pure http, enabling the probe seems fine even after
TS-2751. The problem only happens when the probe is enabled for SSL connection.
It's not very clear from the description in TS-2751 that protocol probe is also
being added for SSL. I agree with [~jpe...@apache.org]'s view to support SSL
probe for completeness. Will try and debug the issue.
was (Author: sudheerv):
For non-TLS and non-SSL pure http, enabling the probe seems fine even after
TS-2751. The problem only happens when the probe is enabled for SSL connection.
It's not very clear from the description in TS-2751 that protocol probe is also
being added for SSL. I agree with [~jpe...@apache.org]]'s view to support SSL
probe for completeness. Will try and debug the issue.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-2983.diff
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZigl
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090094#comment-14090094
]
Sudheer Vinukonda edited comment on TS-2983 at 8/8/14 1:25 AM:
---
For non-TLS and non-SSL pure http, enabling the probe seems fine even after
TS-2751. The problem only happens when the probe is enabled for SSL connection.
It's not very clear from the description in TS-2751 that protocol probe is also
being added for SSL. I agree with [~jpe...@apache.org]]'s view to support SSL
probe for completeness. Will try and debug the issue.
was (Author: sudheerv):
For non-TLS and non-SSL pure http, enabling the probe seems fine even after
TS-2751. The problem only happens when the probe is enabled for SSL connection.
It's not very clear from the description in TS-2751 that protocol probe is also
being added for SSL. I agree with [~jpeach]'s view to support SSL probe for
completeness. Will try and debug the issue.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-2983.diff
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcH
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088759#comment-14088759
]
Bryan Call edited comment on TS-2983 at 8/7/14 3:31 AM:
I don't think it is useful to probe for spdy or http/2 for TLS and ATS should
depend on NPN/ALPN for the correct application protocol.
I do think we should fix the underlying issue for non-TLS.
was (Author: bcall):
I don't think it is useful to probe for spdy or http/2 for TLS and it should
depend on NPN/ALPN for the correct information.
I do think we should fix the underlying issue for non-TLS.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-2983.diff
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088542#comment-14088542
]
Sudheer Vinukonda edited comment on TS-2983 at 8/7/14 12:47 AM:
[~jpe...@apache.org] -
I dug a bit into the old logs to find if there was any non-https request
getting corrupted. I did not find a single such request. iow, all the requests
that are corrupted seem to be https.
Looking into the changes made in TS-2751 again, I am wondering if we really
need to support protocol probe for https at all - the implementation prior to
TS-2751 also seem to only support probe for http.
I also verified that there's no issue with TS-2751 commit when I enable the
probe for http and just revert the probe for https. Is there any specific
reason that you would like the probe enabled for https? Isn't NPN support
mandatory for SPDY over https?
{code}
diff --git a/proxy/http/HttpProxyServerMain.cc
b/proxy/http/HttpProxyServerMain.cc
index 9eb9291..6cdbce7 100644
--- a/proxy/http/HttpProxyServerMain.cc
+++ b/proxy/http/HttpProxyServerMain.cc
@@ -171,10 +171,9 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
// XXX the protocol probe should be a configuration option.
ProtocolProbeSessionAccept *probe = new ProtocolProbeSessionAccept();
- HttpSessionAccept *http = 0; // don't allocate this unless it will be used.
+ HttpSessionAccept *http = new HttpSessionAccept(accept_opt);
if (port.m_session_protocol_preference.intersects(HTTP_PROTOCOL_SET)) {
-http = new HttpSessionAccept(accept_opt);
probe->registerEndpoint(ProtocolProbeSessionAccept::PROTO_HTTP, http);
}
@@ -185,7 +184,7 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
#endif
if (port.isSSL()) {
-SSLNextProtocolAccept *ssl = new SSLNextProtocolAccept(probe);
+SSLNextProtocolAccept *ssl = new SSLNextProtocolAccept(http);
// ALPN selects the first server-offered protocol,
// so make sure that we offer the newest protocol first.
{code}
was (Author: sudheerv):
[~jpe...@apache.org]] -
I dug a bit into the old logs to find if there was any non-https request
getting corrupted. I did not find a single such request. iow, all the requests
that are corrupted seem to be https.
Looking into the changes made in TS-2751 again, I am wondering if we really
need to support protocol probe for https at all - the implementation prior to
TS-2751 also seem to only support probe for http.
I also verified that there's no issue with TS-2751 commit when I enable the
probe for http and just revert the probe for https. Is there any specific
reason that you would like the probe enabled for https? Isn't NPN support
mandatory for SPDY over https?
{code}
diff --git a/proxy/http/HttpProxyServerMain.cc
b/proxy/http/HttpProxyServerMain.cc
index 9eb9291..6cdbce7 100644
--- a/proxy/http/HttpProxyServerMain.cc
+++ b/proxy/http/HttpProxyServerMain.cc
@@ -171,10 +171,9 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
// XXX the protocol probe should be a configuration option.
ProtocolProbeSessionAccept *probe = new ProtocolProbeSessionAccept();
- HttpSessionAccept *http = 0; // don't allocate this unless it will be used.
+ HttpSessionAccept *http = new HttpSessionAccept(accept_opt);
if (port.m_session_protocol_preference.intersects(HTTP_PROTOCOL_SET)) {
-http = new HttpSessionAccept(accept_opt);
probe->registerEndpoint(ProtocolProbeSessionAccept::PROTO_HTTP, http);
}
@@ -185,7 +184,7 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
#endif
if (port.isSSL()) {
-SSLNextProtocolAccept *ssl = new SSLNextProtocolAccept(probe);
+SSLNextProtocolAccept *ssl = new SSLNextProtocolAccept(http);
// ALPN selects the first server-offered protocol,
// so make sure that we offer the newest protocol first.
{code}
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-2983.diff
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
>
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088542#comment-14088542
]
Sudheer Vinukonda edited comment on TS-2983 at 8/7/14 12:48 AM:
[~jpe...@apache.org] -
I dug a bit into the old logs to find if there was any non-https request
getting corrupted. I did not find a single such request. iow, all the requests
that are corrupted seem to be https.
Looking into the changes made in TS-2751 again, I am wondering if we really
need to support protocol probe for https at all - the implementation prior to
TS-2751 also seems to only support probe for http.
I also verified that there's no issue with TS-2751 commit when I enable the
probe for http and just revert the probe for https. Is there any specific
reason that you would like the probe enabled for https? Isn't NPN support
mandatory for SPDY over https?
{code}
diff --git a/proxy/http/HttpProxyServerMain.cc
b/proxy/http/HttpProxyServerMain.cc
index 9eb9291..6cdbce7 100644
--- a/proxy/http/HttpProxyServerMain.cc
+++ b/proxy/http/HttpProxyServerMain.cc
@@ -171,10 +171,9 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
// XXX the protocol probe should be a configuration option.
ProtocolProbeSessionAccept *probe = new ProtocolProbeSessionAccept();
- HttpSessionAccept *http = 0; // don't allocate this unless it will be used.
+ HttpSessionAccept *http = new HttpSessionAccept(accept_opt);
if (port.m_session_protocol_preference.intersects(HTTP_PROTOCOL_SET)) {
-http = new HttpSessionAccept(accept_opt);
probe->registerEndpoint(ProtocolProbeSessionAccept::PROTO_HTTP, http);
}
@@ -185,7 +184,7 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
#endif
if (port.isSSL()) {
-SSLNextProtocolAccept *ssl = new SSLNextProtocolAccept(probe);
+SSLNextProtocolAccept *ssl = new SSLNextProtocolAccept(http);
// ALPN selects the first server-offered protocol,
// so make sure that we offer the newest protocol first.
{code}
was (Author: sudheerv):
[~jpe...@apache.org] -
I dug a bit into the old logs to find if there was any non-https request
getting corrupted. I did not find a single such request. iow, all the requests
that are corrupted seem to be https.
Looking into the changes made in TS-2751 again, I am wondering if we really
need to support protocol probe for https at all - the implementation prior to
TS-2751 also seem to only support probe for http.
I also verified that there's no issue with TS-2751 commit when I enable the
probe for http and just revert the probe for https. Is there any specific
reason that you would like the probe enabled for https? Isn't NPN support
mandatory for SPDY over https?
{code}
diff --git a/proxy/http/HttpProxyServerMain.cc
b/proxy/http/HttpProxyServerMain.cc
index 9eb9291..6cdbce7 100644
--- a/proxy/http/HttpProxyServerMain.cc
+++ b/proxy/http/HttpProxyServerMain.cc
@@ -171,10 +171,9 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
// XXX the protocol probe should be a configuration option.
ProtocolProbeSessionAccept *probe = new ProtocolProbeSessionAccept();
- HttpSessionAccept *http = 0; // don't allocate this unless it will be used.
+ HttpSessionAccept *http = new HttpSessionAccept(accept_opt);
if (port.m_session_protocol_preference.intersects(HTTP_PROTOCOL_SET)) {
-http = new HttpSessionAccept(accept_opt);
probe->registerEndpoint(ProtocolProbeSessionAccept::PROTO_HTTP, http);
}
@@ -185,7 +184,7 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
#endif
if (port.isSSL()) {
-SSLNextProtocolAccept *ssl = new SSLNextProtocolAccept(probe);
+SSLNextProtocolAccept *ssl = new SSLNextProtocolAccept(http);
// ALPN selects the first server-offered protocol,
// so make sure that we offer the newest protocol first.
{code}
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-2983.diff
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
>
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088542#comment-14088542
]
Sudheer Vinukonda edited comment on TS-2983 at 8/7/14 12:47 AM:
[~jpe...@apache.org]] -
I dug a bit into the old logs to find if there was any non-https request
getting corrupted. I did not find a single such request. iow, all the requests
that are corrupted seem to be https.
Looking into the changes made in TS-2751 again, I am wondering if we really
need to support protocol probe for https at all - the implementation prior to
TS-2751 also seem to only support probe for http.
I also verified that there's no issue with TS-2751 commit when I enable the
probe for http and just revert the probe for https. Is there any specific
reason that you would like the probe enabled for https? Isn't NPN support
mandatory for SPDY over https?
{code}
diff --git a/proxy/http/HttpProxyServerMain.cc
b/proxy/http/HttpProxyServerMain.cc
index 9eb9291..6cdbce7 100644
--- a/proxy/http/HttpProxyServerMain.cc
+++ b/proxy/http/HttpProxyServerMain.cc
@@ -171,10 +171,9 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
// XXX the protocol probe should be a configuration option.
ProtocolProbeSessionAccept *probe = new ProtocolProbeSessionAccept();
- HttpSessionAccept *http = 0; // don't allocate this unless it will be used.
+ HttpSessionAccept *http = new HttpSessionAccept(accept_opt);
if (port.m_session_protocol_preference.intersects(HTTP_PROTOCOL_SET)) {
-http = new HttpSessionAccept(accept_opt);
probe->registerEndpoint(ProtocolProbeSessionAccept::PROTO_HTTP, http);
}
@@ -185,7 +184,7 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
#endif
if (port.isSSL()) {
-SSLNextProtocolAccept *ssl = new SSLNextProtocolAccept(probe);
+SSLNextProtocolAccept *ssl = new SSLNextProtocolAccept(http);
// ALPN selects the first server-offered protocol,
// so make sure that we offer the newest protocol first.
{code}
was (Author: sudheerv):
[~jpeach] -
I dug a bit into the old logs to find if there was any non-https request
getting corrupted. I did not find a single such request. iow, all the requests
that are corrupted seem to be https.
Looking into the changes made in TS-2751 again, I am wondering if we really
need to support protocol probe for https at all - the implementation prior to
TS-2751 also seem to only support probe for http.
I also verified that there's no issue with TS-2751 commit when I enable the
probe for http and just revert the probe for https. Is there any specific
reason that you would like the probe enabled for https? Isn't NPN support
mandatory for SPDY over https?
{code}
diff --git a/proxy/http/HttpProxyServerMain.cc
b/proxy/http/HttpProxyServerMain.cc
index 9eb9291..6cdbce7 100644
--- a/proxy/http/HttpProxyServerMain.cc
+++ b/proxy/http/HttpProxyServerMain.cc
@@ -171,10 +171,9 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
// XXX the protocol probe should be a configuration option.
ProtocolProbeSessionAccept *probe = new ProtocolProbeSessionAccept();
- HttpSessionAccept *http = 0; // don't allocate this unless it will be used.
+ HttpSessionAccept *http = new HttpSessionAccept(accept_opt);
if (port.m_session_protocol_preference.intersects(HTTP_PROTOCOL_SET)) {
-http = new HttpSessionAccept(accept_opt);
probe->registerEndpoint(ProtocolProbeSessionAccept::PROTO_HTTP, http);
}
@@ -185,7 +184,7 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
#endif
if (port.isSSL()) {
-SSLNextProtocolAccept *ssl = new SSLNextProtocolAccept(probe);
+SSLNextProtocolAccept *ssl = new SSLNextProtocolAccept(http);
// ALPN selects the first server-offered protocol,
// so make sure that we offer the newest protocol first.
{code}
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-2983.diff
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084098#comment-14084098
]
Sudheer Vinukonda edited comment on TS-2983 at 8/6/14 1:58 AM:
---
You are right - I couldn't (and didn't) actually revert TS-2751 alone, since
there are quite a few commits since.
Given the nature of the problem (that the incoming client request is corrupted
before any processing begins and that the corrupted request gets parsed), I
just used my judgement going over the commits and the type of changes.
Basically, what I did was to confirm that the issue doesn't occur when I go
back to pre-TS-2751 (commit 1106086111dc0faf0568bd7bf78b3ee6f7bb344a) and when
I add TS-2751 on top of that (727811ef0870701ade427b0ed374ac42daec8c54), the
issue comes back.
Since, it's a large commit, I didn't actually review the entire commit yet, so,
do you have any specific part of the code that you would like me to comment out
or modify to disable protocol probing?
was (Author: sudheerv):
You are right - I couldn't (and didn't) actually revert TS-2751 alone, since
there are quite a few comments since.
Given the nature of the problem (that the incoming client request is corrupted
before any processing begins and that the corrupted request gets parsed), I
just used my judgement going over the commits and the type of changes.
Basically, what I did was to confirm that the issue doesn't occur when I go
back to pre-TS-2751 (commit 1106086111dc0faf0568bd7bf78b3ee6f7bb344a) and when
I add TS-2751 on top of that (727811ef0870701ade427b0ed374ac42daec8c54), the
issue comes back.
Since, it's a large commit, I didn't actually review the entire commit yet, so,
do you have any specific part of the code that you would like me to comment out
or modify to disable protocol probing?
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: TS-2983.diff
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDG
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084953#comment-14084953
]
Sudheer Vinukonda edited comment on TS-2983 at 8/4/14 5:43 PM:
---
[~jpe...@apache.org]- it looks like the change you suggested above only
disables protocol probe for http. [~bcall] suggested the below additional
change to disable the probe for https as well. Tried this additional suggestion
and that seems to have done the trick. I've also done some basic validation to
ensure that spdy is not broken when enabled via NPN (normal way of configuring
spdy via server_port setting).
{code}
diff --git a/proxy/http/HttpProxyServerMain.cc
b/proxy/http/HttpProxyServerMain.cc
index c9fdbde..46ee998 100644
--- a/proxy/http/HttpProxyServerMain.cc
+++ b/proxy/http/HttpProxyServerMain.cc
@@ -180,7 +180,7 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
probe->registerEndpoint(TS_PROTO_HTTP, http);
if (port.isSSL()) {
-SSLNextProtocolAccept *ssl = NEW(new SSLNextProtocolAccept(probe));
+SSLNextProtocolAccept *ssl = NEW(new SSLNextProtocolAccept(http));
// ALPN selects the first server-offered protocol,
// so make sure that we offer the newest protocol first.
@@ -204,7 +204,7 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
acceptor._accept = ssl;
} else {
-acceptor._accept = probe;
+acceptor._accept = http;
}
}
{code}
was (Author: sudheerv):
[~jpeach] - it looks like the change you suggested above only disables protocol
probe for http. [~bcall] suggested the below additional change to disable the
probe for https as well. Tried this additional suggestion and that seems to
have done the trick. I've also done some basic validation to ensure that spdy
is not broken when enabled via NPN (normal way of configuring spdy via
server_port setting).
{code}
diff --git a/proxy/http/HttpProxyServerMain.cc
b/proxy/http/HttpProxyServerMain.cc
index c9fdbde..46ee998 100644
--- a/proxy/http/HttpProxyServerMain.cc
+++ b/proxy/http/HttpProxyServerMain.cc
@@ -180,7 +180,7 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
probe->registerEndpoint(TS_PROTO_HTTP, http);
if (port.isSSL()) {
-SSLNextProtocolAccept *ssl = NEW(new SSLNextProtocolAccept(probe));
+SSLNextProtocolAccept *ssl = NEW(new SSLNextProtocolAccept(http));
// ALPN selects the first server-offered protocol,
// so make sure that we offer the newest protocol first.
@@ -204,7 +204,7 @@ MakeHttpProxyAcceptor(HttpProxyAcceptor& acceptor,
HttpProxyPort& port, unsigned
acceptor._accept = ssl;
} else {
-acceptor._accept = probe;
+acceptor._accept = http;
}
}
{code}
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPims
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084760#comment-14084760
]
James Peach edited comment on TS-2983 at 8/4/14 4:20 PM:
-
Oh, https-only is a good clue!
was (Author: jamespeach):
Oh, https-only i a good clue!
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBX
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083854#comment-14083854
]
Sudheer Vinukonda edited comment on TS-2983 at 8/3/14 3:33 AM:
---
Just to confirm that there are no more errors, since reverting TS-2751..traffic
appears stable for the past few hours.
A few additional observations -
- the issue seems independent of spdy - it appears to be happening when spdy is
enabled as well as disabled
- the issue is independent of any (open source as well as custom) plugins -
- we are not noticing this issue in our production static content cache serving
system. It is only affecting our proxy infrastructure.
An additional note - I remember seeing some spdy requests failing with spdy
with the received responses showing version HTTP/0.9 (afaict, [~briang] also
noticed this). Not sure, if that is also related to the client request
corruption (it seems http parser defaults to v0.9, in error cases)
was (Author: sudheerv):
Just to confirm that there are no more errors, since reverting TS-2751..traffic
appears stable for the past few hours.
A few additional observations -
- the issue seems independent of spdy - it appears to be happening when spdy is
enabled as well as disabled
- the issue is independent of any (open source as well as custom) plugins -
- we are not noticing this issue in our production static content cache serving
system. It is only affecting our proxy infrastructure.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=u
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083854#comment-14083854
]
Sudheer Vinukonda edited comment on TS-2983 at 8/3/14 3:28 AM:
---
Just to confirm that there are no more errors, since reverting TS-2751..traffic
appears stable for the past few hours.
A few additional observations -
- the issue seems independent of spdy - it appears to be happening when spdy is
enabled as well as disabled
- the issue is independent of any (open source as well as custom) plugins -
- we are not noticing this issue in our production static content cache serving
system. It is only affecting our proxy infrastructure.
was (Author: sudheerv):
Just to confirm that there are no more errors, since reverting TS-2751..traffic
appears stable for the past few hours.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0S5we2qshU69hR1grm1Pyxli2Pv8uZ3YqL2FUQow0zZdtejnsxosoFqfge_mWnnHq9gmXkfc0RdgUevblIr50wC6stwTwjbW2MqOo2zyrRkp99Uprxah2olhrbw7Zc2yFDuCG5A4.R_3crXB8fp6iwmdlGnDfRa1oaHXn3Kves9YbZLtp1sUmQFmPoKr7Fu0qgxSHPDagEqhQXFnV3YpZ0LHdvir7MWFKg2bzh3OlrDeaGe0KK.xl8Y2OkckdNvQ.ho6F9AElt5GBACSl2kaVKChw8xa5xUOT0x8FYzFfgGk6syEESBPxvloY7OpdDGh3LUovu00N7z2z8lhC.LvYwmEdMeuS.5qq5yAE4jGWSlXXBBgUBXqyTFJ3IZUbm1gPvOCbEVELrbEvc7n0Gw_D_TjHcbNHN7rzXqad;
>
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> - NONE/- -
> https://YLS=v=1&p=1&n=0;%20ucs=bnas=1&bnid=SGZJL05rb2dzRzN3dTd5UDJWdFdqUT09;%20_br_uid_2=uid%3D7216053621378%3A_uid%3D8562842167448%3Av%3D10.6.1%3Ats%3D1324745461005%3Ahc%3D11/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 1897
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083789#comment-14083789
]
Sudheer Vinukonda edited comment on TS-2983 at 8/3/14 3:21 AM:
---
It turns out that TS-2197 is not really the culprit - the errors appeared to
have stopped for a few minutes, when I reverted TS-2197, but, appeared again.
:-(
Investigating further, it looks like, the commit in TS-2751 may be causing this
issue. I suspected this to begin with, but, was hoping seriously, that it was
not. Given that it's a relatively large commit, it may need to be reviewed
carefully to identify the root cause.
For the time being, reverting TS-2751 and running the private version for an
hour in production, did not bring back the errors so far - will continue to
monitor and confirm/update, if there's anything else.
[~jpe...@apache.org] - We are only seeing this in production. [~bcall] and
myself have not been able to reproduce it, but, our ops team was able to
reproduce consistently (but, again only in production), using Safari browser.
Will let you know if we manage to find an easier way to reproduce it.
And yes, this is definitely a blocker for our 5.0.x (and in turn, SPDY)
production roll out - it would be interesting to hear if anyone else, using
5.0.x is also seeing this issue.
was (Author: sudheerv):
It turns out that TS-2197 is not really the culprit - the errors appeared to
have stopped for a few minutes, when I reverted TS-2197, but, appeared again.
:-(
Investigating further, it looks like, the commit in TS-2751 may be causing this
issue. I suspected this to begin with, but, was hoping seriously, that it was
not. Given that, it's a relatively large commit, this may need to be reviewed
carefully to catch the issue.
For the time being, reverting TS-2751 and running the private version for an
hour in production, did not bring back the errors so far - will continue to
monitor and confirm/update, if there's anything else.
[~jpe...@apache.org] - We are only seeing this in production. [~bcall] and
myself have not been able to reproduce it, but, our ops team was able to
reproduce consistently (but, again only in production), using Safari browser.
Will let you know if we manage to find an easier way to reproduce it.
And yes, this is definitely a blocker for our 5.0.x (and in turn, SPDY)
production roll out - it would be interesting to hear if anyone else, using
5.0.x is also seeing this issue.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3u
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083789#comment-14083789
]
Sudheer Vinukonda edited comment on TS-2983 at 8/2/14 11:41 PM:
It turns out that TS-2197 is not really the culprit - the errors appeared to
have stopped for a few minutes, when I reverted TS-2197, but, appeared again.
:-(
Investigating further, it looks like, the commit in TS-2751 may be causing this
issue. I suspected this to begin with, but, was hoping seriously, that it was
not. Given that, it's a relatively large commit, this may need to be reviewed
carefully to catch the issue.
For the time being, reverting TS-2751 and running the private version for an
hour in production, did not bring back the errors so far - will continue to
monitor and confirm/update, if there's anything else.
[~jpe...@apache.org] - We are only seeing this in production. [~bcall] and
myself have not been able to reproduce it, but, our ops team was able to
reproduce consistently (but, again only in production), using Safari browser.
Will let you know if we manage to find an easier way to reproduce it.
And yes, this is definitely a blocker for our 5.0.x (and in turn, SPDY)
production roll out - it would be interesting to hear if anyone else, using
5.0.x is also seeing this issue.
was (Author: sudheerv):
It turns out that TS-2197 is not really the culprit - the errors appeared to
have stopped for a few minutes, when I reverted TS-2197, but, appeared again.
:-(
Investigating further, it looks like, the commit in TS-2751 may be causing this
issue. I suspected this to begin with, but, was hoping seriously, that it was
not. Given that, it's a relatively large commit, this may need to be reviewed
carefully to catch the issue.
For the time being, reverting TS-2751 and running the private version for an
hour in production, did not bring back the errors so far - will continue to
monitor and confirm/update, if there's anything else.
[~jpe...@apache.org] - We are only seeing this in production and [~bcall] and
myself have not been able to reproduce it, but, our ops team was able to
reproduce consistently (but, again only in production), using Safari browser.
Will let you know if we manage to find an easier way to reproduce it.
And yes, this is definitely a blocker for our 5.0.x (and in turn, SPDY)
production roll out - it would be interesting to hear if anyone else, using
5.0.x is also seeing this issue.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3u
[jira] [Comment Edited] (TS-2983) request headers, http object corrupted in 5.0.x
[
https://issues.apache.org/jira/browse/TS-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083789#comment-14083789
]
Sudheer Vinukonda edited comment on TS-2983 at 8/2/14 11:36 PM:
It turns out that TS-2197 is not really the culprit - the errors appeared to
have stopped for a few minutes, when I reverted TS-2197, but, appeared again.
:-(
Investigating further, it looks like, the commit in TS-2751 may be causing this
issue. I suspected this to begin with, but, was hoping seriously, that it was
not. Given that, it's a relatively large commit, this may need to be reviewed
carefully to catch the issue.
For the time being, reverting TS-2751 and running the private version for an
hour in production, did not bring back the errors so far - will continue to
monitor and confirm/update, if there's anything else.
[~jpe...@apache.org] - We are only seeing this in production and [~bcall] and
myself have not been able to reproduce it, but, our ops team was able to
reproduce consistently (but, again only in production), using Safari browser.
Will let you know if we manage to find an easier way to reproduce it.
And yes, this is definitely a blocker for our 5.0.x (and in turn, SPDY)
production roll out - it would be interesting to hear if anyone else, using
5.0.x is also seeing this issue.
was (Author: sudheerv):
It turns out that TS-2197 is not really the culprit - the errors appeared to
have stopped for a few minutes, when I reverted TS-2197, but, appeared again.
:-(
Investigating further, it looks like, the commit in TS-2751 may be causing this
issue. I suspected this to begin with, but, was hoping seriously, that it was
not. Given that, it's a relatively large commit, this may need to be reviewed
carefully to catch the issue.
For the time being, reverting TS-2751 and running the private version for an
hour in production, did not bring back the errors so far - will continue to
monitor and confirm/update, if there's anything else.
And yes, this is definitely a blocker for our 5.0.x (and in turn, SPDY)
production roll out - it would be interesting to hear if anyone else, using
5.0.x is also seeing this issue.
> request headers, http object corrupted in 5.0.x
> ---
>
> Key: TS-2983
> URL: https://issues.apache.org/jira/browse/TS-2983
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.1.0
>Reporter: Sudheer Vinukonda
>Priority: Blocker
> Fix For: 5.1.0
>
>
> We have run into a http header/field corruption issue on our proxy
> infrastructure production hosts when we enabled 5.0.x. The issue results in
> host header/method and other field corruption.
> For example, this is what we see in our squid access logs:
> {code}
> 1406999819.698 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999819.698 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 0 69.109.120.92 ERR_CONNECT_FAIL 404 0 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- -
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999834.692 4 69.109.120.92 ERR_CONNECT_FAIL 404 1825 nas=0&disclaimer=2;
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> - NONE/- text/html
> https://AMCV_att1=MCAID%7C29B9EEB305013EE7-410900024C7D;%20ypcdb=27a2458b603f6370d295cf4130825e34/
> f1 f2 f3 f4
> 1406999842.475 0 75.15.121.107 ERR_CONNECT_FAIL 404 0
> 435OjuZl6UyTXTs38eKhUO5C7Vs4E7FRajuU3BHWqLQxY4GMkRCgkGTvCOJPimsE1aB2W5hj_Qh70_dy7aJoas2DbmaCbIJ6UgkbkUINLhJbjDnfx3pKtVSlFca1VB6zCYSEkCswU_dULV6p2FtUs5aVRCZl2kVCmvy9esXiSqqXN1oYxAPe6l5bHM9yLOVNIRmaFTRcSHLm3e3lIp5Bx3Wismutrnp8nddMtqoz8xhLLUTVrid1YGmu0kPQxEhn8kJtm_8E2Kw48yhiy.slyxhwZPtI3rHRz42B4MrcvGBnZiglC0f0FCHYBcHVZ4B0eqCXX3hNNH_.xj9xqHfRJzRaL0c6DwuiVFiyd4UcID3uhp6e1Y5EAh0lN4_gJPFCxnyrqnzw1T31w.TuhS9Rz98ZlNHVvsN6kLnKq5JmxocK7X4rmzOKNmmY9e85vEhQS7c4fN69JtzyvdbNUWY_4x6iYU4rvIu30miN.klS8iqD_W8g_6Xl.iclrYt_AKdUJ59qhj9V54JDebWuybPyZHLB.h2ZOKzbIyO9qUiZUY.5eqiHeupe_3ZieCViVpkCVKoiEunj1bPRd9tuxcNel.GmAtDPjRCwUH3WVCz3zq34rY6VBG2EeNQyLNNTT1GEHiXQ7k_ykZeQ6qCZGSZPpqz0
