Re: handling 1xx responses

On Wed, 2002-09-04 at 09:49, Henrik Nordstrom wrote:
> 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.

Upgrade: is a hop to hop header, and ONLY squid can issue it. So I'm
referring to both, but we won't issue Upgrade: requests at the moment.
When we support an upgraded protocol, this architecture should still
work as we can immediately switch to 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.

Yes - this is done by client_side_socket forwarding the 100 to the
client. If the 100 is in response to the proxy, it gets swallowed by the
store (or whatever module requested it).
 
> 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.

:}. Yep, we ALL agree on this.
 
> We still should have the limit that there may only be one object
> returned I think. Informal HTTP messages never contain an object.

lets define object more strictly then.

If we define object as 'any non informal reply struct optionally
followed by object body data'. Then yes, I agree with you.

However there is currently code that assumes that when a set of headers
has been seen, an object has been seen. This will be false once we
support 1xx responses.

Rob