[PREVIEW] 1xx response forwarding

> On Mon, 16 Aug 2010 15:53:42 -0600, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> > Hello,
>> >
>> > We need to forward 1xx control messages from servers to clients. I
>> > see two implementation options:
>> >
>> > 1. Use Store. Squid client side expects responses via storeClientCopy,
>> > so we will be using the usual/normal code paths. Multiple 1xx responses
>> > may be handled with relative ease. The 1xx responses in Store will be
>> > treated kind of as regular response headers, except they will not be
>> > cached and such. The code will need to "skip" them until they reach the
>> > socket-writing client.
>> >
>> > 2. Bypass Store. Contact fwdStart caller (e.g., clientReplyContext)
>> > directly and give it a 1xx response to forward. Store code remains
>> > unchanged. It may be difficult to get from the fwdStart caller to the
>> > client socket and comm_write. It will be difficult to handle multiple
>> > 1xx responses or a regular response that arrives before we are done with
>> > writing 1xx response (all unusual, but can happen!).
>> >
>> > Both approaches may have to deal with crazy offset management,
>> > clientStreams manipulations, and other client-side mess.
>> >
>> >
>> > Do you see any other options? Which option is the best?

On 08/16/2010 04:06 PM, Amos Jeffries wrote:
> My earlier plan if I did it was to do (2). The complication only occurs at
> one point, finding the client FD.
> comm_write() should not be altering offset of the higher level store stuff
> directly. If it is that is a bug to be fixed.
>
> Pipelining the responses one at a time with a simple block on further
> reply passing-on until the existing header set has been finished with gets
> around any trickiness with multiple or early real responses.

The "block on further reply passing" is far from simple because it needs
to deal with two async jobs.

On 08/18/2010 02:11 PM, Henrik Nordström wrote:
> mån 2010-08-16 klockan 15:53 -0600 skrev Alex Rousskov:
>
>> Both approaches may have to deal with crazy offset management,
>> clientStreams manipulations, and other client-side mess.
>
> Yes.
>
> For now I think we need to bypass store to make this sane, and it's
> probably also a step in the right direction in general.

Thank you both for your feedback!

The attached patch implements the "Bypass Store" design and forwards 1xx
control messages to clients that are likely to be able to handle such
messages.

The patch appears to pass initial tests but more testing and a sync with
trunk are needed. There is also one XXX that I still need to resolve,
but it requires some code from the bug #2583 (pure virtual call) fix. I
will switch to committing that fix now.

Meanwhile, if you have a chance, please review the overall direction of
the patch. Preamble has more notes.

The patch removes the ignore_expect_100 feature because we now forward
100 Continue messages. Is everybody OK with that removal?

Thank you,

Alex.