You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "taoyunxing (JIRA)" <ji...@apache.org> on 2011/08/18 10:57:27 UTC
[jira] [Created] (TS-921) TSIOBufferBlockReadStart() could'nt
return the corresponding chunk data length when original server using the
"Transfer Encoding: chunked" http header !
TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the "Transfer Encoding: chunked" http header !
--------------------------------------------------------------------------------------------------------------------------------------------------------
Key: TS-921
URL: https://issues.apache.org/jira/browse/TS-921
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.0.1
Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0.1, Web Browser：firefox 6.0，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk: 500G
Reporter: taoyunxing
Fix For: 3.0.2
Recently I meet with a strange proble when I manage to get the server response body in the "Transfer Encoding: chunked" mode:
I couldn't get the corresponding chunk length in hexdecimal ! The details as follows:
I use the "null-transform" plugin modified to just output the server response body, when the web server uses the "Transfer Encoding: chunked" header
to transfer chunked data to user agent, eg, I request the web page: "http://www.qq.com/", I just get the chunk body data, but get no chunk length in
the hexdecimal format "383cb\r\n" before the chunk body data. the chunk body data is uncompressed and like as "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n......."
In addition, I capture the data packet using the Wireshark software, I sure that I see the chunk length "383cb\r\n" before the chunk body data "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n.......", it is a complete chunk response !
I continue to check the code of null-transform.c, set a breakpoint at the function TSIOBufferBlockReadStart(), run ATS and debug it, when ATS stop at the breakpoint TSIOBufferBlockReadStart(), I print the return string of TSIOBufferBlockReadStart(), there is no chunk data length at the head of output string, which implies the api TSIOBufferBlockReadStart() has bug！
Breakpoint 1, TSIOBufferBlockReadStart (blockp=0x89d6570, readerp=0x89d5330, avail=0xb6c8e288) at InkIOCoreAPI.cc:659
659 {
(gdb) s
660 sdk_assert(sdk_sanity_check_iocore_structure(blockp) == TS_SUCCESS);
(gdb) n
667 p = blk->start();
(gdb)
668 if (avail)
(gdb) p p
$3 = 0xb1312000 "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\r\n<html xmlns=\"http://www.w3.org/1999/xhtml\">\r\n<head>\r\n<meta http-equiv=\"Conten"...
(gdb)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-921) TSIOBufferBlockReadStart() could'nt
return the corresponding chunk data length when original server using the
"Transfer Encoding: chunked" http header !
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-921:
-----------------------------
Backport to Version: (was: 3.0.1)
Fix Version/s: (was: 3.0.2)
3.1.1
Not sure how the fix versions were decided for this, bug remember, things has to go on trunk first, then get nominated for backports. So, marking this to be fixed for 3.1.1 (the next developer release).
> TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the "Transfer Encoding: chunked" http header !
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TS-921
> URL: https://issues.apache.org/jira/browse/TS-921
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
> Affects Versions: 3.0.1
> Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0.1, Web Browser：firefox 6.0，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk: 500G
> Reporter: taoyunxing
> Labels: transfer_encoding_chunded
> Fix For: 3.1.1
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Recently I meet with a strange proble when I manage to get the server response body in the "Transfer Encoding: chunked" mode:
> I couldn't get the corresponding chunk length in hexdecimal ! The details as follows:
> I use the "null-transform" plugin modified to just output the server response body, when the web server uses the "Transfer Encoding: chunked" header
> to transfer chunked data to user agent, eg, I request the web page: "http://www.qq.com/", I just get the chunk body data, but get no chunk length in
> the hexdecimal format "383cb\r\n" before the chunk body data. the chunk body data is uncompressed and like as "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n......."
> In addition, I capture the data packet using the Wireshark software, I sure that I see the chunk length "383cb\r\n" before the chunk body data "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n.......", it is a complete chunk response !
> I continue to check the code of null-transform.c, set a breakpoint at the function TSIOBufferBlockReadStart(), run ATS and debug it, when ATS stop at the breakpoint TSIOBufferBlockReadStart(), I print the return string of TSIOBufferBlockReadStart(), there is no chunk data length at the head of output string, which implies the api TSIOBufferBlockReadStart() has bug！
> Breakpoint 1, TSIOBufferBlockReadStart (blockp=0x89d6570, readerp=0x89d5330, avail=0xb6c8e288) at InkIOCoreAPI.cc:659
> 659 {
> (gdb) s
> 660 sdk_assert(sdk_sanity_check_iocore_structure(blockp) == TS_SUCCESS);
> (gdb) n
> 667 p = blk->start();
> (gdb)
> 668 if (avail)
> (gdb) p p
> $3 = 0xb1312000 "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\r\n<html xmlns=\"http://www.w3.org/1999/xhtml\">\r\n<head>\r\n<meta http-equiv=\"Conten"...
> (gdb)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-921) TSIOBufferBlockReadStart() could'nt
return the corresponding chunk data length when original server using the
"Transfer Encoding: chunked" http header !
Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-921:
-----------------------------
Fix Version/s: (was: 3.1.2)
3.1.3
Looking for someone who wish to work on this (if so, just take it / assign it). Moving out unassigned bugs with no patches etc. to 3.1.3 for now.
> TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the "Transfer Encoding: chunked" http header !
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TS-921
> URL: https://issues.apache.org/jira/browse/TS-921
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
> Affects Versions: 3.0.1
> Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0.1, Web Browser：firefox 6.0，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk: 500G
> Reporter: taoyunxing
> Labels: transfer_encoding_chunded
> Fix For: 3.1.3
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Recently I meet with a strange proble when I manage to get the server response body in the "Transfer Encoding: chunked" mode:
> I couldn't get the corresponding chunk length in hexdecimal ! The details as follows:
> I use the "null-transform" plugin modified to just output the server response body, when the web server uses the "Transfer Encoding: chunked" header
> to transfer chunked data to user agent, eg, I request the web page: "http://www.qq.com/", I just get the chunk body data, but get no chunk length in
> the hexdecimal format "383cb\r\n" before the chunk body data. the chunk body data is uncompressed and like as "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n......."
> In addition, I capture the data packet using the Wireshark software, I sure that I see the chunk length "383cb\r\n" before the chunk body data "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n.......", it is a complete chunk response !
> I continue to check the code of null-transform.c, set a breakpoint at the function TSIOBufferBlockReadStart(), run ATS and debug it, when ATS stop at the breakpoint TSIOBufferBlockReadStart(), I print the return string of TSIOBufferBlockReadStart(), there is no chunk data length at the head of output string, which implies the api TSIOBufferBlockReadStart() has bug！
> Breakpoint 1, TSIOBufferBlockReadStart (blockp=0x89d6570, readerp=0x89d5330, avail=0xb6c8e288) at InkIOCoreAPI.cc:659
> 659 {
> (gdb) s
> 660 sdk_assert(sdk_sanity_check_iocore_structure(blockp) == TS_SUCCESS);
> (gdb) n
> 667 p = blk->start();
> (gdb)
> 668 if (avail)
> (gdb) p p
> $3 = 0xb1312000 "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\r\n<html xmlns=\"http://www.w3.org/1999/xhtml\">\r\n<head>\r\n<meta http-equiv=\"Conten"...
> (gdb)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-921) TSIOBufferBlockReadStart() could'nt
return the corresponding chunk data length when original server using the
"Transfer Encoding: chunked" http header !
Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-921:
-----------------------------
Fix Version/s: (was: 3.1.1)
3.1.2
Moving all unassigned bugs out to 3.1.2
> TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the "Transfer Encoding: chunked" http header !
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TS-921
> URL: https://issues.apache.org/jira/browse/TS-921
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
> Affects Versions: 3.0.1
> Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0.1, Web Browser：firefox 6.0，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk: 500G
> Reporter: taoyunxing
> Labels: transfer_encoding_chunded
> Fix For: 3.1.2
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Recently I meet with a strange proble when I manage to get the server response body in the "Transfer Encoding: chunked" mode:
> I couldn't get the corresponding chunk length in hexdecimal ! The details as follows:
> I use the "null-transform" plugin modified to just output the server response body, when the web server uses the "Transfer Encoding: chunked" header
> to transfer chunked data to user agent, eg, I request the web page: "http://www.qq.com/", I just get the chunk body data, but get no chunk length in
> the hexdecimal format "383cb\r\n" before the chunk body data. the chunk body data is uncompressed and like as "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n......."
> In addition, I capture the data packet using the Wireshark software, I sure that I see the chunk length "383cb\r\n" before the chunk body data "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n.......", it is a complete chunk response !
> I continue to check the code of null-transform.c, set a breakpoint at the function TSIOBufferBlockReadStart(), run ATS and debug it, when ATS stop at the breakpoint TSIOBufferBlockReadStart(), I print the return string of TSIOBufferBlockReadStart(), there is no chunk data length at the head of output string, which implies the api TSIOBufferBlockReadStart() has bug！
> Breakpoint 1, TSIOBufferBlockReadStart (blockp=0x89d6570, readerp=0x89d5330, avail=0xb6c8e288) at InkIOCoreAPI.cc:659
> 659 {
> (gdb) s
> 660 sdk_assert(sdk_sanity_check_iocore_structure(blockp) == TS_SUCCESS);
> (gdb) n
> 667 p = blk->start();
> (gdb)
> 668 if (avail)
> (gdb) p p
> $3 = 0xb1312000 "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\r\n<html xmlns=\"http://www.w3.org/1999/xhtml\">\r\n<head>\r\n<meta http-equiv=\"Conten"...
> (gdb)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-921) TSIOBufferBlockReadStart() could'nt
return the corresponding chunk data length when original server using the
"Transfer Encoding: chunked" http header !
Posted by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-921:
-----------------------------
Fix Version/s: (was: 3.1.4)
3.3.0
Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
> TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the "Transfer Encoding: chunked" http header !
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TS-921
> URL: https://issues.apache.org/jira/browse/TS-921
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
> Affects Versions: 3.0.1
> Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0.1, Web Browser：firefox 6.0，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk: 500G
> Reporter: taoyunxing
> Labels: transfer_encoding_chunded
> Fix For: 3.3.0
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Recently I meet with a strange proble when I manage to get the server response body in the "Transfer Encoding: chunked" mode:
> I couldn't get the corresponding chunk length in hexdecimal ! The details as follows:
> I use the "null-transform" plugin modified to just output the server response body, when the web server uses the "Transfer Encoding: chunked" header
> to transfer chunked data to user agent, eg, I request the web page: "http://www.qq.com/", I just get the chunk body data, but get no chunk length in
> the hexdecimal format "383cb\r\n" before the chunk body data. the chunk body data is uncompressed and like as "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n......."
> In addition, I capture the data packet using the Wireshark software, I sure that I see the chunk length "383cb\r\n" before the chunk body data "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n.......", it is a complete chunk response !
> I continue to check the code of null-transform.c, set a breakpoint at the function TSIOBufferBlockReadStart(), run ATS and debug it, when ATS stop at the breakpoint TSIOBufferBlockReadStart(), I print the return string of TSIOBufferBlockReadStart(), there is no chunk data length at the head of output string, which implies the api TSIOBufferBlockReadStart() has bug！
> Breakpoint 1, TSIOBufferBlockReadStart (blockp=0x89d6570, readerp=0x89d5330, avail=0xb6c8e288) at InkIOCoreAPI.cc:659
> 659 {
> (gdb) s
> 660 sdk_assert(sdk_sanity_check_iocore_structure(blockp) == TS_SUCCESS);
> (gdb) n
> 667 p = blk->start();
> (gdb)
> 668 if (avail)
> (gdb) p p
> $3 = 0xb1312000 "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\r\n<html xmlns=\"http://www.w3.org/1999/xhtml\">\r\n<head>\r\n<meta http-equiv=\"Conten"...
> (gdb)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-921) TSIOBufferBlockReadStart() could'nt
return the corresponding chunk data length when original server using the
"Transfer Encoding: chunked" http header !
Posted by "William Bardwell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087081#comment-13087081 ]
William Bardwell commented on TS-921:
-------------------------------------
Normally TS is undoing the chunked encoding so that plugins and such don't need to worry about the transfer encoding. Is there any reason why the BufferBlock functions would be expected to pass it through? (The docs that I saw didn't say anything about that.) On an Intercept I would expect to see stuff like that, but not in a transform.
> TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the "Transfer Encoding: chunked" http header !
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TS-921
> URL: https://issues.apache.org/jira/browse/TS-921
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
> Affects Versions: 3.0.1
> Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0.1, Web Browser：firefox 6.0，CPU: Intel core i3-2100 3.10GHz, Memory: 2G, HardDisk: 500G
> Reporter: taoyunxing
> Labels: transfer_encoding_chunded
> Fix For: 3.0.2
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Recently I meet with a strange proble when I manage to get the server response body in the "Transfer Encoding: chunked" mode:
> I couldn't get the corresponding chunk length in hexdecimal ! The details as follows:
> I use the "null-transform" plugin modified to just output the server response body, when the web server uses the "Transfer Encoding: chunked" header
> to transfer chunked data to user agent, eg, I request the web page: "http://www.qq.com/", I just get the chunk body data, but get no chunk length in
> the hexdecimal format "383cb\r\n" before the chunk body data. the chunk body data is uncompressed and like as "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n......."
> In addition, I capture the data packet using the Wireshark software, I sure that I see the chunk length "383cb\r\n" before the chunk body data "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\r\n.......", it is a complete chunk response !
> I continue to check the code of null-transform.c, set a breakpoint at the function TSIOBufferBlockReadStart(), run ATS and debug it, when ATS stop at the breakpoint TSIOBufferBlockReadStart(), I print the return string of TSIOBufferBlockReadStart(), there is no chunk data length at the head of output string, which implies the api TSIOBufferBlockReadStart() has bug！
> Breakpoint 1, TSIOBufferBlockReadStart (blockp=0x89d6570, readerp=0x89d5330, avail=0xb6c8e288) at InkIOCoreAPI.cc:659
> 659 {
> (gdb) s
> 660 sdk_assert(sdk_sanity_check_iocore_structure(blockp) == TS_SUCCESS);
> (gdb) n
> 667 p = blk->start();
> (gdb)
> 668 if (avail)
> (gdb) p p
> $3 = 0xb1312000 "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\r\n<html xmlns=\"http://www.w3.org/1999/xhtml\">\r\n<head>\r\n<meta http-equiv=\"Conten"...
> (gdb)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira