You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (Updated) (JIRA)" <ji...@apache.org> on 2012/01/09 00:06:39 UTC
[jira] [Updated] (TS-921) TSIOBufferBlockReadStart() could'nt
return the corresponding chunk data length when original server using the
"Transfer Encoding: chunked" http header !
[ 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