You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "William Bardwell (JIRA)" <ji...@apache.org> on 2011/08/18 18:06:27 UTC

[jira] [Commented] (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: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