TS API won't return header data of > 4K

[Nick Kew <ni...@apache.org>]

We've been chasing a strange problem with an ironbee
test case.  As the HTTP header size (from the method
to the blank line) grows above 4K, TSAPI 'loses' the
first 4Kb.  Request line details (method, url, version)
are fine if we use their explicit APIs, but the data
are lost/

I'll attach a mini demo-plugin that reproduces the problem.
The essence of it can be boiled down to:

    TSHttpTxnClientReqGet(txnp, &bufp, &hdr_loc);

    iobufp = TSIOBufferCreate();
    TSHttpHdrPrint(bufp, hdr_loc, iobufp);

    readerp = TSIOBufferReaderAlloc(iobufp);
    blockp = TSIOBufferReaderStart(readerp);

    len = TSIOBufferBlockReadAvail(blockp, readerp);

    head_buf = TSIOBufferBlockReadStart(blockp, readerp, &len);


What happens here is that the first 4K of a request are
'lost' in TSHttpHdrPrint.  Thus all we see in head_buf
is the last few bytes of a header a little larger than 4K.
I think the culprit is the do { } loop at lines 3603-3617
of InkAPI.cc, which goes around twice and overwrites the
first 4K on the second time round.

In addition to the demo plugin, I'll attach the two
testcases my colleague sent me.  It demonstrates that
a single extra byte in the header makes the difference
between working fine and provoking the problem.

A bug or a PBKAC?

[Bcc: my colleague]

-- 
Nick Kew

Re: TS API won't return header data of > 4K

[Nick Kew <ni...@apache.org>]

On 24 Apr 2013, at 15:43, Leif Hedstrom wrote:

> On 4/24/13 6:51 AM, Nick Kew wrote:
>> On Fri, 19 Apr 2013 22:54:47 +0100
>> Nick Kew <ni...@apache.org> wrote:
>> 
>> 
>>> I'll attach a mini demo-plugin that reproduces the problem.
>>> The essence of it can be boiled down to:
>> Magic sauce here.
> 
> Indeed. I hate magic.
> 
> So, since for sure the regressions are hanging now, should we back out the commit, until we can figure out one of two things:

Yeah, OK.

It was after yesterday's session on IRC I wondered if a reader might retain a pointer
that was lost in the iobuf.  Obviously that couldn't happen if the pointer was already
lost before the reader was initialised.  But in this case, a bit of voodoo worked!

Some possible solutions:
  - Insist that a reader is initialised before writing data to the buffer.
  - Retain a pointer to all (not-yet-consumed) data in the iobuf.

-- 
Nick Kew

Re: TS API won't return header data of > 4K

[Daniel Gruno <ru...@cord.dk>]

On 04/24/2013 04:43 PM, Leif Hedstrom wrote:
> On 4/24/13 6:51 AM, Nick Kew wrote:
>> On Fri, 19 Apr 2013 22:54:47 +0100
>> Nick Kew <ni...@apache.org> wrote:
>>
>>
>>> I'll attach a mini demo-plugin that reproduces the problem.
>>> The essence of it can be boiled down to:
>> Magic sauce here.
> 
> Indeed. I hate magic.
> 
> So, since for sure the regressions are hanging now, should we back out
> the commit, until we can figure out one of two things:
> 
> 1) If the patch is correct, why are the regressions hanging? And how do
> we fix that?
> 
> 2) If the patch is incorrect, lets figure out what the right solution.
> 
> 
> Thoughts?
> 
> -- Leif
> 
I see ATS freezing up on regression tests in two different places after
this commit was introduced, and, as much as I'm for fixing the original
problem, it's slightly disruptive, so I'm for rolling this back till we
can figure out why it's failing the tests or why it's wrong, whichever
it is. I've tried whatever I can to debug the issue, but apparently, I'm
no good at that :( Waiting for input/output from someone more clever on
this issue :)

With regards,
Daniel.

Re: TS API won't return header data of > 4K

[Leif Hedstrom <zw...@apache.org>]

On 4/24/13 6:51 AM, Nick Kew wrote:
> On Fri, 19 Apr 2013 22:54:47 +0100
> Nick Kew <ni...@apache.org> wrote:
>
>
>> I'll attach a mini demo-plugin that reproduces the problem.
>> The essence of it can be boiled down to:
> Magic sauce here.

Indeed. I hate magic.

So, since for sure the regressions are hanging now, should we back out the 
commit, until we can figure out one of two things:

1) If the patch is correct, why are the regressions hanging? And how do we 
fix that?

2) If the patch is incorrect, lets figure out what the right solution.


Thoughts?

-- Leif

Re: TS API won't return header data of > 4K

[Nick Kew <ni...@apache.org>]

On Fri, 19 Apr 2013 22:54:47 +0100
Nick Kew <ni...@apache.org> wrote:


> I'll attach a mini demo-plugin that reproduces the problem.
> The essence of it can be boiled down to:

Magic sauce here.

This fails:
    TSHttpTxnClientReqGet(txnp, &bufp, &hdr_loc);
    iobufp = TSIOBufferCreate();
    TSHttpHdrPrint(bufp, hdr_loc, iobufp);
    readerp = TSIOBufferReaderAlloc(iobufp);

This works:
    TSHttpTxnClientReqGet(txnp, &bufp, &hdr_loc);
    iobufp = TSIOBufferCreate();
    readerp = TSIOBufferReaderAlloc(iobufp);
    TSHttpHdrPrint(bufp, hdr_loc, iobufp);

We can get away with losing the buffer in the iobuf
provided the reader buf was set *before* trashing it.  Ouch!

I thought I got the first originally from an example plugin,
though I can't find it in current versions.  It is still there
in proxy/InkAPITest.cc at line 3445:

    TSIOBuffer iobuf = TSIOBufferCreate();
    TSHttpHdrPrint(bufp1, hdr_loc1, iobuf);
    TSIOBufferReader iobufreader = TSIOBufferReaderAlloc(iobuf);

Hmmm ....

-- 
Nick Kew