[
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
