Traffic Server
  1. Traffic Server
  2. TS-921

TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the "Transfer Encoding: chunked" http header !

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: 3.0.1
    • Fix Version/s: 3.3.2
    • Component/s: TS API
    • 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

      Description

      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)

        Activity

        Hide
        James Peach added a comment -

        Behaves correctly.

        Show
        James Peach added a comment - Behaves correctly.
        Hide
        Uri Shachar added a comment -

        This can probably be closed – As William wrote in the initial comment, dechunking happens before the transform receives the data....

        Show
        Uri Shachar added a comment - This can probably be closed – As William wrote in the initial comment, dechunking happens before the transform receives the data....
        Hide
        Leif Hedstrom added a comment -

        Moving to 3.3.2.

        Show
        Leif Hedstrom added a comment - Moving to 3.3.2.
        Hide
        Leif Hedstrom added a comment -

        Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.

        Show
        Leif Hedstrom added a comment - Moving all unassigned bugs out to 3.3.0. Move back and assign as necessary.
        Hide
        Leif Hedstrom added a comment -

        Moved to 3.1.4, please move bugs back to 3.1.3, which you will work on in the next 2 weeks.

        Show
        Leif Hedstrom added a comment - Moved to 3.1.4, please move bugs back to 3.1.3, which you will work on in the next 2 weeks.
        Hide
        Leif Hedstrom added a comment -

        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.

        Show
        Leif Hedstrom added a comment - 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.
        Hide
        Leif Hedstrom added a comment -

        Moving all unassigned bugs out to 3.1.2

        Show
        Leif Hedstrom added a comment - Moving all unassigned bugs out to 3.1.2
        Hide
        Leif Hedstrom added a comment -

        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).

        Show
        Leif Hedstrom added a comment - 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).
        Hide
        William Bardwell added a comment -

        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.

        Show
        William Bardwell added a comment - 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.

          People

          • Assignee:
            James Peach
            Reporter:
            taoyunxing
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 672h
              672h
              Remaining:
              Remaining Estimate - 672h
              672h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development