Re: handling 1xx responses

I assume you are talking about "100 Continue" here.. There is only two
1XX response types defined, and 101 is a very different beast. You
cannot apply the same forwarding rules on 101 even if the RFC tries
to bundle them together..

After a 101 response the proxy must effectively switch to tunnel mode
unless it knows the new protocol.

Note that there is two types of "100 Continue" messages. Those in
response to the client, and those in response to the proxy, and we
should deal with both.

Splitting responses in metadata+headers and object is a must for this
to work, and should have been done from start. The current habit of
using HTTP internally between the "store" (including forwarding) and
client_side.c is a big mistake in my opinion.

We still should have the limit that there may only be one object
returned I think. Informal HTTP messages never contain an object.

Regards
Henrik

On Tuesday 03 September 2002 14.33, Robert Collins wrote:
> Heres my current thoughts:
>
> We rework the data path to separate metadata from data as per the
> current architecture TODO.
>
> Then, we change the rule that says a request can only have one
> object returned - we can send a metadata with no body and a flag
> (say 'interim') down the pipeline. Whoever originated the cause of
> the 1xx reply swallows it, and the store effectively ignores it
> because of the interim flag.
>
> Thoughts?
>
> Rob
Received on Tue Sep 03 2002 - 18:27:56 MDT