[
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
