[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