Re: [PREVIEW] 1xx response forwarding

Alex Rousskov wrote:
>> 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?

No. Bad naming maybe, but its primarily there to suppress 417 responses
being generated in the negative case to broken clients. Even with
working 1xx support internally we may still be required to suppress
these (ie when forwarding to a known 1.0 peer).

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.6
   Beta testers wanted for 3.2.0.1